Anonymous user
GSoC 2014/bug-set-creator: Difference between revisions
→Asheesh
imported>Ehashman No edit summary |
imported>Ehashman |
||
(21 intermediate revisions by 3 users not shown) | |||
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].'''
== 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
* 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.
Line 23 ⟶ 22:
'''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
[[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:
Line 56 ⟶ 57:
'''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:'''
[[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
* '''
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.
Line 90 ⟶ 109:
* 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
Line 97 ⟶ 118:
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 ==
|