Bugzilla upstream workflow changes, and our response

classic Classic list List threaded Threaded
135 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

Bugzilla upstream workflow changes, and our response

Gervase Markham
Headline: Bugzilla 4.0 has a new status workflow. I propose we adopt it,
with one modification (the addition of a READY_TO_FIX state).

There have been discussions in the past about changing the workflow (set
of statuses and transitions between them) of bugzilla.mozilla.org to
better reflect our current development practices.

Soon, Bugzilla 4.0 will be released, and some time after that,
bugzilla.mozilla.org will be upgraded to it. One reason this is
significant is that Bugzilla 4.0 comes with a new default set of
statuses, designed based on the last 12 years of experience in Bugzillas
around the world.

The new lifecycle is here:
http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html

There are two new states - CONFIRMED (a replacement for NEW) and
IN_PROGRESS (a replacement for ASSIGNED). CLOSED and REOPENED are no more.

Some of the rationale for this change is here:
http://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-default-status-workflow/
https://bugzilla.mozilla.org/show_bug.cgi?id=486292

We've tried to update the b.m.o. workflow before, e.g. 2 years ago:
http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/80a8f074ab137f10/f9a60aaf914bcd7e
but the effort stalled. (I.e. I failed to drive it to completion.) This
change in the upstream software reopens the question.

I think we should adopt this change. The two removed statuses will not
be missed much (we no longer use CLOSED anyway), and the new names for
the other two better reflect what is going on. Also, even if the changes
were neutral, it is advantageous to be doing the same thing as upstream
Bugzilla.

However, there is one additional change we can consider at the same
time. The idea of having a READY or READY_TO_FIX state in
bugzilla.mozilla.org goes back 6 years, with some proposals from mconnor
and fantasai:
https://bugzilla.mozilla.org/show_bug.cgi?id=264721
http://snarkfest.net/blog/2005/09/28/a-modest-proposal/
http://steelgryphon.com/testcases/bugzilla-workflow-9.png

In the new workflow bug, Max K-A (a lead Bugzilla developer) says that a
READY_TO_FIX state to go between CONFIRMED and IN_PROGRESS makes sense
only for bigger Bugzillas (which we are). Which is why it's not part of
the default set.

I further propose that we add this state at the same time, for the
reasons given in the above proposals. It provides a clear delineation
between "bugs which are QA's problem" (CONFIRMED/RESOLVED) and "bugs
which are dev's problem" (READY_TO_FIX/IN_PROGRESS), with the latter
distinction showing clearly what dev is working on and what they aren't.
Without this change, a CONFIRMED bug could be on QA's plate or dev's
plate - the status doesn't tell us.

It is somewhat complicated to change the workflow for only a part of
Bugzilla (such as one product or component), so we would like to avoid
having to do that. But if you have a strong case for it, make it.

Note: this discussion is _not_ about resolutions (FIXED, DUPLICATE,
WORKSFORME etc.). Those can also be changed, but independently. Let's
have one discussion at a time.

Gerv

Appendix: How We'd Convert
--------------------------

We don't have to wait until Bugzilla 4.0 is released; we can convert
beforehand if necessary. No new 4.0 features are needed to implement this.

The exact algorithm, as implemented by the conversion script shipped
with Bugzilla, would be:

* "NEW"      will become "CONFIRMED"
* "ASSIGNED" will become "IN_PROGRESS"
* "REOPENED" will become "CONFIRMED" (and the "REOPENED" status will be
    removed)
* "CLOSED"   will become "VERIFIED" (and the "CLOSED" status will be
    removed)

The history of each bug will also be changed so that it appears that
these statuses were always in existence. Emails will not be sent.

If we adopt the READY_TO_FIX proposal, then initially no bugs would be
in the READY_TO_FIX state.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

Benjamin Smedberg
On 10/28/10 10:18 AM, Gervase Markham wrote:

