GSoC 2014/bug-set-creator: Difference between revisions

Line 107:

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's Feedback ===

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's Feedback ===

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.

== Implementation ==