Re: Changes to the bugzilla workflow: 2 proposals

[Boudewijn Rempt]

On Mon, 12 Dec 2016, David Edmundson wrote:

> In terms of bugzilla workflow, we need to indicate 3 possible states of
> who we are waiting on:
> 
>  - needs bugzilla input from a developer (current unconfirmed)
>  - needs bugzilla input from the reporter (current needsinfo)
>  - doesn't require any further bugzilla input (current confirmed/resolved
> as appropriate)
> 

But are the states just there to reflect that we're waiting on something?

> I don't think it can be done in any fewer statuses, and I don't really see
> how it requires any more.

As I said before, and I handle the second-biggest KDE project in terms of 
new bugs per year, my workflow would be easier with more states, and I'll
describe them, instead of using existing terms: 

* new, haven't looked at it yet
* have looked at it, couldn't reproduce it or  couldn't understand it, but 
don't want to look at it again when I'm looking for new reports
* have looked at it, and I know the reporter hasn't told me everything I need 
yet
* have looked at it and I know what is going on
* have started working on it
* have finished with the darn thing
* never want to look at the report again, it was dumb (well, that's the same I 
have finished with the darn thing)

> Not arguing, but it's worth noting this was a deliberate default change
> between bugzilla 3 and bugzilla 4.

On a tangent, but something I've wanted to bring up for long time...

Yeah, they're nuts. Well, maybe not nuts, but bugzilla is a poster-child
of rudeness towards people who want to help. RESOLVED/WONTFIX, RESOLVED/
INVALID -- that all reads as "BUGGEROFF/YOUIDIOT. 

A bug tracker is in the first place a tool to help me, as a developer, be more
efficient in improving my software, but a very close second it's a marketing
tool, and a recruitement tool and a customer retention tool. It's one of the
most direct ways to stay in touch with our user base, with the users who are
fan enough that they scale the stairs to the Olympus and manage to make use
of a tool that must look like the Necronomicon to them. 

It's also a unique selling point, because with proprietary software, this
kind of contact is all but impossible.

I've said it before, but I _love_ and _admire_ everyone who reports a
bug in bugs.kde.org!
-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Changes to the bugzilla workflow: 2 proposals

[David Edmundson]

On Sun, Dec 11, 2016 at 9:35 PM, 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.
>
> This is implemented on various instances of bugzilla (mozilla.org,
> redhat.com,
> opensuse.org) and allows the requester to set a needinfo on one or more
> specific user.
>
>
> In terms of bugzilla workflow, we need to indicate 3 possible states of
who we are waiting on:

 - needs bugzilla input from a developer (current unconfirmed)
 - needs bugzilla input from the reporter (current needsinfo)
 - doesn't require any further bugzilla input (current confirmed/resolved
as appropriate)

I don't think it can be done in any fewer statuses, and I don't really see
how it requires any more.


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

Not arguing, but it's worth noting this was a deliberate default change
between bugzilla 3 and bugzilla 4.

Whether they have new or not, is probably an indication of how old that
project's bugzilla instance is.
They document the reason here:
https://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-default-status-workflow/

However, we have another problem: You can rename every status in bugzilla
except this one...
http://bugzilla.readthedocs.io/en/latest/administering/workflow.html

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

That's quite clearly 3 proposals. I'll report a bug :P

FWIW that's bugzilla 4/5's default "INPROGRESS".

David

Re: Changes to the bugzilla workflow: 2 proposals

[Boudewijn Rempt]

On Mon, 12 Dec 2016, Luigi Toscano wrote:

> You could intercept them by filtering the content of the X-Bugzilla-Flags: 
> header.

Okay.

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

But what _are_ the benefits? I'm sure I must be missing something. Apart from
the granularity of asking a specific person -- which I don't see as relevant
or helpful.

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

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. 

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.
* 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. 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Changes to the bugzilla workflow: 2 proposals

[Boudewijn Rempt]

On Mon, 12 Dec 2016, Martin Gräßlin wrote:

> No, that would affect more. For example when looking for a bug report I go to
> bugs.kde.org, Browse, kwin, component and then have a very small list of the
> bugs for that component and can find the bug report.
> 
> If all the nonsentical needsinfo bugs get in there and are not hidden by
> default, it gets completely useless.
> 
> Also I don't want to be at 1000 open bug reports in a year. Consider the
> social impact of that if weekly-bug-summary stats include those bugs.

Fortunately, in that case, the weekly info page has disappeared from
the front page... But yes, needinfo is a category that applies to a bug,
it isn't just "I have a question for this person who reported or commented
on this bug" -- it's this bug report is useless without further info.

