Anonymous user
GSoC 2014/bug-set-creator: Difference between revisions
→Asheesh
imported>Ehashman |
|||
| (14 intermediate revisions by 3 users not shown) | |||
Line 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:''' 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.
Line 66 ⟶ 68:
[[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
--><p>
#* Assigned Attendee
#* Task Description
#* Task Description </p><p>A user could then fill in these fields before or during an event: </p><!--▼
#* Assigned mentor
#* Language
#* Skills needed
#* Field of project
#* Estimated time to address bug
▲#*
--><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.
=== 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 92 ⟶ 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 99 ⟶ 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 ==
| |||