Users, unfamiliar with bug-triage, often confuse 'Triaged' and 'Confirmed' status

Hi, Vish.

I'm not sure I agree we should rename Triaged. I need suggestions for an alternate name before I can say for sure, and even then, it needs to be a pretty compelling renaming to make it worth the social trouble of renaming a status. In short, I'll be really reluctant to do this, and so I'm inclined to mark this Won't Fix.

I do, however, like the idea of tracking that the distinction between Triaged and Confirmed is confusing for users. I thought we had a bug like this already, but I can't find it. Do you mind if we re-purpose this bug for the root issue itself, or do you want this bug only to track the request that we rename Triaged?

Cheers.
deryck

deryck, were you looking for Bug #655385 ?
Thats the one i had filed initially for this, preventing the users from changing triaged bugs should keep me happy enough. ;-)

I do understand what "Triage" means its not an issue for me, and I dont have a reasonable alternative for triaged either.

However , there are several such bugs where i have noticed this "pattern of misunderstanding" . Bug #625193 is another such example, the 'triaged' status got changed several times on that bug. ;-) .
And since we have an international audience, we might need to think of a better alternative too. Other triagers have noticed this issue too. We could discuss this on a mailing list somewhere?
Bug #655385 would be a higher priority IMO, once that gets fixed we can probably review/re-access this renaming later?

How about a simple help box explaining the statuses, similar to the one for Bug Heat?

@Vish, I knew about your first bug. There still isn't a bug for the general problem of "people confuse Triaged and Confirmed." Your first bug asked for limiting who can change out of Triaged status, this one asks for the status to be renamed. I'm suggesting that I'd like a bug to track the main issue. If you want want a decision now on changing the name, then I'll mark this won't fix and open a new bug tracking the main issue.

@Micah, maybe a pop up can help. We have to be careful, though. Fix Released has slightly different meanings for Launchpad and Ubuntu, for example. Some groups want Triaged set when the fix is known, others when the problem is understood. So clearly there is a common definition at the root, but we don't want to prescribe usage, I don't think.

deryck, re-titled the bug, Lets address the main issue. :-)

We could do with a way to measure the situation. Any change from Triaged to Confirmed is a bit suspicious. Perhaps we should graph those transitions before we start making changes?

We can probably do something incredibly simple at first, like a tool-tip on the status in the bugtask table, or the pop-up that Micah suggests. Then we watch the graph to see the effect.

Also, I've always thought of Triaged as "Confirmed with an importance". I'm almost inclined to say that Triaged should be a pseudo status that means exactly that. But that's a big change, and I have the sense that a lot of people are accustomed to using the Triaged status to mean something other than triaged (though that's something we might be able to measure too).

Right now I doubt this bug is a huge problem, but some sort of graph might show otherwise, and so would be a good first step.

People often think they need just one more bug status, so bug trackers gradually accumulate them, thereby becoming harder and harder to adopt for people who don't already use them. Launchpad currently has eleven bug statuses (or eleven and a half, if you count "Incomplete with response"). It would work just fine with only six.

I've always thought "Triaged" was a bit pointless, for the reason Gavin just gave: triaging is the process of deciding how important something is, and we can already tell whether that's happened from the Importance field. So whenever I've used "Triaged", I've pretended that it said "Ready", as in ready to fix: the problem is reproducible, and the correct behavior is either obvious or in a specification.

Like, mpt, I would prefer we converge on less statuses. I think that is the best way to fix this bug, but I also think doing some research to confirm the severity is worthwhile. Until we have data, I'll mark this as of low importance for the bugs team to work on.

Well, another instance of user confusion of the day > Bug 160311 comment #206 .

When we have a status for "Opinion" I dont think mpt's suggestion applies to this bug.. ;-)
Lets remove 'Opinion' and keep 'Triaged'.
We make it easy for *anyone* to confirm a bug, irrespective of the bug having sufficient info or not.
If we merge confirmed and triaged without making changes about who confirms a bug , bug triage will get very tough!

Or we lock-down all bug status like gnome bugzilla.

Personally, I do not like the distinction between Confirmed and Triaged too. However I think that merging them would be very complicated, and this would be a long-term solution. This bug is about people making confusion with the statuses, so a short-term solution is needed. I found two possible solutions that do not need to remove bug statuses, and therefore should be easy to implement:

1. rename "Triaged" to "Confirmed (triaged)";
2. show a confirmation dialog when a user sets the status of a bug from Triaged to Confirmed/New.

Or rename "Triaged" to "Confirmed(with info)"

We know there is enough information when a member of the project could set the bug priority. Triaged can be deduced by know that the user who set the confirmed status is a member of the project and the priority is set.

