GSoC 2014/bug-set-creator: Difference between revisions
imported>Ehashman (Initial commit) |
imported>Ehashman |
||
(24 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
This page will serve as the home of the documentation for the bug set creator for '''[https://www.google-melange.com/gsoc/project/details/google/gsoc2014/ehashman/5649050225344512 OpenHatch's project in Google Summer of Code 2014].''' |
|||
This page left intentionally blank. |
|||
== 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. |
|||
## Create a new list! --> [[#List creation|List creation 1]] |
|||
## Open/Edit an existing list! --> [[#List creation|List creation 2]] |
|||
## Delete a list! --> Same page confirmation & reload |
|||
## View a list! --> [[#List view|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. |
|||
## "Save" --> updates the preview list, slug, name |
|||
## "Save & Quit" --> saves the list by writing to the db, redirects to the List view |
|||
[[File:Bug-set-creator-create-screen-1.jpg|thumb|Initial creation mockup]][[File:Bug-set-creator-create-screen-2.jpg|thumb|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? |
|||
* '''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 === |
|||
[[File:Bug-set-creator-view-screen.jpg|thumb|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: <!-- |
|||
--><p> |
|||
#* Assigned Attendee |
|||
#* Task Description |
|||
#* Assigned mentor |
|||
#* Language |
|||
#* Skills needed |
|||
#* Field of project |
|||
#* Estimated time to address bug |
|||
#* Status (unclaimed, claimed, needs-review, resolved)</p><p>A user could then fill in these fields before or during an event: </p><!-- |
|||
--><p> |
|||
#* '''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</p> |
|||
# 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|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. |
Latest revision as of 19:08, 26 July 2014
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.
- 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.
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.
- "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:
- 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.