> which are QA's problem" (CONFIRMED/RESOLVED) and "bugs which are dev's
> problem" (READY_TO_FIX/IN_PROGRESS), with the latter distinction showing
> clearly what dev is working on and what they aren't. Without this change, a
> CONFIRMED bug could be on QA's plate or dev's plate - the status doesn't
> tell us.

I'm opposed to current ASSIGNED status, and the new IN_PROGRESS status. Very
few people use them, and I don't think we'll have more luck convincing
people to use them in the future. They mainly serve to confuse newcomers who
ask "why isn't this bug IN_PROGRESS" even though there are attached patches
and the bug is pending review.

I don't have much input on the READY-TO-FIX state other than I'm skeptical
that it will actually help get bugs fixed, but I'm willing to keep my mouth
shut and find out ;-)

--BDS
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

Axel Hecht
In reply to this post by Gervase Markham
Ack for l10n and rdf, if that matters.

Axel

On 28.10.10 16:18, Gervase Markham wrote:

> Headline: Bugzilla 4.0 has a new status workflow. I propose we adopt it,
> with one modification (the addition of a READY_TO_FIX state).
>
> There have been discussions in the past about changing the workflow (set
> of statuses and transitions between them) of bugzilla.mozilla.org to
> better reflect our current development practices.
>
> Soon, Bugzilla 4.0 will be released, and some time after that,
> bugzilla.mozilla.org will be upgraded to it. One reason this is
> significant is that Bugzilla 4.0 comes with a new default set of
> statuses, designed based on the last 12 years of experience in Bugzillas
> around the world.
>
> The new lifecycle is here:
> http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html
>
> There are two new states - CONFIRMED (a replacement for NEW) and
> IN_PROGRESS (a replacement for ASSIGNED). CLOSED and REOPENED are no more.
>
> Some of the rationale for this change is here:
> http://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-default-status-workflow/
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=486292
>
> We've tried to update the b.m.o. workflow before, e.g. 2 years ago:
> http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/80a8f074ab137f10/f9a60aaf914bcd7e
>
> but the effort stalled. (I.e. I failed to drive it to completion.) This
> change in the upstream software reopens the question.
>
> I think we should adopt this change. The two removed statuses will not
> be missed much (we no longer use CLOSED anyway), and the new names for
> the other two better reflect what is going on. Also, even if the changes
> were neutral, it is advantageous to be doing the same thing as upstream
> Bugzilla.
>
> However, there is one additional change we can consider at the same
> time. The idea of having a READY or READY_TO_FIX state in
> bugzilla.mozilla.org goes back 6 years, with some proposals from mconnor
> and fantasai:
> https://bugzilla.mozilla.org/show_bug.cgi?id=264721
> http://snarkfest.net/blog/2005/09/28/a-modest-proposal/
> http://steelgryphon.com/testcases/bugzilla-workflow-9.png
>
> In the new workflow bug, Max K-A (a lead Bugzilla developer) says that a
> READY_TO_FIX state to go between CONFIRMED and IN_PROGRESS makes sense
> only for bigger Bugzillas (which we are). Which is why it's not part of
> the default set.
>
> I further propose that we add this state at the same time, for the
> reasons given in the above proposals. It provides a clear delineation
> between "bugs which are QA's problem" (CONFIRMED/RESOLVED) and "bugs
> which are dev's problem" (READY_TO_FIX/IN_PROGRESS), with the latter
> distinction showing clearly what dev is working on and what they aren't.
> Without this change, a CONFIRMED bug could be on QA's plate or dev's
> plate - the status doesn't tell us.
>
> It is somewhat complicated to change the workflow for only a part of
> Bugzilla (such as one product or component), so we would like to avoid
> having to do that. But if you have a strong case for it, make it.
>
> Note: this discussion is _not_ about resolutions (FIXED, DUPLICATE,
> WORKSFORME etc.). Those can also be changed, but independently. Let's
> have one discussion at a time.
>
> Gerv
>
> Appendix: How We'd Convert
> --------------------------
>
> We don't have to wait until Bugzilla 4.0 is released; we can convert
> beforehand if necessary. No new 4.0 features are needed to implement this.
>
> The exact algorithm, as implemented by the conversion script shipped
> with Bugzilla, would be:
>
> * "NEW" will become "CONFIRMED"
> * "ASSIGNED" will become "IN_PROGRESS"
> * "REOPENED" will become "CONFIRMED" (and the "REOPENED" status will be
> removed)
> * "CLOSED" will become "VERIFIED" (and the "CLOSED" status will be
> removed)
>
> The history of each bug will also be changed so that it appears that
> these statuses were always in existence. Emails will not be sent.
>
> If we adopt the READY_TO_FIX proposal, then initially no bugs would be
> in the READY_TO_FIX state.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

