Changes to the bugzilla workflow: 2 proposals

[David Edmundson]

On Sun, Dec 11, 2016 at 9:35 PM, Luigi Toscano <luigi.toscano at tiscali.it>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20161212/c39486a3/attachment.htm>