Changes to the bugzilla workflow: 2 proposals
Boudewijn Rempt
boud at valdyas.org
Mon Dec 12 13:31:25 GMT 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