OpenHatch wiki

GSoC 2014/bug-set-creator

< GSoC 2014
Revision as of 15:43, 31 May 2014 by 129.97.124.247 (talk) (→‎User Interface and Workflow)

This page will serve as the home of the documentation for the bug set creator for OpenHatch's project in Google Summer of Code 2014.

Preface: Planning and Design

Elana Hashman, this year's Google Summer of Code student, is building a "bug set creator" for newcomer-oriented events and activities including but not limited to OpenHatch's Open Source Comes to Campus. This will become a new section of the site, distinct from http://openhatch.org/search/, that allows a user to assemble, save, and edit a hot list of bugs of interest. The idea is to help the user to prep lists of tasks for attendees of in-person open source contribution events.

Assumptions:

  • Bugs of interest may already scraped and housed in the OpenHatch bug database.
  • A user has some sort of way of searching for bugs of interest and has already collected a list of URLs of interest.

User Interface and Workflow

Main page

  1. Access http://openhatch.org/bugsets/ as an authenticated user.
  2. Be presented with the list of bug sets.
    1. Create a new list! --> List creation 1
    2. Open/Edit an existing list! --> List creation 2
    3. Delete a list! --> Same page confirmation & reload
    4. View a list! --> List view

QUESTION: Should the list of bug sets you are presented with be global or per-user? Leaning towards global, possibly with filtering.

  • ANSWER: We will start with global.

QUESTION: Should deletion just be a flag that makes the list not show up on the website as opposed to an actual deletion? Methinks yes.

  • ANSWER: Yes, we will use delete flags instead of deleting data.

List creation

  1. Initial creation. Be presented with a box that allows you to enter a number of bug URLs, separated by newlines. Clicking "Save" submits the info.
  2. Edit screen. User is presented with a table preview of the given list of bugs, and can additionally enter a slug and human-readable name for the list, as well as an event date.
    1. "Save" --> updates the preview list, slug, name
    2. "Save & Quit" --> saves the list by writing to the db, redirects to the List view
 
Initial creation mockup
 
Edit screen mockup

Each bug will be displayed in the preview table with the following columns:

  • Project
  • Last Updated
  • First Reported
  • Summary

A sample row might be:

  • Project: Python
  • Last updated: 3 weeks ago
  • First reported: 1 month ago
  • Summary: dev guide appears not to cover the benchmarking suite

The underlying data structure for a bug set might look like the tuple 

   (creator, slug, event, event_date, [(bug1, assigned_attendee1, task_desc1), ... ])

The assigned attendee and task description can be set in the List view screen.

QUESTION: The columns above are only a subset of the data we have available. Are there any other fields you think are missing from the preview?

QUESTION: This relies on a user finding the bug URLs on their own, probably using the advanced search features of a project tracker. How valuable would an advanced search UI on the OpenHatch bug database be to help create the set?

POSSIBLE NEXT ITERATION: If bugs are available in the OH database, we'll use their info to help fill in fields. If not, we might want to try launching a crawl of these new bug URLs.

List view

 
List view
  1. User gets to view a table very similar to that of the preview screen in List creation, but with two additional columns with initially blank, writeable fields:

    • Assigned Attendee
    • Task Description

      A user could then fill in these fields before or during an event:

    • Assigned Attendee: Ke
    • Task Description: Improve our git training mission to be clearer. Purely HTML.

  2. User clicks "Save" to submit this info. Page is refreshed.

POSSIBLE NEXT ITERATION: This interface is likely going to be accessed/modified by a number of people at once. I've currently addressed this issue by having a per-bug save button. What do you think about modifying the page to allow real-time collaboration, ala MoPad or Google Docs, et al.? No clicking "Save" or page refreshes required.

Shauna's Feedback

I want to be able to add bugs from projects OpenHatch doesn't track. For instance, WelcomeBot's issues are not tracked. This could be in the form of freehand entry bugs.

  • Elana (e): I'm fine with freehand bug entry so long as they are limited to the bug set creator, and *not* entered into the OpenHatch bug database. If we want the latter, we should be implementing a scrape because that data is not static forever (and the hand-entered bug would be), whereas bug data is going to be basically static for the purposes of a time-limited event.
  • e: We want to encourage users to add their trackers, especially if it's a type we already support. WelcomeBot was added to our trackers as a result of this conversation, and that's great! However, having your tracker in the OH database will *not* be mandatory for use of this tool.


I am worried that it is too much effort to get people to add their trackers, and I don't want to add their trackers for them without their permission.

  • e: We will not require use of trackers though, and think about integration with the OH bug database later.


I want the following fields added to the List View screen:

  • Assigned mentor
  • Language
  • Skills needed
    • e: is this kind of the same as language?
    • Shauna: No, I'm thinking more like "familiarity with social media", "fluent english", "unit testings", "graphical skills", etc.
  • Field of project
    • e: I assume this means [frontend, backend, design, docs, web] etc.
    • Shauna: I meant something like "science" or "humanitarian" or "games" :)
  • Estimated time to address bug


I want it to be easy to sort through the list of bugs. For example, I'd like to be able to use a filter to show only "bugs in Python" AND "bugs tagged Science".

  • e: Something like a user request to sort the table by columns might cover this case. Actual filtering seems like a lot of work, I was thinking these sets wouldn't get over about 30 bugs in size.
  • e: This will be something to consider for a later iteration.


I want to be able to use a bug on different event lists, and not have to edit it for each list if I want to make changes.

  • e: We will store annotated bugs in their own table, and use a many-to-many relationship between lists and bugs. That way, if bug A is in lists 1, 2, and 3, editing bug A on the list 1 screen will make changes for lists 2 and 3 as well.

Catherine's Feedback

It would be nice to have a bookmarklet-type button I could install in my web browser that would add the URL I'm currently on to my bug list. Then I could browse for bugs in the original project's bug tracker and add them very easily to my target list. I think bookmarklets are very easy to write, provided that you have an API (preferably a RESTful API). Many applications (like Django) have plugins to make exposing a RESTful API really easy.

  • e: This is a really neat idea that could be a cool add-on for a later project iteration.

Jessica's Feedback

If the application is importing bug information directly from the trackers, it will need to be updated frequently.

  • e: I think we're going to shy away from this to begin with, but may look into scraping and updating the bugs later.


I want to be able to mark bugs waiting on review in the set.

I want a way for attendees to claim tickets and resolve them in the application.

  • e: Yes, attendee names are included in the annotation! I think the review/resolve portion of these two asks can both be covered by a bug status field in the annotation, which we can add.


I want to be able to tag bugs and filter them by tags.

  • e: Also requested by Shauna. Definitely in the pipeline.

Implementation

This section intentionally left blank.

Retrieved from "https://wiki.openhatch.org/wiki/GSoC_2014/bug-set-creator?oldid=14503"