Changes to the bugzilla workflow: 2 proposals

[Luigi Toscano]

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.


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


-- 
Luigi