Proposed changes to workflow bug management

[Morten Kjeldgaard]

On 30/05/2008, at 0.17, Scott Kitterman wrote:

> Sarcasm isn't particularly useful here.  Her assessment was harsh,  
> but I

You are right, I am sorry Caroline.

> think reasonably accurate with Tags as they are now.  Tag based  
> discovery
> is not, IMO, a good basis for process improvement without a redesign.

Redesign is the key phrase here. Tags may not be useful currently,  
but that's only because they've not been systematically employed.  
Basically, tags are small strings that can be used to filter searches  
on LP. They are a design feature that makes it possible to expand the  
UI in ways that were not originally envisaged when the schema was  
designed. So tags are not at all "useless".

We have a huge database of bugs, which are very different in  
character, but all the bugs are data points in the health status of  
Ubuntu. This discussion should really be about how to mine this  
database for useful information. It is actually a fascinating problem  
that we are trying to solve, which has never been done before,  
because no one has ever had access to such a database before.

For example, it was mentioned in another discussion that patch  
statuses are not necessarily the same as the bug status. A patch can  
be "invalid" where the bug itself is not. The connotation of this is  
that there are not enough status markers for bugs; there really  
should be one for patches as well. However, a solution to this  
problem could be achieved using tags in a systematic way; and this  
use could in principle be hard-wired into the GUI.

My point is, that if it can be agreed upon what searches (filterings)  
of the data we need to solve particular problems in the treatment,  
classification or workflow of bugs, that can be accomplished using tags.

Therefore, the main objective IMHO is to establish what kind of bug- 
filtering criterea would be useful to the various teams. What common  
bug properties would be useful to see? With tags, these filterings  
can be tried out in an ad hoc manner, and if proven useful,  
incorporated more formally.

> and training aids for new troagers.  I think triagers should start on
> things they are familiar with and expand out as they gain  
> experience.  If
> triagers would start narrowly, expand outwards as they learn, and  
> stop and
> ask if they hit something unfamilair, I think the incidence of  
> issues with
> workflow bugs would drop to acceptable levels.

I agree. But this does not exclude that we also attempt to  
incorporate the accumulated experience and knowledge of seasoned bug- 
triagers and developers into the UI of the LP database.

Cheers,
Morten