2008-09-09 12:53:48 |
Björn Tillenius |
malone: statusexplanation |
Morten, it's good for all projects using Launchpad to have the same bug statuses, because that improves collaboration between projects -- when a bug report is filed against both project X and distribution Y, a contributor to either of them can understand the status in the other.
So if we're going to give up that benefit, I think we really do need, as Diogo requested, examples of actual problems that this would solve.
You mention some real problems that can be solved in less complex ways:
* Confusion about how bug statuses should be used can be addressed by making status definitions available from the bug page (bug 29495). It would not be solved by introducing group statuses; how would people know what *those* meant? :-)
* People forgetting exactly which tags are used can be addressed by making common tags easily selectable on the bug-reporting page (bug 184737), the search page (bug 83736), and the bug report page (bug 98585).
* The list of tags being very long (making it harder, for example, for you to have realized that we use the "bugtag" tag) can be addressed by showing only the common tags (bug 59154).
One problem you mention that doesn't have a planned solution is that it's not obvious what a particular tag means. That's true, and perhaps we should solve it, and maybe group statuses or group tags would solve other problems, but I don't see how they would solve that problem in particular.
In bug 193585 I gave examples of problems that could be solved by having tags that teams can control without interference by non-members. Is that the problem you're concerned with? If so, this could be a duplicate. |
I'm closing this due to lack of use cases. I agree with Matthew, and I think most of the use cases can be solved by other means than adding a group-status field. |
|