Story 1.7
XXX flacoste duplicate of ../../Stories#story-1.1
An a Ubuntu developer
I want to make an external upstream aware of a triaged bug in Ubuntu
So that we don't have to deal with it anymore.Notes: Benefit isn't that realistic here.
Story 1.8
XXX flacoste Redundant with ../../Stories#story-1.
As an Ubuntu developer (John)
I want to spend as little time as possible processing bugs (confirming and triaging)
So that I can spend as much time as possible coding fixes.Notes: Launchpad could ask questions and/or use "affects me too" information to suggest triages and even auto-triage. IOW, Launchpad could do more to support crowdsourcing technically.
Not duplicates
Story 1.9
XXX - jml - not that valuable in itself, but probably quite cheap to do after doing the inline project registration stuff required for the more critical stories. Also, LP would feel oddly incomplete without it.
As an Ubuntu fan,
I want to quickly add upstream data for packages that are missing it
So that I can help the project although I'm not a coder (and earn karma and brag about it).
Story 1.10
XXX - flacoste Too small to be on this list. JFDI.
As an Ubuntu QA engineer,
I want to know how many users are affected by a bug
So that I can prioritise bugs more easily.
Story 1.11
XXX - flacoste Better triage service, less than upstream.
As a developer
I want incomplete bugs to automatically go back to confirmed when the reporter provides the requested information
So that I don't have to mark them confirmed myself.
Story 1.12
XXX - jml Contingent to package of the day "network".
As an Ubuntu QA engineer,
I want to have people be able to easily confirm the bug against latest trunk,
so that I know whether the bug exists upstream.Notes:
- This helps bug triagers to decide whether the bug is in Ubuntu, or should be sent upstream.
- It's important that it's easy for the tester to test the latest version, without messing up his system.