Changes to the bugzilla workflow: 2 proposals

[Luigi Toscano]

On Monday, 12 December 2016 13:54:44 CET Boudewijn Rempt wrote:
> On Mon, 12 Dec 2016, Luigi Toscano wrote:
> > You could intercept them by filtering the content of the X-Bugzilla-Flags:
> > header.
> 
> Okay.
> 
> > It may not bring immediate benefits for everyone, and of course some
> > people
> > would not benefit from it, but if there are no regressions I think it
> > would be beneficial anyway.
> 
> But what _are_ the benefits? I'm sure I must be missing something. Apart
> from the granularity of asking a specific person -- which I don't see as
> relevant or helpful.

You can ask to another person without adding explicitly to the bug. The flag 
is cleared after asking, so you don't have to go and check the list of pending 
NEEDINFO for answer if you miss the email.
This may not be relevant for you. It is for me at least.
Also, especially if you want to use more states as described below (TRIAGED, 
CONFIRMED, etc), you don't need to go forth and back from the NEEDINFO state 
if you need some information at some point in the later state. This is the 
case that makes me consider needinfo as not as a state as the others (it can 
break the workflow). Maybe it's not so visible when we have only one bug 
initial status that moves almost always to RESOLVED, but it is.

> 
> > > Not if you're talking about the keywords like in the top half of the
> > > screen, those are horrible. if I can have NEW/UNTRIAGED, NEW/TRIAGED,
> > > NEW/CONFIRMED like RESOLVED/WONTFIX or RESOLVED/FIXED, then that might
> > > work. But the easiest flow would ideally still be from NEW to TRIAGED
> > > to CONFIRMED to ASSIGNED to RESOLVED.
> > 
> > I don't think that adding more substate combination would improve things.
> 
> Well, I would like more states -- as I explained, NEW, TRIAGED, CONFIRMED,
> ASSIGNED, RESOLVED, NEEDINFO would cover all my needs. That's how a bug
> changes over time in my workflow.

See above for more benefit as needinfo flag in this case.

> 
> Substates could work, but would not be optimal.
> 
> > Is there a special reason why keywords are horrible?
> 
> * They're shown in a different location, the info block of the bug, so
> they're not meant for tracking state, and this is state. Keywords are for
> describing the bug.

I see.

> * The keywords we have are a mish-mash mixing all kinds of different things.
> * and they cannot be cleaned up without removing information from existing
> bugs.
They can be removed, it needs some work:
- if the information conveyed by the keyword was never relevant, remove it
- if it should be assigned to some other entity, move it there (with some 
automation)
That does not mean that it could not be done, it takes time. But this is a 
discussion for another time. I don't see them as horrible: for example, the 
status of Feature could be tracked there instead of priority. Regression is 
useful too.

-- 
Luigi