Mike Connor-4
In reply to this post by Benjamin Smedberg
  On 28/10/2010 10:24 AM, Benjamin Smedberg wrote:

> On 10/28/10 10:18 AM, Gervase Markham wrote:
>
>> which are QA's problem" (CONFIRMED/RESOLVED) and "bugs which are dev's
>> problem" (READY_TO_FIX/IN_PROGRESS), with the latter distinction showing
>> clearly what dev is working on and what they aren't. Without this
>> change, a
>> CONFIRMED bug could be on QA's plate or dev's plate - the status doesn't
>> tell us.
>
> I'm opposed to current ASSIGNED status, and the new IN_PROGRESS
> status. Very few people use them, and I don't think we'll have more
> luck convincing people to use them in the future. They mainly serve to
> confuse newcomers who ask "why isn't this bug IN_PROGRESS" even though
> there are attached patches and the bug is pending review.

I think the goal here is to reduce confusion about the state of a bug.  
I can figure out the state of a bug without statuses, but that's a lot
more time consuming.  ASSIGNED is weirdly named, since there's an
assigned-to field.  (As an aside, it'd be great to auto-set IN_PROGRESS
when a patch is attached by the assignee, because that means the
top-level status would reflect reality.)

I try to argue for a minimum of process/overhead with how we do things,
but I think reflecting actual phases of a bug would be beneficial here.  
UNCO/CONF/READY/IN_PROGRESS are all distinct, and require different
actions from different people, so it makes sense that we would call
these out at the top level.

It's worth a shot, at least!

-- Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

David E. Ross-3
In reply to this post by Gervase Markham
On 10/28/10 7:18 AM, Gervase Markham wrote [in part]:

> Headline: Bugzilla 4.0 has a new status workflow. I propose we adopt it,
> with one modification (the addition of a READY_TO_FIX state).
>
> There have been discussions in the past about changing the workflow (set
> of statuses and transitions between them) of bugzilla.mozilla.org to
> better reflect our current development practices.
>
> Soon, Bugzilla 4.0 will be released, and some time after that,
> bugzilla.mozilla.org will be upgraded to it. One reason this is
> significant is that Bugzilla 4.0 comes with a new default set of
> statuses, designed based on the last 12 years of experience in Bugzillas
> around the world.
>
> The new lifecycle is here:
> http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html

Bad URI.  Apparently the domain www.bugzilla.org does not exist.

--

David E. Ross
<http://www.rossde.com/>

I am again filtering and ignoring all newsgroup messages posted
through GoogleGroups via Google's G2/1.0 user agent because of the
amount of spam from that source.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

Reed Loden
On Thu, 28 Oct 2010 08:15:55 -0700
"David E. Ross" <[hidden email]> wrote:

> On 10/28/10 7:18 AM, Gervase Markham wrote [in part]:
<snip>

> > The new lifecycle is here:
> > http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html
>
> Bad URI.  Apparently the domain www.bugzilla.org does not exist.

Works fine for me... Check your browser or DNS settings?

~reed

--
Reed Loden
[hidden email]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

Benjamin Smedberg
In reply to this post by Benjamin Smedberg
On 10/28/10 11:12 AM, Mike Connor wrote:

> I try to argue for a minimum of process/overhead with how we do things, but
> I think reflecting actual phases of a bug would be beneficial here.
> UNCO/CONF/READY/IN_PROGRESS are all distinct, and require different actions
> from different people, so it makes sense that we would call these out at the
> top level.
>
> It's worth a shot, at least!

Sure, reflecting the actual phases of the bug would be valuable, if people
*did* it. Given the current design of bugzilla, there is no incentive to
actually change the status from CONF->READY->IN_PROGRESS, and I just don't
think people are going to do it.

You could certainly make things better by preventing the combination of
assignee=nobody + status = IN_PROGRESS. You could also make it better by
optionally being able to change the status to IN_PROGRESS when somebody
attaches a patch. That will reduce friction and increase the likelihood of
success.

But overall, I still think we'd be better off with a single "open" status,
which, when a bug is assigned to nobody, means "ready", and when it's
assigned to somebody, means "in progress". There are edge cases where
somebody is assigned a bug but isn't working on it or doesn't plan to work
on it, but that's already the degenerate case where more metadata probably
won't help.

--BDS
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

Shawn Wilsher-3
In reply to this post by Mike Connor-4
On 10/28/2010 8:12 AM, Mike Connor wrote:
> I try to argue for a minimum of process/overhead with how we do things,
> but I think reflecting actual phases of a bug would be beneficial here.
> UNCO/CONF/READY/IN_PROGRESS are all distinct, and require different
> actions from different people, so it makes sense that we would call
> these out at the top level.
This.  At the very least, employees of Mozilla should be doing this.
It's our primary job to communicate clearly to the community what's
going on with the project (via bugs, meeting notes, blog posts, etc),
and being too lazy to change the status of a bug when you start working
on it just isn't a good enough reason to not do this, IMO.

Cheers,

Shawn


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

Marco Bonardo-2
In reply to this post by Mike Connor-4
Il 28/10/2010 17:55, Shawn Wilsher ha scritto:
> On 10/28/2010 8:12 AM, Mike Connor wrote:
> At the very least, employees of Mozilla should be doing this. It's
> our primary job to communicate clearly to the community what's going on
> with the project (via bugs, meeting notes, blog posts, etc), and being
> too lazy to change the status of a bug when you start working on it just
> isn't a good enough reason to not do this, IMO.

I often find myself setting ASSIGNED status on others' bugs.  For most
people the new workflow will continue to be the same they use today:
UNCONFIRMED -> CONFIRMED -> assignedTo -> FIXED -> VERIFIED.
Both the suggested new statused are nice changes but will be hard to
enforce them, noticing how common is the above workflow.

Do we expect assignees to remove IN_PROGRESS if they work on other
higher priority stuff and expect to not go back to that bug soonish? Or
is it just indication that the assignee started doing something for the bug?

Regarding READY_TO_FIX, there should also be a defined way to
differentiate what is needed when a bug is not yet ready (testcase,
design, prototype, triaging, ...).
It looks like an inverse replacement for "qawanted".  We have about 3500
bugs marked with it and they don't seem to get more traction from the
community, mostly because it's a large set including also pretty old
bugs, and a lot of newer bugs, not marked with it, are requiring the
same attention.  From this point of view could make sense an inverse
approach, where any bug needs attention till it has enough info.

If READY is added, imo IN_PROGRESS is needed; a READY bug with an
assignee doesn't give me the idea of being worked on. Looks like
something that is ready for the assignee to _start_ working on.

-m
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

Asa Dotzler-2
In reply to this post by Benjamin Smedberg
On 10/28/2010 8:38 AM, Benjamin Smedberg wrote:

> On 10/28/10 11:12 AM, Mike Connor wrote:
>
>> I try to argue for a minimum of process/overhead with how we do
>> things, but
>> I think reflecting actual phases of a bug would be beneficial here.
>> UNCO/CONF/READY/IN_PROGRESS are all distinct, and require different
>> actions
>> from different people, so it makes sense that we would call these out
>> at the
>> top level.
>>
>> It's worth a shot, at least!
>
> Sure, reflecting the actual phases of the bug would be valuable, if
> people *did* it.

