Anonymous user
GSoC 2014/bug-set-creator: Difference between revisions
Shauna's feedback, stating assumptions
imported>Ehashman (Contents of an initial email) |
imported>Ehashman (Shauna's feedback, stating assumptions) |
||
Line 3:
== 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 are already scraped and housed in the OpenHatch bug database.
** If they're not, a user should add the tracker 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 ===
Line 19 ⟶ 25:
'''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 ====
Line 29 ⟶ 34:
## "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:
Line 56 ⟶ 60:
'''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 ====
Line 70 ⟶ 73:
'''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.
=== Shauna's Feedback ===
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's response:''' 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.
* '''Elana:''' I would prefer that users add their trackers, particularly if it's one we already support. WelcomeBot was added to our trackers as a result of this conversation, and that's great!
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.
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?
* Field of project
** '''e:''' I assume this means [frontend, backend, design, docs, web] etc.
* 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.
| |||