users can move bugs out of Triaged status, but not back in

[Vish]

New lp users unfamiliar with bug triage often end-up confusing the bug statuses Triaged and Confimed.
They seem to consider Triaged as a status that is lower than confirmed or a bug that needs to be confirmed yet. [Ex: Bug #323815 ]

As you can see in the above example, the bug status had to be reverted nearly one yr after the status was changed from Triaged > Confirmed.
There are several such instances of the status being confused.

Since Triaged is a status available only to Bug Control it might be better to allow changes *from* triaged also only to BugControl Members.

[Matthew Paul Thomas (mpt)]

"Allow bug status change from Triaged, only for BugControl" is one possible solution to the bug. It is not the bug itself. There are other possible solutions: for example, merging Confirmed and Triaged, or renaming Triaged to something less redundant.

[Vish (vish)]

Merging, confirmed and triaged , not sure thats a great option or really an option.

Renaming "triaged" to something else, we can keep bikeshredding this for *ever*. Also, this would need to be changed in the docs everywhere and everyone would need to re-learn this new name/status.

However, a quicker option would be blocking this change for non-BC members..
Renaming or blocking, whichever we can get done sooner is good.

[Deryck Hodge (deryck)]

I agree with mpt's assessment here, but I don't see the harm in ACL'ing Triaged so only bug supervisor can change a bug task status out of Triaged. Only bug supervisor can set Triaged, so it makes sense only bug supervisor should be able to un-set it. I thought it was already this way in fact.

Having a look now, it seems we only check WONTFIX to prevent someone other than bug supervisor unsetting it. All bug supervisor statuses, which would include EXPIRED and TRIAGED, should be included in this check. An easy fix!

[William Grant (wgrant)]

Forbidding unprivileged accounts from changing the status from Triaged will negatively impact users when fixing bugs themselves (marking the bug In Progress), or discovering that a bug is already fixed (marking it Fix Released).

[Deryck Hodge (deryck)]

Yeah, good point. We could make an exception for those two conditions, if we don't mind the more complicated code.

[Vish (vish)]

Oh goody, another example for today : Bug #658798 .. :-/

Maybe for the long term we need to think about giving it a better name too, but that is the second part of this bug as deryck mentions. So filed Bug #659947 for that renaming .

[Curtis Hovey (sinzui)]

This cannot be limited to the role of bug supervisor. I think all users in project roles like maintainer and driver, and the bug assignee need permission to do their job.

[Brian Murray (brian-murray)]

I started working on this and upon further consideration I don't think it is a good idea anymore. Restricting who can transition a bug task from a Triaged status reduces the quantity of people who can do useful bug work which isn't something that we want. Consider the case of an upstream developer who is working on bug reports about their package in Ubuntu - should they have to join the bug supervisor team to be able to set a bug report to any bug status? (Yes, we could limit which statuses a Triaged bug task can move to but to what? Confirmed is the only one that makes sense to me and coding that seems a bit silly.)

Additionally, I decided to look at the scope of the problem (as originally described) by looking at the ubuntu-bugs mailing list mboxes.
2011-01
543 bug tasks transitioned from the Triaged state to something else
   10 of those were to Confirmed
2011-02
506 bug tasks transitioned from the Triaged state to something else
   12 of those were to Confirmed

So I think adding this restriction to Launchpad would actually cause more harm than good and while something should be done to make bug statuses less confusing in the meantime incorrect changes to bug task statuses should be handled socially.

[Andrea Corbellini (andrea.corbellini)]

In bug #659947 I've proposed to drop the Triaged status, and instead keep Confirmed, adding a checkbox "This bug has been checked by a bug supervisor". This solution would make it clear what the status of a bug is (for reporters and lurkers) and whether a developer can start working on it (for developers).

I think this solution will solve this bug too, because users will no longer confuse Confirmed with Triaged and so won't need to change between this two statuses.

[Robert Collins (lifeless)]

On Thu, Mar 17, 2011 at 9:35 PM, Andrea Corbellini
<email address hidden> wrote:
> In bug #659947 I've proposed to drop the Triaged status, and instead
> keep Confirmed, adding a checkbox "This bug has been checked by a bug
> supervisor". This solution would make it clear what the status of a bug
> is (for reporters and lurkers) and whether a developer can start working
> on it (for developers).
>
> I think this solution will solve this bug too, because users will no
> longer confuse Confirmed with Triaged and so won't need to change
> between this two statuses.

A problem with that solution is that it the separation between bug
supervisor and developer is pretty much entirely artificial - I'm not
aware of any project (other than Ubuntu) using it at all - and AFAICT
most ubuntu devs don't particularly care about the confirmed/triaged
distinction anyhow...

[Martin Pool (mbp)]

On 17 March 2011 19:35, Andrea Corbellini <email address hidden> wrote:
> In bug #659947 I've proposed to drop the Triaged status, and instead
> keep Confirmed, adding a checkbox "This bug has been checked by a bug
> supervisor". This solution would make it clear what the status of a bug
> is (for reporters and lurkers) and whether a developer can start working
> on it (for developers).

I like that idea.

[Vish (vish)]

On Tue, 2011-03-15 at 21:07 +0000, Brian Murray wrote:
> Additionally, I decided to look at the scope of the problem (as originally described) by looking at the ubuntu-bugs mailing list mboxes.
> 2011-01
> 543 bug tasks transitioned from the Triaged state to something else
> 10 of those were to Confirmed
> 2011-02
> 506 bug tasks transitioned from the Triaged state to something else
> 12 of those were to Confirmed
>

Interesting results there...
What would be interesting, is to split out of the total numbers(500+)
the change in status done by Launchpad bug janitor.
I would expect at least 100 bug fixes in a day? (Several Triaged -> Fix
Released would have been automatically by the janitor.)

It would also be great to see the rest of the breakdown.
We could see which status we can allow non-bug-supervisors to set. Maybe
Inprogress/FixReleased/Invalid or a few other ones..?

It was mentioned earlier to just allow status changes to a few other
states excluding "confirmed".

> So I think adding this restriction to Launchpad would actually cause
> more harm than good and while something should be done to make bug
> statuses less confusing in the meantime incorrect changes to bug task
> statuses should be handled socially.
>

I dont think handling socially is feasible, seeing that atleast 10bugs
are converted everyday.
One could expect atleast 1 bug/day change is done by someone not knowing
the difference between Triaged/Confirmed.

That means someone somewhere has to explain what the difference is,
*everyday*..

We could probably look at fixing this in Bug 659947 by removing the
triaged status all together? Or Maybe what Andrea says..

[Andrea Corbellini (andrea.corbellini)]

On Thu, 2011-03-17 at 22:12 +1300, Robert Collins wrote:
> A problem with that solution is that it the separation between bug
> supervisor and developer is pretty much entirely artificial - I'm not
> aware of any project (other than Ubuntu) using it at all - and AFAICT
> most ubuntu devs don't particularly care about the confirmed/triaged
> distinction anyhow...

Well, the fact that developers don't care about the two statuses is
probably true. However, currently, the Triaged status is not only useful
to developers, but also to bug supervisors who need to know whether a
bug needs work or not. Giving that there are probably hundreds of bugs
filed every week in Ubuntu, some sort of Triaged status is essential to
bug supervisors (at least in Ubuntu), and I hope we all agree on this.

[Robert Collins (lifeless)]

On Thu, Mar 17, 2011 at 10:59 PM, Andrea Corbellini
<email address hidden> wrote:
> On Thu, 2011-03-17 at 22:12 +1300, Robert Collins wrote:
>> A problem with that solution is that it the separation between bug
>> supervisor and developer is pretty much entirely artificial - I'm not
>> aware of any project (other than Ubuntu) using it at all - and AFAICT
>> most ubuntu devs don't particularly care about the confirmed/triaged
>> distinction anyhow...
>
> Well, the fact that developers don't care about the two statuses is
> probably true. However, currently, the Triaged status is not only useful
> to developers, but also to bug supervisors who need to know whether a
> bug needs work or not. Giving that there are probably hundreds of bugs
> filed every week in Ubuntu, some sort of Triaged status is essential to
> bug supervisors (at least in Ubuntu), and I hope we all agree on this.

I agree that being able to split the analysis / coding tasks is good
in theory. However in practice those folk that don't know enough to do
the code rarely know enough to do the analysis accurately. We get
regular discussions on this in e.g. #ubuntu-devel, and its not at all
clear that the current practice in Ubuntu of encouraging new
contributors to do widespread bug analysis is a net positive for the
project. We often have to chase down and halt new triagers, for
instance. Ask Colin Watson about folk triaging Ubiquity :). Beyond
that thorny question, we have very similar requests for the ability to
disable duplicate detection, and disable commenting on bugs that a
person didn't file in packages like the kernel, where many defects may
have the same symptoms, but not be duplicates or even related at all.

