← Back to team overview

ubuntu-bugcontrol team mailing list archive

Fwd: Re: Proposal to merge #ubuntu-quality and #ubuntu-bugs

 

To my amazement and shame, I did not copy BugControl on this email.

Sorry.

..C..
----------  Forwarded Message  ----------

Subject: Re: Proposal to merge #ubuntu-quality and #ubuntu-bugs
Date: Thursday, January 03, 2013, 12:25:01
From: C de-Avillez <hggdh2@xxxxxxxxxx>
To: ubuntu-bugsquad@xxxxxxxxxxxxxxxx
CC: Omer Akram <om26er@xxxxxxxxxx>, ubuntu-quality@xxxxxxxxxxxxxxxx

On Thursday, January 03, 2013 18:14:53 Omer Akram wrote:
> Hi All
> 
> Just recently there started a discussion on Ubuntu bug squad list about
> less people getting involved in bug triage along the discussion there were
> a few points raised which let me to put the idea of merging #ubuntu-quality
> and #ubuntu-bugs into one. Ultimately both have the same goal that is
> talking about quality in Ubuntu.

As said already elsewhere, joining -bugs and -quality is not ideal. Bugs (and 
triaging) is a subset of quality, and has specific issues; conflating both 
together is prone to generate more noise, with very specific discussions 
derailing the overall view of quality control/assurance.

Perhaps it would be more productive to review the whole process of bugs, 
triaging, etc.

For example:

* lack of quality/detail/references on bugs. A lot of bugs do not state the 
bare minimum needed (like Ubuntu version, package version, etc). Many, even 
when set to triaged, lack details on how to reproduce.

* lack of responsible parties. We should have teams/groups/whatever-you-want-
to-call-them that are responsible for triaging, tagging, raising attention on 
"areas of interest". One such area of interest could be, for example, the 
Ubuntu version (bugs that affect Lucid, or Precise, etc), another could be 
technology (email clients, email servers, browsers, KDE, Gnome (both under the 
Gnome shell and under Unity)), and so on.

* expanding apport hook usage. A *lot* of packages do not have apport hooks. 
The infrastructure is there, we need to use it.

* reviewing the bug work processes, and re-adjusting them. Bugs are technical 
reports of problems, and should be looked at, and worked on, as such. So, 
bugs.lp.net should not be the entry point for an user having a problem -- 
perhaps, answers.ubuntu.com should be it, and bugs would then be "promoted" 
from a.u.c.

And so on.

But -- let it be clear -- I agree with Omer: we have to do something.

Cheers,

..C..

-----------------------------------------

Attachment: signature.asc
Description: This is a digitally signed message part.