bugzilla.mozilla.org workflow changes

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

bugzilla.mozilla.org workflow changes

Gervase Markham
A while back (2005), some work was done on defining what would be an
optimum Bugzilla workflow:
http://wiki.mozilla.org/BugzillaWorkflowImprovements

This included the clear definition of a workflow:
http://steelgryphon.com/testcases/bugzilla-workflow-9.png
which I hope will be useful to new QA contributors. Among other things,
the new workflow had a READY state, into which bugs should be put by
triagers and QA when they were ready to be fixed, and from which
developers could take bugs to fix.

Having reviewed the discussion from back then:
http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/80a8f074ab137f10/f9a60aaf914bcd7e?q=%22READY+state%22+mozilla&lnk=ol&
I still think we should make the following changes:

- Create the new READY state, and encourage triagers to manually move
   ready bugs into it.

- Abolish the REOPENED state (automatically converting all existing
   REOPENED bugs to NEW) as it adds no useful information.

- Publish a tweaked version of mconnor's diagram so people know how
   things should work, and as a guide for new QA community members.

Do people think there is still value in this?

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

Re: bugzilla.mozilla.org workflow changes

Jean-Marc Desperrier
Gervase Markham wrote:
> Among other things, the new workflow had a READY state, into which bugs
> should be put by triagers and QA when they were ready to be fixed, and
> from which developers could take bugs to fix.
 >

> [...]
> I still think we should make the following changes:
>
> - Create the new READY state, and encourage triagers to manually move
>    ready bugs into it.
>
> - Abolish the REOPENED state (automatically converting all existing
>    REOPENED bugs to NEW) as it adds no useful information.
>
> - Publish a tweaked version of mconnor's diagram so people know how
>    things should work, and as a guide for new QA community members.
>
> Do people think there is still value in this?

I'd go further. There could be a lot of value in creating new states
between "assigned" and "resolved fixed".

I'm thinking of :
- Assigned : Changed to mean that the bug is waiting until the dev it's
affected to *actually* starts working on it
- Under Work : the dev is currently busy investigating the bug/writing
code to solve it
- Patched : There's a patch attached that solves the bug as far as the
affected dev is concerned, but that has not yet been validated.

And then a report of the bugs that have stayed more than a few weeks in
the "Patched" state, or several months in the "Assigned" state would be
*very* useful.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org workflow changes

Benjamin Smedberg
In reply to this post by Gervase Markham
On 3/31/09 5:24 AM, Gervase Markham wrote:

> This included the clear definition of a workflow:
> http://steelgryphon.com/testcases/bugzilla-workflow-9.png
> which I hope will be useful to new QA contributors. Among other things,
> the new workflow had a READY state, into which bugs should be put by
> triagers and QA when they were ready to be fixed, and from which
> developers could take bugs to fix.

Have developers indicated that they are actually going to use this new
state? I'm wary of adding additional metadata to all our bugs unless there
is a clear indication that it's going to help someone in a practical way.
READY is only better than a little whiteboard note if it's going to help
create effective queries, and we'd all pay a price to keep READY and NEW
separate.

It's like ASSIGNED: while there may be some theoretical difference between
ASSIGNED and NEW, I haven't seen most developers use the ASSIGNED state.

I tend to think that in most of the modules I own READY would just be
another thing for people to argue over, with little practical benefit. On
the other hand, I think we could probably ignore it and it would cause only
minor inconvenience.

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

Re: bugzilla.mozilla.org workflow changes

L. David Baron
In reply to this post by Gervase Markham
On Tuesday 2009-03-31 10:24 +0100, Gervase Markham wrote:
> - Create the new READY state, and encourage triagers to manually move
>   ready bugs into it.

Don't we already have such a distinction:  UNCONFIRMED vs. NEW?
What does this *additional* distinction add?

I'd love to have a way to un-confirm a bug, though.  (That is, move
it from NEW to UNCONFIRMED, because it shouldn't have been
confirmed.)

> - Abolish the REOPENED state (automatically converting all existing
>   REOPENED bugs to NEW) as it adds no useful information.

Sounds reasonable to me.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org workflow changes

Martijn-4
On Tue, Mar 31, 2009 at 5:00 PM, L. David Baron <[hidden email]> wrote:
> On Tuesday 2009-03-31 10:24 +0100, Gervase Markham wrote:
>> - Create the new READY state, and encourage triagers to manually move
>>   ready bugs into it.
>
> Don't we already have such a distinction:  UNCONFIRMED vs. NEW?
> What does this *additional* distinction add?