The bearing this has on your proposal is that in all these cases there
is a strong desire *not to have* bug supervisors doing analysis unless
they are also capable of doing the work: there's no particular need to
separate 'now a developer can look at it' from 'the last comment was
from the person filing the bug'.

Consider this model of the state of a bug:
not valid as a bug
needs response from reporter/other affected people
needs analysis
queued
being worked on
done

mapping those to our current labels:
not valid as a bug - rejected, opinion, invalid
needs response - INCOMPLETE-WITHOUT-RESPONSE
needs analysis - NEW, CONFIRMED, INCOMPLETE-WITH-RESPONSE
queued - TRIAGED
being worked on - INPROGRESS
done - FIX COMMITTED, FIX RELEASED

It seems clear to me that *at any point* a response may be needed from
the reporter/other affected people. So perhaps these things really are
in different dimensions:
- what action is needed next (which also implies who is action needed by)
  - more information (filer/affected)
  - analysis (for projects/packages that *want* to have analysis
happen separately from development)
  - development
  - validation (this is something various projects are asking for)
  - release
  - no action: done
- is the thing appropriate to track as a bug in this location (yes/no
- with several labels that all mean no)
- does someone have a lock on it (e.g. assignee)

How might this look in practice?
 - someone having a lock is our existing 'assignee'...

[Brian Murray (brian-murray)]

Vish - here are the csv files of activity I was looking at - the format is bug number, transition (from the email body), x-launchpad-bug-modifier (launchpad username), date of the transition. From what I saw the vast majority of transitions were by people who are bug supervisors.

[Martin Pool (mbp)]

I think there is a real bug here: people change the bug state, either through misunderstanding its meaning, misunderstanding the state of the bug, or simply misclicking. Then they cannot undo their change. This is bad.

The original proposal of preventing changes out of Triaged may not be a good solution but the bug still exists and is regularly hit.