@Curtis Hovey : Thats a *very* interesting suggestion!
Setting the importance can be considered a sign of triage completed for the bug.
However, this change would mean changing the bug workflow for several teams:
- Some of the teams set bug importance *immediately* , and bug status is left as 'new'. Sometimes the questions are asked only later and bug maybe marked 'incomplete' at which point.
- This 'setting-bug-importance-immediately' is also recommended to new bug triagers who enter BugControl.
- Apport-retracer sets bug importance immediately to medium once the crash has been retraced. (This would need to be changed)
[I'm not sure if I have missed any other use cases.]

While i very much like the idea, and would have subscribed the relevant desktop, apport and qa team members to comment on the suggestion, I would like to see what the other LP bugs team members think about this suggestion.
Once the lp team considers this a favorable suggestion, we can ask the relevant teams for comments regarding this.

This would trim down the bug statuses but might need a little bit of adjustment for the teams.
But this change, might be:
- lesser bug work for the teams (no need to visit bug twice, once for setting importance and later for final triage) and
- might be lesser number of 'status/importance-change' emails received too.
- lesser need for teams to explain the status difference.

Heh, i just noticed that's what mpt tried to mention earlier(comment#7).. But somehow, Curtis saying it sounded nicer/clearer... ;p

I often set bug importance immediately when the issue is severe. I occasionally subscribe a experts to the bug and ask them to triage the bug after setting the importance to high so that they know we need to know if the issue will jump the queue of bugs.

I think we should as a page on help.launchpad.net that describes successful ways to triage.

Regarding changing the workflow and setting the importance only to indicate a 'complete triage' , I think we might have a tough time convincing Brian Murray (https://lists.ubuntu.com/archives/ubuntu-devel/2011-February/032424.html) and Kate Stewart (https://lists.ubuntu.com/archives/ubuntu-devel/2011-February/032419.html).
Both seem to favor the idea of setting importances immediately.

Brian and Kates concerns are about bugs being dropped when they are
earmarked via nominations; thats completely compatible with the
outcomes being proposed in this bug.

For mistake, I filed bug #735754, which contains a proposed solution to this issue:

I propose to merge Triaged with Confirmed and add somewhere a checkbox with a label similar to this one: "A bug supervisor for this project believes that this bug report contains enough information for a developer".

Perhaps we need to go back and ask what user stories there are around "Triaged" and how much people care about them. Then we can work out whether a checkbox as Andrea suggests would satisfy them better, or adequately.

It may be there are some developers who really need to indicate "a developer has agreed this is a real bug" in a way that cannot be faked (or accidentally clicked) by users. Who are these developers? It's asserted in bug 735754 that Ubuntu developers don't care about this. If we know more about what they want (and whether anyone cares) we can decide whether a checkbox would be enough, etc.

Launchpad already has a fair number of hidden access-control rules; as jml said the other day it would be nice to have less rather than adding more.

Confused or malicious users can and do make random changes to bugs, and people seem to cope with them by reverting them, gently correcting the user, or admin intervention. Is setting it to Triaged in particular need of protection?

Some teams use assignment to the team, or subscription of the team, to indicate the bug is in a particular state, and the first of those can (I think) only be done by team members.

See also https://dev.launchpad.net/IssueTracker.

> Confused or malicious users can and do make random changes to bugs, and
> people seem to cope with them by reverting them, gently correcting the
> user, or admin intervention.  Is setting it to Triaged in particular
> need of protection?

We regularly get cases where one person doing their own view of the
'right thing' causes many hours or days worth of work for core devs
undoing that persons changes. LP doesn't throttle folk making lots of
changes, and this makes social training ineffective fairly often.
Additionally LP's habit of not letting mistakes be undone means bugs
accrue lots of noise. (Look at bug 1, for instance).

On 17 March 2011 22:38, Robert Collins <email address hidden> wrote:
>> Confused or malicious users can and do make random changes to bugs, and
>> people seem to cope with them by reverting them, gently correcting the
>> user, or admin intervention.  Is setting it to Triaged in particular
>> need of protection?
>
> We regularly get cases where one person doing their own view of the
> 'right thing' causes many hours or days worth of work for core devs
> undoing that persons changes. LP doesn't throttle folk making lots of
> changes, and this makes social training ineffective fairly often.
> Additionally LP's habit of not letting mistakes be undone means bugs
> accrue lots of noise. (Look at bug 1, for instance).

Yes, I agree very much that this does occur and does cause problems.
Also I think Launchpad could do some things to discourage noise
changes and to make them easier to undo.

But I question whether having a specific restriction around the
Triaged state is really helping with this.

A misguided change into the Triaged state is no more harmful than
other changes people can make (eg Triaged->Invaild, Confirmed->Fix
Released) and it is trivial to undo (by contrast to eg adding
comments).

In fact, the presence of this mechanism makes noise changes to status
more harmful, because only privileged developers can undo some of
them.

Another point to note here -
triaged as say Launchpad uses it (an importance has been assigned), and triage as Ubuntu -sometimes- uses it (Ready to code and importance assigned) are two -totally- different things.

As I see it:
 - folk wanting to triage (actual triage) should be able to do so, and have triaged bugs get out of their way from then on.
 - being able to say 'the right thing for this issue is X' is unrelated to its importance, whether the issue has been seen by multiple users or not.

So the harm in the system at the moment is two-fold:
 - Ubuntu (and others) conflated 'importance assigned' with 'ready to act on' (triaged-as-ready-for-a-developer-to-execute)
 - Confirmed and Triaged are shown in the same dimension, so folk have to choose between them.

I think even "ready to act on" is not a single status:

 * most notably in unity, there are some bugs that are ready to be
acted upon by someone (the design team) but not ready to be
implemented in code. (It seems like that ought to map to assignment,
but presumably they have reasons to do otherwise.)
 * a bug can be "accepted" as valid, yet also incomplete if more
information is needed.
 * once an authority has accepted a bug as valid, other people should
not be able to accidentally or consequentially undo that (eg this bug,
also going triaged->incomplete->....?)

One option would be to model this similarly to Nominate/Accept, and
let projects if they wish look at bugs and specifically Accept or
Decline them, orthogonally to them being new/confirmed/incomplete and
to having an importance assigned.