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.

User Interface and Workflow

Main page

Access http://openhatch.org/bugsets/ as an authenticated user.
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

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.
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

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

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:
- Assigned Attendee
- Task Description
- Assigned mentor
- Language
- Skills needed
- Field of project
- Estimated time to address bug
- Status (unclaimed, claimed, needs-review, resolved)
  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.
- Assigned mentor: Elana
- Language: HTML, CSS
- Skills needed: web development, writing skills
- Field of project: OH training missions
- Estimated time to address bug: 30 minutes
- Status: claimed
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.

User Feedback

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.