Comment 14 for bug 655385

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' field: if its
assigned to someone, its in progress (but we don't know the rate
[today])
 - the thing being appropriate or not could be folded into the
next-action field, or could just be a 'mark invalid' widget that pops
up and lets you select invalid/wontfix/opinion) I have no opinion on
whats best here - I'm sure mpt and others will :)
 - the next action selection differs from the 'status' field by
talking about 'what next' rather than 'where has it gotten to'. This
would (I think) make it easier for folk wandering by to understand the
*implication* of a given state.
 - permission debates become more obvious: only someone that can
either develop themselves, or is acked as someone that can do so, can
mark a bug as waiting for a developer. Likewise, only someone that can
set it to those values in the first place could unset it (and this
wouldn't impact on usability, because the user can still mark the bug
as invalid due to it being a different dimension: we can set different
rules on it). bugs waiting for analysis don't need to be arbitrarily
touched etc.

In writing this I've become more convinced that having a checkbox
saying 'a bug supervisor has acked this' would be a band aid at best,
and missing the complex set of interacting problems we have with the
bug status field. Change in this area /costs/ a lot due to learning
overhead amongst all our users : if we're going to change it, I think
we should be bold, think hard about the problem (by which I mean lots
of discussion, user testing, use case and story analysis), and then go
and do something awesome.

In terms of how we get here, we can probably do everything I've
described purely at the UI level, with the exception of adding in
optional qa steps (but even then the db changes required would be
extremely modest.

-Rob