I have the same feeling about this.
Afaics, it would only cause a lot of work where qa/triagers needs to
go through all the NEW bugs and mark them as READY when appropriate.

> I'd love to have a way to un-confirm a bug, though.  (That is, move
> it from NEW to UNCONFIRMED, because it shouldn't have been
> confirmed.)
>
>> - Abolish the REOPENED state (automatically converting all existing
>>   REOPENED bugs to NEW) as it adds no useful information.

I guess you could do that, but I don't really see the harm of REOPENED bugs.

Regards,
Martijn

> Sounds reasonable to me.
>
> -David
>
> --
> L. David Baron                                 http://dbaron.org/
> Mozilla Corporation                       http://www.mozilla.com/
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>



--
Martijn Wargers - Help Mozilla!
http://quality.mozilla.org/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org workflow changes

Joshua Cranmer-2
In reply to this post by Gervase Markham
L. David Baron wrote:
> On Tuesday 2009-03-31 10:24 +0100, Gervase Markham wrote:
>> - Create the new READY state, and encourage triagers to manually move
>>   ready bugs into it.
>
> Don't we already have such a distinction:  UNCONFIRMED vs. NEW?
> What does this *additional* distinction add?

At this stage, I'm going to say that adding a new READY state will
likely cause some procedural furor. I can sometimes see the need for a
distinction between bugs that are not sufficiently reproducible to be
fixable but clearly exist among a large sector of the user population
(e.g., <https://bugzilla.mozilla.org/show_bug.cgi?id=451118>) and the
bugs whose existence may be in question or bugs whose fixes are, in
principle, known.

That said, the more useful place to stick the state, in my eyes, is
between UNCO and NEW, not between NEW and ASSI as is the current proposal.

> I'd love to have a way to un-confirm a bug, though.  (That is, move
> it from NEW to UNCONFIRMED, because it shouldn't have been
> confirmed.)

This, on the other hand, I would gladly welcome. Some of the components
I triage have large numbers of NEW bugs which were confirmed in days
when the bar was rather low.

>> - Abolish the REOPENED state (automatically converting all existing
>>   REOPENED bugs to NEW) as it adds no useful information.
>
> Sounds reasonable to me.

+<however much my vote counts for>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org workflow changes

Aakash Desai-2
In reply to this post by Gervase Markham
I'm not sure that I agree with abolishing the Re-Opened state on a semantic level. The Re-Opened state is used as a marker to community members (whether they're involved or not involved with fixing the bug) that this bug already has had a patch created and was reviewed before being submitted. Now, from what I can gather, a bug that goes to Re-Opened status usually means that it failed on a specific platform, certain use case failed or it broke another function. On the other hand, the New state means that the bug has been unconfirmed and it's either in the process of being assigned to a developer (semantics again because bugs stay in the New state even after they're assigned) and/or a patch has not been created for it. I think moving a bug back to the New state should be possible, but the Re-opened state does have a lot of use to it to people not involved with the bug.

As for a guide to go from state to state for a bug, there's one posted here: http://quality.mozilla.org/bugs-life-walkthrough . It's a beginner's guide, so there's still some kinks (i.e. screenshots, specific reasons for going from one state to the other) that need to be ironed out or put into an Advanced version of the document.

Lastly, there's still some problems with the workflow diagram linked to in Gervase's e-mail. For the lazy, the link is http://steelgryphon.com/testcases/bugzilla-workflow-9.png . Here are my gripes on it:

- WontFix is not just for enhancements
- If a bug is found under inappropriate conditions, then the bug is Invalid, not WorksForMe. If it's not found in the scenario that the bug reporter listed, then it's a WorksForMe.

Thanks,
Aakash

----- Original Message -----
From: "L. David Baron" <[hidden email]>
To: [hidden email]
Sent: Tuesday, March 31, 2009 8:00:09 AM GMT -08:00 US/Canada Pacific
Subject: Re: bugzilla.mozilla.org workflow changes

On Tuesday 2009-03-31 10:24 +0100, Gervase Markham wrote:
> - Create the new READY state, and encourage triagers to manually move
>   ready bugs into it.

Don't we already have such a distinction:  UNCONFIRMED vs. NEW?
What does this *additional* distinction add?

