Triaging Revisited

Registered by C de-Avillez

This blueprint has been superseded. See the newer blueprint "BugSquad Roadmap" for updated plans.

This BP is based on the recent thread in -devel about bug expiring [1].

This is dear to me. All sides have merit, and I will summarise them
below (as of now):

* ScottK is against bug expiry, in any form, at all.
* Bryce considers that Incomplete-no-response bugs should be closed.
* cjwatson wonders why we let inexperienced people triage.

As far as I can see, all views have merit:
* bug expiry is bad: because the default search on LP does *NOT*
  select expired (or Fix Released, or Opinion, or Invalid, or WontFix)
  by default. This, from the PoV of triaging, is really not good. Of
  course, we can re-open an INVALID bug anytime, but we first have to
  *know* there is such a bug.

* Incomplete-no-responses bugs *should* be closed: if we have not
  enough data to work on it, there is no meaning in leaving it hanging
  around -- BUT ONLY as long as we can easily search on them.

* experience on triaging: Colin's views perfectly match mine, and my
  experience on support. One thing I always hated was this idea of
  having a call-desk manned by low-pay, low-knowledge, people that
  followed a script. You get out of the script and all hell breaks
  loose. A good example is pretty much *any* help-desk for Internet
  connections (Verizon comes to mind as a perfect example). Triage
  is NOT easy, and a good triager is worth her weight in gold.

These are all valid points. The problem is they are not mutually
exclusive: it is not a zero-one game.

We really, *really*, should look at it.

[1] https://lists.ubuntu.com/archives/ubuntu-devel/2010-October/031866.html

Blueprint information

Status:
Complete
Approver:
Marjo F. Mercado
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Superseded
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Marjo F. Mercado

Related branches

Sprints

Whiteboard

(?)

Work Items