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.

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.

Main page

 * 1) Access http://openhatch.org/bugsets/ as an authenticated user.
 * 2) Be presented with the list of bug sets.
 * 3) Create a new list! --> List creation 1
 * 4) Open/Edit an existing list! --> List creation 2
 * 5) Delete a list! --> Same page confirmation & reload
 * 6) 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.
 * 3) "Save" --> updates the preview list, slug, name
 * 4) "Save & Quit" --> saves the list by writing to the db, redirects to the List view



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?
 * ANSWER: Possibly project language. If we don't have the bug available, no big deal, but we won't have any details to display (perhaps a quick scrape would give us details like bug title).

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?
 * ANSWER: Unsure of the value of this feature at this point.

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



 * 1) User gets to view a table very similar to that of the preview screen in List creation, but with additional columns with blank, writeable fields:
 * 2) * Assigned Attendee
 * 3) * Task Description
 * 4) * Assigned mentor
 * 5) * Language
 * 6) * Skills needed
 * 7) * Field of project
 * 8) * Estimated time to address bug
 * 9) * Status (unclaimed, claimed, needs-review, resolved) A user could then fill in these fields before or during an event:
 * 10) * Assigned Attendee: Ke
 * 11) * Task Description: Improve our git training mission to be clearer. Purely HTML.
 * 12) * Assigned mentor: Elana
 * 13) * Language: HTML, CSS
 * 14) * Skills needed: web development, writing skills
 * 15) * Field of project: OH training missions
 * 16) * Estimated time to address bug: 30 minutes
 * 17) * Status: claimed
 * 18) 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
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
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
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.

Asheesh
It would be really cool if I could click a button along the lines of "unblock this subnet", that would allow users from a particular IP block to edit bugs without being logged in.
 * e: I suggested this, it would be cool, not sure how feasible this is. Asheesh gives a +1 so he can claim credit for the idea.

I might add bugs to a set, have no one show up to my sprint, and then want to use the same bug set later. But perhaps someone has closed some of those bugs in the meantime! I would like to have a 'refresh metadata' button that will let me know if the OpenHatch bug tracker has recorded any of my set's bugs as "looks closed".

Project Milestones

 * gsoc14.4: Week 4, May 25 -- June 1
 * List view
 * Blog post due June 1
 * gsoc14.5: Week 5, June 2 -- 8
 * View list view iteration 1 (no edits)
 * gsoc14.6: Week 6, June 9 -- 15
 * View list view iteration 2 (edits)
 * gsoc14.7: Week 7, June 16 -- 22
 * Blog post due June 22
 * gsoc14.8: Week 8, June 23 -- 29
 * Attend Open Source Bridge
 * Midterm Review
 * gsoc14.9: Week 9, June 30 -- July 6
 * gsoc14.10: Week 10, July 7 -- 13
 * Blog post due July 13
 * gsoc14.11: Week 11, July 14 -- 20
 * View list view iteration 3 (refinement & css)
 * gsoc14.12: Week 12, July 21 -- 27
 * Create and Edit views
 * Update list view
 * Blog post due July 27
 * gsoc14.13: Week 13, July 28 -- August 3
 * Simultaneous editing: Notification on edited bug list/bug set
 * Security fixes for production
 * Refresh metadata to inform user if bug is closed [stretch]
 * gsoc14.14: Week 14, August 4 -- 10
 * Call for user testing (Shauna, Jessica, Britta)
 * Documentation
 * gsoc14.15: Week 15, August 11 -- 17
 * User testing
 * Final Exams
 * Blog post due August 17
 * Recommendations for future extension(s)
 * gsoc14.16: Week 16, August 18 -- 22
 * Final Review
 * Security documentation PR for django-inplaceedit

Implementation
This section intentionally left blank.