I'd love to have a way to un-confirm a bug, though.  (That is, move
it from NEW to UNCONFIRMED, because it shouldn't have been
confirmed.)

> - Abolish the REOPENED state (automatically converting all existing
>   REOPENED bugs to NEW) as it adds no useful information.

Sounds reasonable to me.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
_______________________________________________
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.mozilla.org workflow changes

Mike Shaver
In reply to this post by Joshua Cranmer-2
On Tue, Mar 31, 2009 at 11:36 AM, Joshua Cranmer <[hidden email]> wrote:
> That said, the more useful place to stick the state, in my eyes, is between
> UNCO and NEW, not between NEW and ASSI as is the current proposal.

I propose a zero-net-complexity rule for our bugzilla.  If you add a
state, you have to remove one.  REOPENED and ASSIGNED are both pretty
much useless to us, not carrying their weight in terms of clutter or
complexity.  WONTFIX/INVALID might be foldable too, since it's not
like WONTFIX keeps us from having people re-ask, and I don't think we
ever really care about distinguishing "what you're asking for is not
going to happen" and "what you asked doesn't make sense or is a bug in
some other piece of software or wtf are you trying to say etc." beyond
what would be expressed in the closing comment.

(I'd like to say that if you add a flag you have to remove one, but
when all we have is flags/keywords/whiteboard-tribal-knowledge, every
problem looks like a [?-+ parity:investigate].  See also the co-opting
of priority field for shade-of-blocker, squatting a useful management
and planning tool for module owners and managers.)

See also: QA contact and Hardware fields, IMO.  If we didn't have
bugzilla right now, this is definitely not the system we'd build.

Here are the things I care about as an engineering/product manager:

- what bugs have had work done on them?
- what bugs are assigned to which people (loading)? what reviews?
- what bugs block the given release?
- what is the rate of addition to the blocker list? what is the rate
of fix (to trunk, and to a given release stream)? (likewise for
security and crash bugs, and untriaged/new bugs)
- what bugs have patches? what bugs have test cases?
- what open bugs haven't been touched in a while?
- what bugs are being reported against which newly-released versions
or milestones?

As a developer, also I care about:

- what bugs need a comment from me?
- what bugs of mine are ready to land on which branches?
- what bugs have an updated patch for re-review?
- where do I put a comment in a bug so that it gets pulled into
release notes or a changelog?
- what bugs have clear regression ranges?
- in what *@(#&*@*#&@ component should I file this bug I just found?
- why can I still not watch components?

As a user and product advocate, I care about:
- are you really telling me that there's nowhere to file a bug about a
layout problem in Firefox without clicking through "Other Products"
and looking through the list of Java crypto software and webtools?
- how to not be mortified when someone asks where to file a bug, and
what all the twiddles mean
- how to do anything but nod sadly when someone says "I didn't have
time to figure out how to file that bug"

I don't think these states are really going to help me answer many of
these things, so I'm loath to take much additional complexity or time
investment for it.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org workflow changes

Mike Shaver
In reply to this post by Aakash Desai-2
On Tue, Mar 31, 2009 at 11:57 AM, Aakash Desai <[hidden email]> wrote:
> I'm not sure that I agree with abolishing the Re-Opened state on a semantic level. The Re-Opened state is used as a marker to community members (whether they're involved or not involved with fixing the bug) that this bug already has had a patch created and was reviewed before being submitted. Now, from what I can gather, a bug that goes to Re-Opened status usually means that it failed on a specific platform, certain use case failed or it broke another function. On the other hand, the New state means that the bug has been unconfirmed and it's either in the process of being assigned to a developer (semantics again because bugs stay in the New state even after they're assigned) and/or a patch has not been created for it. I think moving a bug back to the New state should be possible, but the Re-opened state does have a lot of use to it to people not involved with the bug.

I don't think REOPENED tells you much that you don't have to read the
bug to confirm, at which point the state isn't useful.  At most,
REOPENEDness should be a keyword like "regression" so that the 0.3% of
people who would query on it can do so without adding more state-space
for the rest of the world.

> As for a guide to go from state to state for a bug, there's one posted here: http://quality.mozilla.org/bugs-life-walkthrough . It's a beginner's guide, so there's still some kinks (i.e. screenshots, specific reasons for going from one state to the other) that need to be ironed out or put into an Advanced version of the document.

