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