In the case that people don't do it, we're no worse off. In the case
that people do use the indicators properly, it's a win. That sounds like
a net win to me.

- A
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

Sheila Mooney
In reply to this post by Shawn Wilsher-3
I kind of like the new statuses. I certainly like IN_PROGRESS better.
I never really liked the ASSIGNED status much.

I think it would be helpful to understand why people really don't use
the statuses consistently today. The exception here is maybe RESOLVED
since everybody will reliably mark that because it has a direct
benefit. To look at a bit of data; of the 19 Beta7 blockers, only 5 of
them have status=ASSIGNED. The rest are in the NEW state. Does this
reflect the state of things? I suspect not. The bug assigned to
"nobody" isn't really assigned to "nobody". You are required to go
through each bug individually to figure out what is really going on. I
agree that assuming people will adopt the new statuses simply because
they make more sense isn't a reliable motivator.

I like the idea of coupling the statuses with the assigned field
somehow to prevent cases of assigned=nobody and status=IN_PROGRESS and
possibly some other combinations - understanding there are edge cases
here. I think that would be helpful.

In my experience, using status to figure out what is going on is
somewhat limited. There are bugs that can sit in one state for a long
time, let's say CONFIRMED. There might be all kinds of parallel
activities going on - dev investigation, qa investigation. They are
being worked on in some form. What you really don't see is why they
are getting bogged down or what next step we are blocked on. I know
this is kind of off topic from the initial discussion.

On Thu, Oct 28, 2010 at 8:55 AM, Shawn Wilsher <[hidden email]> wrote:

> On 10/28/2010 8:12 AM, Mike Connor wrote:
>>
>> I try to argue for a minimum of process/overhead with how we do things,
>> but I think reflecting actual phases of a bug would be beneficial here.
>> UNCO/CONF/READY/IN_PROGRESS are all distinct, and require different
>> actions from different people, so it makes sense that we would call
>> these out at the top level.
>
> This.  At the very least, employees of Mozilla should be doing this. It's
> our primary job to communicate clearly to the community what's going on with
> the project (via bugs, meeting notes, blog posts, etc), and being too lazy
> to change the status of a bug when you start working on it just isn't a good
> enough reason to not do this, IMO.
>
> Cheers,
>
> Shawn
>
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

David E. Ross-3
In reply to this post by David E. Ross-3
On 10/28/10 8:30 AM, Reed Loden wrote:

> On Thu, 28 Oct 2010 08:15:55 -0700
> "David E. Ross" <[hidden email]> wrote:
>
>> On 10/28/10 7:18 AM, Gervase Markham wrote [in part]:
> <snip>
>
>>> The new lifecycle is here:
>>> http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html
>>
>> Bad URI.  Apparently the domain www.bugzilla.org does not exist.
>
> Works fine for me... Check your browser or DNS settings?
>
> ~reed
>

Yes, it's working for me now.  But I did nothing to change my browser or
DNS settings.

--

David E. Ross
<http://www.rossde.com/>

I am again filtering and ignoring all newsgroup messages posted
through GoogleGroups via Google's G2/1.0 user agent because of the
amount of spam from that source.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

Mike Hommey
In reply to this post by Sheila Mooney
On Thu, Oct 28, 2010 at 10:52:29AM -0700, Sheila Mooney wrote:

> I kind of like the new statuses. I certainly like IN_PROGRESS better.
> I never really liked the ASSIGNED status much.
>
> I think it would be helpful to understand why people really don't use
> the statuses consistently today. The exception here is maybe RESOLVED
> since everybody will reliably mark that because it has a direct
> benefit. To look at a bit of data; of the 19 Beta7 blockers, only 5 of
> them have status=ASSIGNED. The rest are in the NEW state. Does this
> reflect the state of things? I suspect not. The bug assigned to
> "nobody" isn't really assigned to "nobody". You are required to go
> through each bug individually to figure out what is really going on. I
> agree that assuming people will adopt the new statuses simply because
> they make more sense isn't a reliable motivator.