If the beginner's guide doesn't fit in 500 words and a 800x600 image,
we should streamline the process until it does, IMO.

> - If a bug is found under inappropriate conditions, then the bug is Invalid, not WorksForMe. If it's not found in the scenario that the bug reporter listed, then it's a WorksForMe.

Most people don't care about that, though.  They care about:

- we don't know wtf about this bug
- this bug will be fixed
 - when (as in which release stream, as well as date)
- this bug won't be fixed (why not is a detail)
- this bug has been fixed in (pick-N release streams/versions/dates)

It's only to the twisted mind of a developer that "INVALID" is a form
"resolved"; likewise with WONTFIX, I think.

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

Re: bugzilla.mozilla.org workflow changes

Joshua Cranmer-2
In reply to this post by Joshua Cranmer-2
Mike Shaver wrote:
> On Tue, Mar 31, 2009 at 11:36 AM, Joshua Cranmer <[hidden email]> wrote:
>> That said, the more useful place to stick the state, in my eyes, is between
>> UNCO and NEW, not between NEW and ASSI as is the current proposal.

For clarification: I'm not exactly in favor of adding a new state, but
I'm not altogether opposed to one in theory.

> See also: QA contact and Hardware fields, IMO.  If we didn't have
> bugzilla right now, this is definitely not the system we'd build.

Is there a way to watch components without utilizing QA contact? If
there is, feel free to make that information more widely visible and
then get rid of it.

> As a developer, also I care about:
>
> - what bugs need a comment from me?
> - what bugs of mine are ready to land on which branches?
> - what bugs have an updated patch for re-review?
> - where do I put a comment in a bug so that it gets pulled into
> release notes or a changelog?
> - what bugs have clear regression ranges?
> - in what *@(#&*@*#&@ component should I file this bug I just found?
> - why can I still not watch components?

As a potential developer:
- which bugs would people like to me fix?
- which bugs are people not working on?

> I don't think these states are really going to help me answer many of
> these things, so I'm loath to take much additional complexity or time
> investment for it.

I find the ASSI state useful, in that I can distinguish between "I'll
look at fixing this bug if I have time" and "I'm going to commit to
fixing this bug." On the other hand, REOP is not very useful for any of
my bug grepping strategies.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: bugzilla.mozilla.org workflow changes

Aakash Desai-2
In reply to this post by Gervase Markham
> I don't think REOPENED tells you much that you don't have to read the
bug to confirm, at which point the state isn't useful.  At most,
REOPENEDness should be a keyword like "regression" so that the 0.3% of
people who would query on it can do so without adding more state-space
for the rest of the world.

Adding it as a keyword is fine and dandy for me as long as it's not completely removed from the system. Re-Openedness is something that's going to be seen in the wild when working on cross platform projects and it should be taken into account, no matter how good we are at handling them or how "small" of a number they begin to show up in our system.

> If the beginner's guide doesn't fit in 500 words and a 800x600 image,
we should streamline the process until it does, IMO.

We should really ask if all beginner's guides need to fit into a 500 word document or something hard-set like that. For me, if we're using something as complex as this: http://www.bugzilla.org/docs/tip/en/html/lifecycle.html ... sometimes writing a bit more is necessary to really explain it. Now, how the reader sees the information splayed out onto the screen is probably where you're getting at. In that light, yeah sure, I did say there were some kinks that needed to be ironed out :). We don't want to scare away potential volunteers, but having that information up in that form, for now, is a better alternative than not having it up at all.

> Most people don't care about that, though.  They care about:
- we don't know wtf about this bug
- this bug will be fixed
- when (as in which release stream, as well as date)
- this bug won't be fixed (why not is a detail)
- this bug has been fixed in (pick-N release streams/versions/dates)
It's only to the twisted mind of a developer that "INVALID" is a form
"resolved"; likewise with WONTFIX, I think.

Developers aren't the only ones reading and changing the states on these bugs. There's a whole host of people external to Mozilla's community that read through this bug system (or we hope read through it) that don't understand how it works. If we start blurring the lines of what each state means, so it's easier for a developer to read, then we're not doing our job in trying to get more of the community involved.

Thanks,
Aakash

----- Original Message -----
From: "Mike Shaver" <[hidden email]>
To: "Aakash Desai" <[hidden email]>
Cc: "L. David Baron" <[hidden email]>, [hidden email]
Sent: Tuesday, March 31, 2009 9:14:57 AM GMT -08:00 US/Canada Pacific
Subject: Re: bugzilla.mozilla.org workflow changes

On Tue, Mar 31, 2009 at 11:57 AM, Aakash Desai <[hidden email]> wrote:
> I'm not sure that I agree with abolishing the Re-Opened state on a semantic level. The Re-Opened state is used as a marker to community members (whether they're involved or not involved with fixing the bug) that this bug already has had a patch created and was reviewed before being submitted. Now, from what I can gather, a bug that goes to Re-Opened status usually means that it failed on a specific platform, certain use case failed or it broke another function. On the other hand, the New state means that the bug has been unconfirmed and it's either in the process of being assigned to a developer (semantics again because bugs stay in the New state even after they're assigned) and/or a patch has not been created for it. I think moving a bug back to the New state should be possible, but the Re-opened state does have a lot of use to it to people not involved with the bug.

