On Monday, 12 December 2016 12:49:32 CET Boudewijn Rempt wrote: > On Mon, 12 Dec 2016, Luigi Toscano wrote: > > On Monday, 12 December 2016 10:22:37 CET Boudewijn Rempt wrote: > > > On Sun, 11 Dec 2016, Luigi Toscano wrote: > > > > Hi, > > > > > > > > I would like to propose two changes to the Bugzilla workflow for our > > > > instance on bugs.kde.org. The two proposals are totally independent > > > > from > > > > each other. > > > > > > > > a) use the "needinfo" flag instead of the NEEDINFO status. > > > > > > I wouldn't like that. I'm with Martin here -- NEEDINFO is an essential > > > part > > > of my workflow, and I'm not interested in fine-grained asking info from > > > one > > > particular person in the bug thread. > > > > If you want to filter the bugs with needinfo, you can still do it (see the > > other answer on this thread), so this would not disrupt your queries. > > Even if you are not interested in more detailed needinfo, others could be. > > Wit the targeted needinfo it is *possible* to define periodic reminder > > emails too. > What about the mails? I filter all my bugzilla mail into new, changed and > needinfo folder with pine.
You could intercept them by filtering the content of the X-Bugzilla-Flags: header. > > In any case, I don't see any improvements here -- not for my workflow. I > guess I can adapt, and I'm fine with having to do that, but it's not like > there's anything useful for me in return. 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. > > > > > b) change back the initial state from UNCONFIRMED to NEW. > > > > > > > > This was the default until Bugzilla 3. But Many of our developers > > > > don't > > > > really use the UNCONFIRMED->CONFIRMED transition and this confuses the > > > > users. Moreover, NEW is still the initial status on various bugzilla > > > > instances. I would introduce an ASSIGNED state so that developers that > > > > want to mark that they have acknowledged it and they are going to work > > > > on > > > > it can do it. > > > > > > > > What do you think? > > > > > > I'm fine with adding NEW, my workflow currently misses a stage between > > > UNCONFIRMED and CONFIRMED that means "I looked at the bug report, but > > > couldn't confirm, and I don't want to look at it again any time soon", > > > so > > > going from NEW to UNCONFIRMED to CONFIRMED would be good for me. I don't > > > need an ASSIGNED stage, I don't even assign bugs these days; as soon as > > > someone starts to work on them, I make a phabricator task. > > > > Would NEW + a keyword (Triaged, InitialTriage) work for this case? > > 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. Is there a special reason why keywords are horrible? > > I don't think anyone seriously uses the VERIFIED and CLOSED stages, to me > those are just bureaucracy. I think they are just part of the default set of states, and we don't use them currently (which does not mean that they are not useful in general). -- Luigi