Changes to the bugzilla workflow: 2 proposals

Boudewijn Rempt boud at valdyas.org
Mon Dec 12 13:31:25 UTC 2016


On Mon, 12 Dec 2016, Luigi Toscano wrote:

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

So, if someone answers, the flag gets clear? That might be quite useful, though
I get my answers sorted into a special mailbox, which also works.

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

That's a really good point. In that sense, NEEDINFO is weird indeed.

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

Okay, but I would still like to have a TRIAGED state in between NEW and CONFIRMED :-)

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

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



More information about the kde-community mailing list