I don't think REOPENED tells you much that you don't have to read the
bug to confirm, at which point the state isn't useful.  At most,
REOPENEDness should be a keyword like "regression" so that the 0.3% of
people who would query on it can do so without adding more state-space
for the rest of the world.

> As for a guide to go from state to state for a bug, there's one posted here: http://quality.mozilla.org/bugs-life-walkthrough . It's a beginner's guide, so there's still some kinks (i.e. screenshots, specific reasons for going from one state to the other) that need to be ironed out or put into an Advanced version of the document.

If the beginner's guide doesn't fit in 500 words and a 800x600 image,
we should streamline the process until it does, IMO.

> - If a bug is found under inappropriate conditions, then the bug is Invalid, not WorksForMe. If it's not found in the scenario that the bug reporter listed, then it's a WorksForMe.

Most people don't care about that, though.  They care about:

- we don't know wtf about this bug
- this bug will be fixed
 - when (as in which release stream, as well as date)
- this bug won't be fixed (why not is a detail)
- this bug has been fixed in (pick-N release streams/versions/dates)

It's only to the twisted mind of a developer that "INVALID" is a form
"resolved"; likewise with WONTFIX, I think.

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

Re: bugzilla.mozilla.org workflow changes

Mike Connor-4
In reply to this post by Aakash Desai-2

On 31-Mar-09, at 11:57 AM, Aakash Desai wrote:

> Lastly, there's still some problems with the workflow diagram linked  
> to in Gervase's e-mail. For the lazy, the link is http://steelgryphon.com/testcases/bugzilla-workflow-9.png 
>  . Here are my gripes on it:
>
> - WontFix is not just for enhancements

It doesn't cover every single possible workflow, but it's somewhat  
idealized.  WONTFIX vs. INVALID is often a grey area, IMO.

> - If a bug is found under inappropriate conditions, then the bug is  
> Invalid, not WorksForMe. If it's not found in the scenario that the  
> bug reporter listed, then it's a WorksForMe.

The assumption made in the "can it be reproduced under appropriate  
conditions?" decision point is that you follow the STR, and can't repro.

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

Re: bugzilla.mozilla.org workflow changes

Serge Gautherie-2
In reply to this post by Gervase Markham
L. David Baron wrote:

> I'd love to have a way to un-confirm a bug, though.  (That is, move
> it from NEW to UNCONFIRMED, because it shouldn't have been
> confirmed.)

I concur:
NEW would then mean "ready" somehow;
UNCONFIRMED would mean "needs triage", as it already does.

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

Re: bugzilla.mozilla.org workflow changes

Boris Zbarsky
In reply to this post by Gervase Markham
Aakash Desai wrote:
> Developers aren't the only ones reading and changing the states on these bugs. There's a whole host of people external to Mozilla's community that read through this bug system (or we hope read through it) that don't understand how it works. If we start blurring the lines of what each state means, so it's easier for a developer to read, then we're not doing our job in trying to get more of the community involved.

Shaver's point was that non-developers are the ones who don't care about
WONTFIX vs INVALID.  The care about whether the behavior will change or not.

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

Re: bugzilla.mozilla.org workflow changes

Serge Gautherie-2
In reply to this post by Benjamin Smedberg
Benjamin Smedberg wrote:

> It's like ASSIGNED: while there may be some theoretical difference between
> ASSIGNED and NEW, I haven't seen most developers use the ASSIGNED state.

