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.
- 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
- Access http://openhatch.org/bugsets/ as an authenticated user.
- Be presented with the list of bug sets.
- Create a new list! --> List creation 1
- Open/Edit an existing list! --> List creation 2
- Delete a list! --> Same page confirmation & reload
- 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.
- 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.
- "Save" --> updates the preview list, slug, name
- "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:
- Last Updated
- First Reported
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.
- 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
- 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.
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
- 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.
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.
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.
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".
- 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)
- 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
This section intentionally left blank.