Changes to the bugzilla workflow: 2 proposals

[Luigi Toscano]

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