Groups should have a group-status field at their disposal

Hi Morten,

thank you for the report. The "Status" pulldown menu options are restricted according to team membership. For instance, for ubuntu bugs, anyone can access the following status: "New", "Invalid", "Incomplete", "Confirmed", "In Progress", "Fix Committed" and "Fix Released". The status "Triaged" and "Won't Fix" are restricted to the project maintainer and bug supervisor group.

You could use bug tags for the second suggestion,

In summary, the first suggestion is already implemented and the second one could be solved using existing infrastructure.

I'm setting this to Incomplete for now, so we can outline the issue better.

Thanks,

I agree that it is in principle possible to use tags, but in practice it doesn't work as well, because people tend to forget which ones are in use, and how their exact spelling is.

The list of tags in Malone is very long and most are only used by one or two entries, and scrolling through it rarely gives you an idea what tag is used for what.

The group status field would be more user-friendly, since it would give you a limited number of options, and options that you know are actively in use by the team.

I suppose group tags could be implemented using tags "behind the scenes".

Check https://edge.launchpad.net/launchpad-project/+bugs?field.tag=bugtag for a list of bugs filed regarding our tag implementation. Some of the things you outline are indeed limitations in the current implementation.

Notice that we're discussing the solution to a undefined problem. What is exactly the problem we're trying to solve here? Let's first define the problem and then discuss the possible solutions.

Thanks

Actually, this is not really a problem that needs to be solved, but rather an improved functionality.

The goal is to enable teams to label bug reports in a more structured manner, by enhancing/extending the options given by the generic and built-in "Status" information.

You refer to the "bugtag" tag in your post, but without knowing that this is indeed actively used to classify certain bug reports, it is useless. However, if I could choose "bugtag" as a possible search term in to "Launchpad Bugs" I might have decided to have a look.

Reading the list of bug reports tagged with "bugtag" that you refer to, it is clear that several users ask for a more structured and customizable way to use tags. I originally suggested a "group" field, but that same functionality could just as well be implemented on top of the tag system.

So, to illustrate the point -- but not to advocate one particular implementation -- I imagine the following scenario:

A team owner -- or even any user -- is allowed to select a limited number of tags -- private to that team (or user). These labels/tags appear in a combo-box next to the Status, Milestone and Importance fields, and members of the team can select one (perhaps several) of them. This enables the team to define and make use of a workflow most suitable for that team.

By providing this customizable extension, the bug tracking system can be used in ways that do not necessarily need to be foreseen by the developers.

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.