Changes to the bugzilla workflow: 2 proposals

[Boudewijn Rempt]

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.

> > 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. 

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.
* 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. 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org