| 2007-10-16 07:25:59 |
Matthew Paul Thomas |
bug |
|
|
added bug |
| 2007-10-16 07:27:29 |
Matthew Paul Thomas |
description |
Large projects have dedicated QA teams that would benefit from knowing how well they are doing in attending to the project's bug reports, and in closing them.
This could be addressed with two cumulative frequency graphs on the project's Bugs page. The first would graph percentage of bug reports against time taken for report to first change state (e.g. New->Confirmed). The second would graph percentage of bug reports against how long before the report was closed (i.e. Invalid, Won't Fix, or Fix Released).
Probably it would save time to fix bug 37926 at the same time as doing this. |
Large projects have dedicated QA teams that would benefit from knowing how well they are doing in attending to the project's bug reports, and in closing them. Launchpad would be the ideal place to do this, but currently it doesn't.
One way of doing it would be two cumulative frequency graphs on the project's Bugs page. The first would graph percentage of bug reports against time taken for report to first change state (e.g. New->Confirmed). The second would graph percentage of bug reports against how long before the report was closed (i.e. Invalid, Won't Fix, or Fix Released).
Probably it would save time to fix bug 37926 at the same time as doing this. |
|
| 2008-05-20 14:19:09 |
Diogo Matsubara |
malone: status |
New |
Confirmed |
|
| 2010-12-26 18:36:29 |
Curtis Hovey |
launchpad: status |
Confirmed |
Triaged |
|
| 2010-12-26 18:36:34 |
Curtis Hovey |
tags |
lp-bugs |
feature lp-bugs |
|
| 2010-12-26 18:36:35 |
Curtis Hovey |
launchpad: importance |
Undecided |
Low |
|
| 2012-03-25 20:24:05 |
Matthew Paul Thomas |
attachment added |
|
wireframe of a Bugs page with status graph front and center https://bugs.launchpad.net/launchpad/+bug/153199/+attachment/2936420/+files/graphing.png |
|
| 2012-03-25 20:29:32 |
Matthew Paul Thomas |
description |
Large projects have dedicated QA teams that would benefit from knowing how well they are doing in attending to the project's bug reports, and in closing them. Launchpad would be the ideal place to do this, but currently it doesn't.
One way of doing it would be two cumulative frequency graphs on the project's Bugs page. The first would graph percentage of bug reports against time taken for report to first change state (e.g. New->Confirmed). The second would graph percentage of bug reports against how long before the report was closed (i.e. Invalid, Won't Fix, or Fix Released).
Probably it would save time to fix bug 37926 at the same time as doing this. |
Large projects have dedicated QA teams that would benefit from knowing how well they are doing in attending to the project's bug reports, and in closing them. Launchpad would be the ideal place to do this, but currently it doesn't.
Both current and potential contributors can also be motivated to work on a project or package by seeing how quickly (or otherwise) bugs are dealt with in that project/package. (For example, Colin Watson in <https://lists.ubuntu.com/archives/ubuntu-devel/2008-October/026729.html>: "I've found that seeing the bug graphs at http://people.ubuntu.com/~bryce/Plots/ drop can be a great incentive when I'm working on a package's bugs.")
One way of doing it would be two cumulative frequency graphs on the project's Bugs page. The first would graph percentage of bug reports against time taken for report to first change state (e.g. New->Confirmed). The second would graph percentage of bug reports against how long before the report was closed (i.e. Invalid, Won't Fix, or Fix Released).
A simpler way would be a single stacked bar chart showing, for the past few months, the number of bug reports that remained in each unresolved status on each day; and below the X status, the number of reports that were resolved in each way (fixed, declined, or marked as a duplicate) on that day. https://launchpadlibrarian.net/98323734/graphing.png
Probably it would save time to fix bug 37926 at the same time as doing this. |
|
| 2012-03-25 20:59:09 |
Matthew Paul Thomas |
description |
Large projects have dedicated QA teams that would benefit from knowing how well they are doing in attending to the project's bug reports, and in closing them. Launchpad would be the ideal place to do this, but currently it doesn't.
Both current and potential contributors can also be motivated to work on a project or package by seeing how quickly (or otherwise) bugs are dealt with in that project/package. (For example, Colin Watson in <https://lists.ubuntu.com/archives/ubuntu-devel/2008-October/026729.html>: "I've found that seeing the bug graphs at http://people.ubuntu.com/~bryce/Plots/ drop can be a great incentive when I'm working on a package's bugs.")
One way of doing it would be two cumulative frequency graphs on the project's Bugs page. The first would graph percentage of bug reports against time taken for report to first change state (e.g. New->Confirmed). The second would graph percentage of bug reports against how long before the report was closed (i.e. Invalid, Won't Fix, or Fix Released).
A simpler way would be a single stacked bar chart showing, for the past few months, the number of bug reports that remained in each unresolved status on each day; and below the X status, the number of reports that were resolved in each way (fixed, declined, or marked as a duplicate) on that day. https://launchpadlibrarian.net/98323734/graphing.png
Probably it would save time to fix bug 37926 at the same time as doing this. |
Large projects have dedicated QA teams that would benefit from knowing how well they are doing in attending to the project's bug reports, and in closing them. Launchpad would be the ideal place to do this, but currently it doesn't.
Both current and potential contributors can also be motivated to work on a project or package by seeing how quickly (or otherwise) bugs are dealt with in that project/package. (For example, Colin Watson in <https://lists.ubuntu.com/archives/ubuntu-devel/2008-October/026729.html>: "I've found that seeing the bug graphs at http://people.ubuntu.com/~bryce/Plots/ drop can be a great incentive when I'm working on a package's bugs.")
One way of doing it would be two cumulative frequency graphs on the project's Bugs page. The first would graph percentage of bug reports against time taken for report to first change state (e.g. New->Confirmed). The second would graph percentage of bug reports against how long before the report was closed (i.e. Invalid, Won't Fix, or Fix Released).
A simpler way would be a single stacked bar chart showing, for the past few months, the number of bug reports that remained in each unresolved status on each day; and below the X axis, the number of reports that were resolved in each way (fixed, declined, or marked as a duplicate) on that day. https://launchpadlibrarian.net/98323734/graphing.png
Probably it would save time to fix bug 37926 at the same time as doing this. |
|
| 2012-04-26 15:28:08 |
Evan |
tags |
feature lp-bugs |
feature lp-bugs rls-mgr-q-tracking |
|
