GSoC 2014/bug-set-creator

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.

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 are already scraped and housed in the OpenHatch bug database.
  • If they're not, a user should add the tracker of interest!
• 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.

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.

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.
   • If an URL corresponds to a bug in the OpenHatch database, it is included in the set. If not, user is presented with a warning message for that URL. See the mockups for a better idea.

1. 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: Rather than presenting a user with a warning if a bug URL is not in the OpenHatch database, the tool could instead note that these bugs aren't in the OpenHatch bug database and walk the user through adding their tracker via http://openhatch.org/customs/ We'll want this to launch a crawl immediately.

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's response: 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.
• Elana: I would prefer that users add their trackers, particularly if it's one we already support. WelcomeBot was added to our trackers as a result of this conversation, and that's great!

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.

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?
• Field of project
  • e: I assume this means [frontend, backend, design, docs, web] etc.
• 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.

Implementation

This section intentionally left blank.