Maybe if the UI was more helpful to follow the workflow, it would work
better. Changing the status can only be done at the bottom of the page,
and assigning bugs to oneself is not as simple as "Add me to CC list".

Some components also have default values for Assigned To that is not
nobody.

Cheers,

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

Reed Loden
On Thu, 28 Oct 2010 20:18:30 +0200
Mike Hommey <[hidden email]> wrote:

> Some components also have default values for Assigned To that is not
> nobody.

Please file bugs on those components (under mozilla.org :: Bugzilla:
Keywords & Components), and they will be fixed.

~reed

--
Reed Loden
[hidden email]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

Mike Hommey
On Thu, Oct 28, 2010 at 11:23:53AM -0700, Reed Loden wrote:
> On Thu, 28 Oct 2010 20:18:30 +0200
> Mike Hommey <[hidden email]> wrote:
>
> > Some components also have default values for Assigned To that is not
> > nobody.
>
> Please file bugs on those components (under mozilla.org :: Bugzilla:
> Keywords & Components), and they will be fixed.

I will when I see one. Or maybe a generic bug should be filed to change
it for all components ?
(I see in the history of bugs against mozilla.org :: Bugzilla: Keywords
& Components that there have been quite a lot of requests to change to
nobody in the past, and a few requests to change it to something else)

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

Dave Mandelin-2
In reply to this post by Benjamin Smedberg
On 10/28/2010 8:38 AM, Benjamin Smedberg wrote:

> On 10/28/10 11:12 AM, Mike Connor wrote:
>
>> I try to argue for a minimum of process/overhead with how we do
>> things, but
>> I think reflecting actual phases of a bug would be beneficial here.
>> UNCO/CONF/READY/IN_PROGRESS are all distinct, and require different
>> actions
>> from different people, so it makes sense that we would call these out
>> at the
>> top level.
>>
>> It's worth a shot, at least!
>
> Sure, reflecting the actual phases of the bug would be valuable, if
> people *did* it. Given the current design of bugzilla, there is no
> incentive to actually change the status from CONF->READY->IN_PROGRESS,
> and I just don't think people are going to do it.
I agree, partially. Your point brings up the question, why is there no
incentive to make that change? Speaking just for myself, I'm not sure
who is using the "intermediate" status values, so it's not clear anyone
cares. Also, they tend not to be set now, so I never rely on them, and I
assume others don't either. I find that in order to track the status of
a bug, I have to read the comments.

On a related note, it seems that for certain kinds of bugs (e.g.,
blockers of the next release or two), status flags could be pretty
valuable, but for other kinds of bugs, people might not care too much.
Maybe if someone who is tracking blockers really wants those flags to be
right, they could go around fixing them/asking assignees to keep them up
to date, and we might be able to get the info for the case where we
actually need it.

I guess the point I'm trying to make is that for most bugs, I'm with you
that the open/in_progress is enough. But for cases where we actually
need to schedule or unblock work, we need more information. I might want
even more than "in_progress" someday, like "to start on date X", "ETA
date X", "blocked on bug X", "blocked, see comment X".
> You could certainly make things better by preventing the combination
> of assignee=nobody + status = IN_PROGRESS.
Yes.
> You could also make it better by optionally being able to change the
> status to IN_PROGRESS when somebody attaches a patch. That will reduce
> friction and increase the likelihood of success.
Why not automatically change the status to IN_PROGRESS when a patch is
attached? And how about automatically changing status back to CONFIRMED
if N days go by with no comments or changes from the assignee?
>
> But overall, I still think we'd be better off with a single "open"
> status, which, when a bug is assigned to nobody, means "ready", and
> when it's assigned to somebody, means "in progress". There are edge
> cases where somebody is assigned a bug but isn't working on it or
> doesn't plan to work on it, but that's already the degenerate case
> where more metadata probably won't help.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

