GSoC 2014/bug-set-creator: Difference between revisions
Content added Content deleted
Line 80: | Line 80: | ||
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. |
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 |
* '''Elana (e):''' 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. |
||
* ''' |
* '''e:''' We want to encourage users to add their trackers, especially if it's a type we already support. WelcomeBot was added to our trackers as a result of this conversation, and that's great! However, having your tracker in the OH database will *not* be mandatory for use of this tool. |
||
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 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: | Line 93: | ||
* Skills needed |
* Skills needed |
||
** '''e:''' is this kind of the same as language? |
** '''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 |
* Field of project |
||
** '''e:''' I assume this means [frontend, backend, design, docs, web] etc. |
** '''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 |
* Estimated time to address bug |
||
Line 99: | Line 102: | ||
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". |
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:''' 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. |
|||
== Implementation == |
== Implementation == |