I'm sad about that:
ASSIGNED should mean someone is actually (planning on) working on it.
Whereas "Assigned To" (+ NEW) is more like asking someone to, or that he
may/will but not yet.
Helps to see (in the graphs) which/how_many bugs are (supposedly)
currently taken care of (among all the open bugs).

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

Re: bugzilla.mozilla.org workflow changes

Igor Bukanov-2
In reply to this post by Serge Gautherie-2
2009/3/31 Serge Gautherie <[hidden email]>:
> L. David Baron wrote:
> I concur:
> NEW would then mean "ready" somehow;
> UNCONFIRMED would mean "needs triage", as it already does.

That is a good point. So what about renaming NEW to simply OPEN? This
would be especially relevant given that now REOPEN means to transition
into that state.

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

Re: bugzilla.mozilla.org workflow changes

Serge Gautherie-2
In reply to this post by Gervase Markham
Gervase Markham wrote:

> - Abolish the REOPENED state (automatically converting all existing
>   REOPENED bugs to NEW) as it adds no useful information.

I don't know. I usualy see two typical cases:

1) bugs which were (thought) fixed:
Reopen is usually a backout or a regression or needs additional changes.
This REOPENED I see as a kind of a priority todo.

2) bugs which were thought invalid/duplicates/etc:
These I wish they could go back (directly) to their previous state
instead of REOPENED.

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

Re: bugzilla.mozilla.org workflow changes

Aakash Desai-2
In reply to this post by Mike Connor-4
> It doesn't cover every single possible workflow, but it's somewhat  
idealized.  WONTFIX vs. INVALID is often a grey area, IMO.

That's great that there's an understanding of the issue known behind the diagram, but it's still community facing. The gray area doesn't belong to people that are read through this diagram for the first time. Those things are learned when they're dealing with bugzilla in the wild. The purpose of any set of documentation is create clarity out of an unclear situation and allow the reader to ask questions that build their knowledge of the system. It's not supposed to force the reader to ask questions about how the system should work as its base.

> The assumption made in the "can it be reproduced under appropriate  
conditions?" decision point is that you follow the STR, and can't repro.

Following the STR and not being able to reproduce the problem can occur from misunderstandings of how people comprehend the steps. That definitely doesn't inherently make a bug invalid.

-- Aakash
 
----- Original Message -----
From: "Michael Connor" <[hidden email]>
To: "Aakash Desai" <[hidden email]>
Cc: "L. David Baron" <[hidden email]>, [hidden email]
Sent: Tuesday, March 31, 2009 9:51:54 AM GMT -08:00 US/Canada Pacific
Subject: Re: bugzilla.mozilla.org workflow changes


On 31-Mar-09, at 11:57 AM, Aakash Desai wrote:

> Lastly, there's still some problems with the workflow diagram linked  
> to in Gervase's e-mail. For the lazy, the link is http://steelgryphon.com/testcases/bugzilla-workflow-9.png 
>  . Here are my gripes on it:
>
> - WontFix is not just for enhancements

It doesn't cover every single possible workflow, but it's somewhat  
idealized.  WONTFIX vs. INVALID is often a grey area, IMO.

> - If a bug is found under inappropriate conditions, then the bug is  
> Invalid, not WorksForMe. If it's not found in the scenario that the  
> bug reporter listed, then it's a WorksForMe.

The assumption made in the "can it be reproduced under appropriate  
conditions?" decision point is that you follow the STR, and can't repro.

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

Re: bugzilla.mozilla.org workflow changes

Frédéric Buclin
In reply to this post by Gervase Markham
Le 31. 03. 09 17:00, L. David Baron a écrit :
> I'd love to have a way to un-confirm a bug, though.  (That is, move
> it from NEW to UNCONFIRMED, because it shouldn't have been
> confirmed.)

You can already do that since Bugzilla 3.2. b.m.o has this NEW -> UNCO
bug status transition disabled.

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

Re: bugzilla.mozilla.org workflow changes

Frédéric Buclin
In reply to this post by Joshua Cranmer-2
Le 31. 03. 09 18:25, Joshua Cranmer a écrit :
> Is there a way to watch components without utilizing QA contact? If
> there is, feel free to make that information more widely visible and
> then get rid of it.

No, you currently cannot watch components. Which is why each component
has its own default QA contact.

LpSolit
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
1234 ... 6