timeless-3
On Thu, Oct 28, 2010 at 9:52 PM, David Mandelin <[hidden email]> wrote:
> Maybe if someone who is
> tracking blockers really wants those flags to be right, they could go around
> fixing them/asking assignees to keep them up to date, and we might be able
> to get the info for the case where we actually need it.

Please *NO*. Nokia management has entire teams of managers whose sole
purpose appears to be asking people to update bug metadata.
This is done by adding comments to bugs.

The result is that we have much much more requests for metadata
comments than we have actual content in our bugs.

> I guess the point I'm trying to make is that for most bugs, I'm with you
> that the open/in_progress is enough. But for cases where we actually need to
> schedule or unblock work, we need more information. I might want even more
> than "in_progress" someday, like "to start on date X", "ETA date X",
> "blocked on bug X", "blocked, see comment X".

> Why not automatically change the status to IN_PROGRESS when a patch is
> attached? And how about automatically changing status back to CONFIRMED if N
> days go by with no comments or changes from the assignee?

At this point why bother having these as actual statuses?
Why not have them as "VIEWS"?
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

Dave Mandelin-2
On 10/28/2010 11:56 AM, timeless wrote:

> On Thu, Oct 28, 2010 at 9:52 PM, David Mandelin<[hidden email]>  wrote:
>> Maybe if someone who is
>> tracking blockers really wants those flags to be right, they could go around
>> fixing them/asking assignees to keep them up to date, and we might be able
>> to get the info for the case where we actually need it.
> Please *NO*. Nokia management has entire teams of managers whose sole
> purpose appears to be asking people to update bug metadata.
> This is done by adding comments to bugs.
>
> The result is that we have much much more requests for metadata
> comments than we have actual content in our bugs.
Of course I would not recommend anything so bureaucratic than that. We
do post in bugs asking for updates sometimes when there hasn't been
progress in a while, so it's not unprecedented. More routine requests
could use email in order not to clutter up the bugs. But the hope would
be to foster a change in how people communicate their activity on
high-priority bugs, so that such requests would eventually be unnecessary.

>> I guess the point I'm trying to make is that for most bugs, I'm with you
>> that the open/in_progress is enough. But for cases where we actually need to
>> schedule or unblock work, we need more information. I might want even more
>> than "in_progress" someday, like "to start on date X", "ETA date X",
>> "blocked on bug X", "blocked, see comment X".
>> Why not automatically change the status to IN_PROGRESS when a patch is
>> attached? And how about automatically changing status back to CONFIRMED if N
>> days go by with no comments or changes from the assignee?
> At this point why bother having these as actual statuses?
> Why not have them as "VIEWS"?
Sounds great.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

Reed Loden
In reply to this post by Mike Connor-4
On Thu, 28 Oct 2010 11:12:51 -0400
Mike Connor <[hidden email]> wrote:

> I think the goal here is to reduce confusion about the state of a bug.  
> I can figure out the state of a bug without statuses, but that's a lot
> more time consuming.  ASSIGNED is weirdly named, since there's an
> assigned-to field.  (As an aside, it'd be great to auto-set IN_PROGRESS
> when a patch is attached by the assignee, because that means the
> top-level status would reflect reality.)

Can be done with a little bit of work... File a bug?

~reed

--
Reed Loden
[hidden email]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla upstream workflow changes, and our response

Reed Loden
In reply to this post by Gervase Markham
On Thu, 28 Oct 2010 15:18:05 +0100
Gervase Markham <[hidden email]> wrote:

> It is somewhat complicated to change the workflow for only a part of
> Bugzilla (such as one product or component), so we would like to avoid
> having to do that. But if you have a strong case for it, make it.

Re-iterating the "complicated" part of the above paragraph, it is
extremely difficult to split the workflow per-product, and as one of
bmo's maintainers, I'm very likely to veto any such request. We already
have too many hacks to manage, and it's really just not worth it.

~reed

--
Reed Loden
[hidden email]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
1234 ... 7