Anonymous user
GSoC 2014/bug-set-creator: Difference between revisions
Contents of an initial email
imported>Ehashman (Initial commit) |
imported>Ehashman (Contents of an initial email) |
||
Line 1:
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.
== Planning and Design ==
The project is currently
=== 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.
'''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.
==== 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.
#* If an URL corresponds to a bug in the OpenHatch database, it is included in the set. If not, user is presented with a warning message for that URL. See the mockups for a better idea.
# ''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?
'''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?
'''POSSIBLE NEXT ITERATION:''' Rather than presenting a user with a warning if a bug URL is not in the OpenHatch database, the tool could instead note that these bugs aren't in the OpenHatch bug database and walk the user through adding their tracker via http://openhatch.org/customs/ We'll want this to launch a crawl immediately.
==== List view ====
# User gets to view a table very similar to that of the preview screen in List creation, but with two additional columns with initially blank, writeable fields: <!--
--><p>
#* Assigned Attendee
#* Task Description </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. </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.
== Implementation ==
This section intentionally left blank.
| |||