Now, if the status automatically changed back if info was added, that would
be a nice improvement.

> 
> Please note that in case of KWin a needsinfo means we never hear back in 99
> out of 100 cases and as I mentioned before we get several of those per day. My
> bug workflow is completely focused only on marking bugs as needsinfo. Yes,
> it's broken and yes for a high profile product like KWin it's even worse.
> 
> So any change of the process must ensure that we are not swamped in useless
> bug reports destroying all the default views and stats bugzilla provides.
> 
> Overall from what I read in this thread so far about it, I'm quite against
> this change. For me the focus is on getting those bugs away as I know that we
> won't get the backtrace. Try asking Arch users for a backtrace...
> 

I have to agree. Krita (+1075, -1210) isn't in the plasmashell category of 
bugs (+2341, -2101) per year yet, but it's more than kwin (+646, -680), and 
bugzilla's workflow needs to be as simple as possible to support me. I don't
think changing the way needinfo works simplifies my workflow.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Changes to the bugzilla workflow: 2 proposals

[Boudewijn Rempt]

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. 

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.

> 
> 
> > > 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 anyone seriously uses the VERIFIED and CLOSED stages, to me
those are just bureaucracy.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Changes to the bugzilla workflow: 2 proposals

[Martin Gräßlin]

Am 2016-12-12 11:55, schrieb Luigi Toscano:

On Monday, 12 December 2016 03:51:31 CET Nicolás Alvarez wrote:

> El 12 dic 2016, a las 03:39, Martin Gräßlin  escribió:
>
> Am 2016-12-11 22:35, schrieb Luigi Toscano:
>> a) use the "needinfo" flag instead of the NEEDINFO status.
>> This is implemented on various instances of bugzilla (mozilla.org,
>> redhat.com, opensuse.org) and allows the requester to set a needinfo on
>> one or more specific user.
>
> What does it mean to the state of "Open" bugs? What I like about the
> RESOLVED NEEDSINFO is that it hides the bugs from my search lists. If the
> bugs would still be shown, it would completely destroy the search for me
> (KWin currently gets 1-3 crash reports by Arch users per day).
I think you would be able to change your searches to take "doesn't 
have a

'needsinfo' flag" into account.


Exactly. You would need only a one-time change to your saved 
search(es).


No, that would affect more. For example when looking for a bug report I 
go to bugs.kde.org, Browse, kwin, component and then have a very small 
list of the bugs for that component and can find the bug report.


If all the nonsentical needsinfo bugs get in there and are not hidden by 
default, it gets completely useless.


Also I don't want to be at 1000 open bug reports in a year. Consider the 
social impact of that if weekly-bug-summary stats include those bugs.


Please note that in case of KWin a needsinfo means we never hear back in 
99 out of 100 cases and as I mentioned before we get several of those 
per day. My bug workflow is completely focused only on marking bugs as 
needsinfo. Yes, it's broken and yes for a high profile product like KWin 
it's even worse.


So any change of the process must ensure that we are not swamped in 
useless bug reports destroying all the default views and stats bugzilla 
provides.


Overall from what I read in this thread so far about it, I'm quite 
against this change. For me the focus is on getting those bugs away as I 
know that we won't get the backtrace. Try asking Arch users for a 
backtrace...


Cheers
Martin

Re: Changes to the bugzilla workflow: 2 proposals

[Luigi Toscano]

On Monday, 12 December 2016 19:34:55 CET Eike Hein wrote:
> On 12/12/2016 07:27 PM, Elvis Angelaccio wrote:
> > On Sun, Dec 11, 2016 at 10:35 PM, Luigi Toscano
> > 
> >  wrote:
> >> 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.> 
> > Don't we already have the ASSIGNED state? I just checked and I can
> > select it from the left dropdown menu.
> 
> Correct, we have that and use it quite a bit imho.

Oh, sorry, I did not check. It would be a matter of changing the policy then.

-- 
Luigi

Re: Changes to the bugzilla workflow: 2 proposals

[Eike Hein]

On 12/12/2016 07:27 PM, Elvis Angelaccio wrote:
> On Sun, Dec 11, 2016 at 10:35 PM, Luigi Toscano
>  wrote:
>> 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.
> 
> Don't we already have the ASSIGNED state? I just checked and I can
> select it from the left dropdown menu.

Correct, we have that and use it quite a bit imho.


Cheers,
Eike

Re: Changes to the bugzilla workflow: 2 proposals

[Boudewijn Rempt]

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.

> 
> This is implemented on various instances of bugzilla (mozilla.org, redhat.com,
> opensuse.org) and allows the requester to set a needinfo on one or more
> specific user.
> 
> 
> 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.


-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org