bugzilla.mozilla.org workflow changes
Gervase Markham
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
Jean-Marc Desperrier
> 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.
Benjamin Smedberg
> 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
L. David Baron
> - 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/
Martijn
> On Tuesday 2009-03-31 10:24 +0100, Gervase Markham wrote:
>> ready bugs into it.
>
> 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
> dev-pl...@lists.mozilla.org
> 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
Joshua Cranmer
> 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>
Aakash Desai
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" <dba...@dbaron.org>
To: dev-pl...@lists.mozilla.org
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
Mike Shaver
> 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.
Mike Shaver
> 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
Joshua Cranmer
> On Tue, Mar 31, 2009 at 11:36 AM, Joshua Cranmer <Pidg...@verizon.net> 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.
Aakash Desai
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" <mike....@gmail.com>
To: "Aakash Desai" <ade...@mozilla.com>
Cc: "L. David Baron" <dba...@dbaron.org>, dev-pl...@lists.mozilla.org
Sent: Tuesday, March 31, 2009 9:14:57 AM GMT -08:00 US/Canada Pacific
Subject: Re: bugzilla.mozilla.org workflow changes
Michael Connor
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
Serge Gautherie
> 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.
Boris Zbarsky
> 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
Serge Gautherie
> 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).
Serge Gautherie
> - 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.
Igor Bukanov
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
Aakash Desai
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" <mco...@mozilla.com>
To: "Aakash Desai" <ade...@mozilla.com>
Cc: "L. David Baron" <dba...@dbaron.org>, dev-pl...@lists.mozilla.org
Sent: Tuesday, March 31, 2009 9:51:54 AM GMT -08:00 US/Canada Pacific
Subject: Re: bugzilla.mozilla.org workflow changes
Frédéric Buclin
> 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
Frédéric Buclin
> 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
Boris Zbarsky
> You can already do that since Bugzilla 3.2. b.m.o has this NEW -> UNCO
> bug status transition disabled.
Uh... how hard would it be to ... undo that? With a vengeance.
-Boris
Aakash Desai
-- Aakash
----- Original Message -----
From: "Boris Zbarsky" <bzba...@mit.edu>
To: dev-pl...@lists.mozilla.org
Sent: Tuesday, March 31, 2009 9:54:52 AM GMT -08:00 US/Canada Pacific
Subject: Re: bugzilla.mozilla.org workflow changes
-Boris
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.
I think the answer to that is/should be: if you're not actively working on
it, don't assign it to yourself. If you want to track bugs you're interested
in perhaps working on in the future, use personal bug tags.
--BDS
L. David Baron
Frédéric Buclin
>> You can already do that since Bugzilla 3.2. b.m.o has this NEW -> UNCO
>> bug status transition disabled.
>
> Uh... how hard would it be to ... undo that? With a vengeance.
It's trivial. The checkbox for the NEW -> UNCO transition is currently
unchecked. Just enable it and you can use it immediately.
LpSolit
Michael Connor
On 31-Mar-09, at 12:09 PM, Mike Shaver wrote:
> On Tue, Mar 31, 2009 at 11:36 AM, Joshua Cranmer <Pidg...@verizon.net
> > 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 agree with this sentiment. ASSIGNED and REOPENED can both die, IMO.
That said, I think we have three states we care about:
* Someone reported a bug
* We can reproduce this bug following STR, and more investigation is
warranted.
* We understand this bug and have determined we should fix it, and
have the information needed to fix it.
> (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.)
Yes, we need a better flag system. Working with the tools we have,
etc. Insane pile-o-flags was a lot worse.
> As a developer, also I care about:
>
> - what bugs have clear regression ranges?
Breaking this out, what you really care about is probably more like:
- what bugs have the information needed to just fix the bug.
This is some combination of testcase ready, regression window found,
> 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"
These changes are explicitly designed to solve these problems. The
intent is that the initial bug filing experience, for someone without
bmo privs, can be made simple:
What are you reporting a bug in? Firefox
Can you give us a short summary of the problem? The foozit is broken.
Please give details on how to reproduce this problem? When I click on
the foozit on http://example.com, the foozit blorbles.
That gets dumped to Firefox::General (or, since stuff legitimately
lives there, Firefox::Needs Triage). Then we have a first pass of
triage, which is very fast, basically:
* Is this an RFE or a bug?
** If it's a bug, can I reproduce given the STR?
* If yes, confirm and move to the correct component, unless it's an
obvious dupe.
* If no, give people information on support/filing better bugs/etc and
close the bug.
Basically, this is splitting the traditionally overloaded UNCO vs. NEW
status change into two steps: something anyone can do and then
something requiring deeper knowledge, and removing the need for users
to deal with anything more complicated than telling us their problem.
-- Mike
Michael Connor
On 31-Mar-09, at 1:03 PM, Aakash Desai wrote:
>> 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.
Shaver already mentioned this, as a "we should just collapse those two
together" idea. Basically, the idea is to change process to be
simpler, and avoid grey areas. This was a proposal for how we should
be doing things, rather than documentation on what we do now.
>> 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.
We have historically had a very low rate of return on digging into
poorly-filed bugs. The intent is "try the STR on the same platform,
if it doesn't work, resolve and move on" as the approach to triage.
Common bugs will be filed again, with better STR. Trust me on that one.
-- Mike
Mike Shaver
> 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
I don't know what cross-platformness has to do with it, since REOPENED
doesn't mean "regressed something", it means "was backed out" or "fix
didn't work".
> no matter how good we are at handling them or how "small" of a number they begin to show up in our system.
No, the amount of cost (complexity, confusion, visual noise) we
(users, developers, administrators) should bear is definitely related
to how common the cases are in which the capability gives us value.
>> 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.
That's exactly my point: our process is too complicated.
>> 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.
I know -- those are the things that bug reporters and followers-on care about.
> 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.
People report bugs in order to have action taken on them. They care
about understanding what action is being taken, and what outcome
results, but they also very much care that the action _is_ taken,
which means they have a vestd interest in developers being able to
work with the bugs effectively and avoid things being dropped or
delayed unnecessarily.
It's not like bugzilla is currently optimized for our developers at
the expense of our users -- it's not really optimal for anyone.
Mike
Michael Connor
On 31-Mar-09, at 11:00 AM, 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?
I think the problem is that this is overloaded. NEW in layout means a
lot of things (it is a bug under the spec + has a testcase + lunar
alignment is positive, etc), and effectively creates a barrier to
entry for anyone touching layout bugs. Of course, in my ideal
workflow, UNCO bugs are in a big bucket away from components we're
using for actual work. Only when we can reproduce issues does it get
onto developer/QA radar.
A major goal is that UNCO->NEW is stage one of a filtering process,
and our overtaxed QA people (i.e. the people who create testcases and
find regression windows) can save time by only focusing on bugs people
can actually reproduce.
-- Mike
Frédéric Buclin
> It's not like bugzilla is currently optimized for our developers at
> the expense of our users -- it's not really optimal for anyone.
Do you have concrete proposals? And if possible which is not limited to
Fx teams.
LpSolit
Michael Connor
On 31-Mar-09, at 1:49 PM, Mike Shaver wrote:
> On Tue, Mar 31, 2009 at 12:51 PM, Aakash Desai <ade...@mozilla.com>
> wrote:
>> 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
>
> I don't know what cross-platformness has to do with it, since REOPENED
> doesn't mean "regressed something", it means "was backed out" or "fix
> didn't work".
Or "no, it shouldn't be INVALID/WONTFIX/etc." It really only means
"this was closed, now it isn't" which isn't of a lot of use.
-- Mike
Mike Shaver
Phil Ringnalda
> 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 that I expect *anything* to happen from all this after all the
previous iterations of sound-n-fury, but, please don't remove ASSI until
after Tb3 ships. We're overloading it so that
blockingTb3/assignee=driver/NEW means that driver is assigned the task
of finding an owner and blockingTb3/assignee=driver/ASSI means that
driver happens to be the person who is fixing the bug.
Reed Loden
Mike Shaver <mike....@gmail.com> wrote:
> 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 sure who the "us" is, but I personally use ASSIGNED all the time to
track bugs I'm actively working on versus ones that are just assigned
to me to get to sometime. I would be very unhappy if it just suddenly
disappeared, as I would have to resort to using status whiteboard
entries, which aren't very easy to maintain.
~reed
--
Reed Loden - <re...@reedloden.com>
timeless
> Don't rub it it. :(
Sorry, I just had to rub it *in* :(
Michael Connor
I already intend to do something here, FWIW. I think we can kill
REOPENED for sure, and probably ASSIGNED, since it's generally
underused.
If we added READY as we removed ASSIGNED/REOPENED, you could use that
in place of ASSIGNED, since something without an owner isn't ready...
-- Mike
Frédéric Buclin
> I already intend to do something here, FWIW. I think we can kill
> REOPENED for sure, and probably ASSIGNED, since it's generally underused.
We also use the ASSIGNED status in the Bugzilla product, for the same
reason as described by reed. I would hate to see it going away.
LpSolit
Michael Connor
I don't think that we should leave statuses that aren't widely used
for the sake of a small minority within Mozilla. The idea of
"accepting" a bug is really strange workflow, and opaque to most
people, and just because someone is using it doesn't mean it actually
makes sense for the installation. If the bug isn't something you're
going to do, reassign to nobody@. Isn't "keep track of bugs I
probably will fix eventually" what personal tagging is supposed to
solve, as Benjamin suggests?
In terms of making it easier for people to understand what's going on,
having ambiguous "assigned to me, but I'm not actually doing anything
with it" states is really not a good approach.
-- Mike
Phil Ringnalda
> If we added READY as we removed ASSIGNED/REOPENED, you could use that in
> place of ASSIGNED, since something without an owner isn't ready...
Lol whut? If it isn't READY unless it has an owner, then just pretend
that READY is spelled A-S-S-I-G-N-E-D and we can all go home.
If instead what you mean is that there are four available states,
NEW+nobody@, NEW+somebody@, READY+nobody@, READY+somebody@, then yeah,
we'd do fine with an ASSI => READY migration, we'd just be slightly
perverting the new meaning of NEW by having them assigned (which is
actually fairly reasonable, since NEW and assigned to the QA person who
will then change it to READY and assigned to nobody@ once they write a
testcase might make this worth doing, and NEW and assigned to the
manager who is looking for a victim is an obvious extension of that),
and anyway when you take away people's "my NEW and my ASSI" distinction,
they'll just use "my NEW and my READY" instead, so that's fine.
Frank Wein
> 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.
The meaning of ASSIGNED also changed a bit in the last years (as far as
I know). A few years ago every component had a real person as default
assignee. These days almost every component has nob...@mozilla.org as
assignee, so there's probably not much need for the ASSIGNED state anymore.
Frank
Michael Connor
Yeah, that's basically it. If people really want to preserve the
"it's assigned to me, kinda" workflow. I'd like to just break people
out of that though.
-- Mike
Mike Shaver
Proposals I make would definitely be biased towards facilitating the
scale, pace, and level of interconnectedness of Firefox/Gecko
development, and towards addressing the needs of Firefox/Gecko.
Bugzilla might let us customize things on a per-product level such
that other products in b.m.o can have a workflow and set of tools that
suits their needs better where they differ? (Thunderbird might be
able to have a state for "owner needed", f.e.!)
Mike
GPHemsley
> 2009/3/31 Frédéric Buclin <LpSo...@gmail.com>:
Indeed, this discussion seems to be heavily biased towards Firefox/
Gecko, and forgetting all the many different pieces of software that
use BMO for their bug tracking. The software with smaller communities
and fewer filed bugs (e.g. Bespin) are better able to use all of these
status names. I use ASSIGNED to categorize bugs that are actually the
responsibility of a particular person. Otherwise, I just ignore
whomever the bug is assigned to (usually nobody), because the bug is
not actually "assigned".
And it's true that REOPENED is (should be) used for bugs that were
originally thought to be RESOLVED, but later turned out that they
weren't, for reasons that have already been mentioned: fix backed out,
fix didn't work, etc. As for READY, in the course of reading this
discussion, I've already forgotten what it means. Ready for what?
Triage? Testcase? Fix to be written? Fix to be applied? In my opinion,
READY is a bad name for a new status.
If you want to combine WONTFIX and INVALID, I suppose I could live
with that, even though specific situations can help to differentiate
which would be appropriate. In that case, I'd recommend rolling them
into NOTABUG.
I probably had more things to say, but it took me a while to get
through these 40-something posts, so I've forgotten the rest. I'll
just wait for a reply to the ones I've already mentioned.
And they key idea here is: don't forget the little people and how they
work. Enable/disable status types on a component-by-component basis,
if you have to.
Gordon
Michael Connor
On 31-Mar-09, at 7:59 PM, GPHemsley wrote:
> Indeed, this discussion seems to be heavily biased towards Firefox/
> Gecko, and forgetting all the many different pieces of software that
> use BMO for their bug tracking. The software with smaller communities
> and fewer filed bugs (e.g. Bespin) are better able to use all of these
> status names. I use ASSIGNED to categorize bugs that are actually the
> responsibility of a particular person. Otherwise, I just ignore
> whomever the bug is assigned to (usually nobody), because the bug is
> not actually "assigned".
Yes, and it's not intuitive, or obvious, or transparent. It's opaque
and confusing.
Having an assignee who's not actually assigned to or working on the
bug is one of the weirdest legacies of Netscape-era development
practices. No one's actually given a great explanation of why this is
actually necessary, vs. just not assigning bugs to yourself if you're
not working on them.
> And it's true that REOPENED is (should be) used for bugs that were
> originally thought to be RESOLVED, but later turned out that they
> weren't, for reasons that have already been mentioned: fix backed out,
> fix didn't work, etc.
And what's the value of that status? Once someone changes the owner,
or changes the status, that metadata is gone. If it's worth
preserving, it should be prominent somewhere, regardless of what the
status gets changed to, surely?
> As for READY, in the course of reading this
> discussion, I've already forgotten what it means. Ready for what?
> Triage? Testcase? Fix to be written? Fix to be applied? In my opinion,
> READY is a bad name for a new status.
Ready to fix, i.e. can be picked up and fixed by anyone with the
skills necessary.
> And they key idea here is: don't forget the little people and how they
> work. Enable/disable status types on a component-by-component basis,
> if you have to.
If the "little people" want to use a confusing, counter-intuitive
workflow, they can run their own bugzilla instance, IMO. Or the
Bugzilla people can add per-component workflows. We should not allow
the needs of the many to continue to suffer because some people are
resistant to change. We need to solve problems because the old
process simply doesn't scale to meet our needs, and makes it hard to
grow to meet our volume.
-- Mike
Shawn Wilsher
> If the "little people" want to use a confusing, counter-intuitive
> workflow, they can run their own bugzilla instance, IMO. Or the Bugzilla
> people can add per-component workflows. We should not allow the needs of
> the many to continue to suffer because some people are resistant to
> change. We need to solve problems because the old process simply doesn't
> scale to meet our needs, and makes it hard to grow to meet our volume.
"So say we all."
/sdwilsh
Michael Connor
things around:
Problems:
* The current workflow is not always obvious, especially bug statuses.
* Assigned To vs. ASSIGNED is confusing. For some people, Assigned To
+ NEW doesn't actually mean they're doing anything with the bug.
Around 80% of FIXED bugs go directly from NEW to RESOLVED, so this is
an increasingly minor view, and a legacy of the old system of default
assignees per component.
* REOPENED is a strange state which doesn't have a lot of perceived
value.
* NEW is overloaded, and there is no status showing when a bug is
ready to be fixed by a developer.
Objectives
* Make it easier to get people with less technical/domain expertise
helping with triage.
* Focus domain expert QA on bugs that can be reproduced.
* Make it easier for developers to pick up a bug and fix it.
* (Needs Feedback): Make it clear when work is actually happening.
Draft thinking:
New flow:
UNCONFIRMED
All bugs go into a single bucket, first pass triage makes sure bug is
actually a bug, not an obvious dupe, and can be reproduced. RFE's
will just get confirmed.
NEW
Bugs that need testcases, regression windows, evaluation against
standards, etc. Basically "yes, this is bug, but it's not clear
whether/how to fix it"
READY
Bugs that have the requirements in place to start work.
INPROGRESS
The bug owner is working on a fix.
RESOLVED
The fix has landed and the bug is resolved.
GPHemsley
At no point did I intend to imply that Bugzilla or BMO should not
change to increase productivity and streamline and simply the
interface. I just want to make sure that these decisions are made with
the fact in mind that Firefox and Gecko are not the only pieces of
software that are using the interface.
I don't think that there's any doubt that turning on the ability to
change bugs from NEW back to UNCONFIRMED will help everybody. I think
there should also be the option to bypass the REOPENED status
(assuming it's kept), especially from the dead-end (rather than finish-
line) resolutions, like INVALID or WONTFIX.
And it probably would be good to tie the ASSIGNED status and assignee
field together, and eliminate that annoying and distracting
"nob...@mozilla.org" assignee. Perhaps it would be good to give
resolutions to the REOPENED status, too? Such as BACKEDOUT or WRONGFIX
or something?
As for assigning a bug to yourself just to keep track of it, isn't
that what CCing is for?
The fact that I needed you to explain to me what "READY" meant means
that it's not a good a name. Perhaps READYTOFIX is a better choice, if
you're going to go with that option? I think it's a good idea to
indicate the different steps in a bug's life, as there are certainly
some that are missing.
But I don't think it would be useful to do a one-for-one switch, or to
worry about whether everyone would use every possible status.
Different people or components will do different things, whatever's
best for them. That's what I meant when I said not to forget about the
little people.
Gordon
Shawn Wilsher
least how some people use it, is now INPROGRESS, yes?
To be clear, I'm not saying this isn't also different. It's much
clearer (to end users, and I think other developers) than the current
setup, and I don't see how it breaks anybody's current workflow if they
use the "NEW but assigned to me means I might fix it later" crazy thing.
Cheers,
Shawn
Michael Connor
On 31-Mar-09, at 10:29 PM, Gordon P. Hemsley wrote:
> At no point did I intend to imply that Bugzilla or BMO should not
> change to increase productivity and streamline and simply the
> interface. I just want to make sure that these decisions are made
> with the fact in mind that Firefox and Gecko are not the only pieces
> of software that are using the interface.
I don't think you can design well with "all things to all people" as a
goal. If we have to complicate the interface for the primary
consumers of the UI because of the needs of small projects, I think
that's a bad plan.
> I don't think that there's any doubt that turning on the ability to
> change bugs from NEW back to UNCONFIRMED will help everybody.
I doubt this will help everybody, or even a significant minority.
Outside of layout, no one uses UNCO as more than a black hole, afaict.
> And it probably would be good to tie the ASSIGNED status and
> assignee field together, and eliminate that annoying and distracting
> "nob...@mozilla.org" assignee.
How would you indicate unassigned bugs?
> Perhaps it would be good to give resolutions to the REOPENED status,
> too? Such as BACKEDOUT or WRONGFIX or something?
I don't think that metadata is very useful in the long run, and can
simply be in a comment.
> As for assigning a bug to yourself just to keep track of it, isn't
> that what CCing is for?
>
> The fact that I needed you to explain to me what "READY" meant means
> that it's not a good a name. Perhaps READYTOFIX is a better choice,
> if you're going to go with that option? I think it's a good idea to
> indicate the different steps in a bug's life, as there are certainly
> some that are missing.
Yeah, being more verbose might be useful.
-- Mike
Michael Connor
people can stop worrying about premature confirmation, and so we can
have a clearer "this has the info needed to just hop in and fix it"
state. And it focuses one possible use for ASSIGNED, and makes the
other uses not part of the flow, because that's really just individual
record-keeping, and not really a useful or understandable status.
It's the same number of statuses, but it is meant to be unambiguous
and progressive through the flow of actually fixing a bug.
-- Mike
> <sdwilsh.vcf>
Michael Connor
On 31-Mar-09, at 10:42 PM, Mike Shaver wrote:
> On Tue, Mar 31, 2009 at 10:40 PM, Michael Connor
> <mco...@mozilla.com> wrote:
>>> And it probably would be good to tie the ASSIGNED status and
>>> assignee
>>> field together, and eliminate that annoying and distracting
>>> "nob...@mozilla.org" assignee.
>>
>> How would you indicate unassigned bugs?
>
> Have bugs start in UNASSIGNED rather than NEW? Dunno if reopening
> should then go to UNASSIGNED or ASSIGNED(previous person), but I bet
> we can have a long thread about it and not come to a crisp conclusion.
> :)
I think I like the idea of assignee being whoever is responsible for
the bug at this point. For QA who are tasked with creating testcases,
etc, we should assign to them until that task is complete. I also
don't think we can have a null assignee, though I kinda want to rename
nobody to unass...@mozilla.bugs and kill the realname stuff.
Maybe we want:
UNCONFIRMED
CONFIRMED
READYTOFIX
INPROGRESS
RESOLVED
-- Mike
GPHemsley
> On 31-Mar-09, at 10:42 PM, Mike Shaver wrote:
>
> > On Tue, Mar 31, 2009 at 10:40 PM, Michael Connor
> > <mcon...@mozilla.com> wrote:
> >>> And it probably would be good to tie the ASSIGNED status and
> >>> assignee
> >>> field together, and eliminate that annoying and distracting
> >>> "nob...@mozilla.org" assignee.
>
> >> How would you indicate unassigned bugs?
>
> > Have bugs start in UNASSIGNED rather than NEW? Dunno if reopening
> > should then go to UNASSIGNED or ASSIGNED(previous person), but I bet
> > we can have a long thread about it and not come to a crisp conclusion.
> > :)
>
> I think I like the idea of assignee being whoever is responsible for
> the bug at this point. For QA who are tasked with creating testcases,
> etc, we should assign to them until that task is complete. I also
> don't think we can have a null assignee, though I kinda want to rename
>
> Maybe we want:
>
> UNCONFIRMED
> CONFIRMED
> READYTOFIX
> INPROGRESS
> RESOLVED
>
> -- Mike
Yes, this is an excellent list (but don't forget VERIFIED!). It would
certainly work for most people, myself included. As for the assignee,
I do like switching from nobody to unassigned, but I disagree about
nuking the real name stuff. However, would it be possible to have
different default unassigned assignees per component (e.g.
unass...@bespin.mozilla.bugs)? Or would that not be useful?
And are the QA fields used for anything but tracking? Can we nuke
those, too, and allow tracking of components, instead?
These are the kinds of changes that apply to everybody, and aren't
specially tailored to Firefox/Gecko. I'm happy so far.
Gordon
Michael Connor
On 31-Mar-09, at 11:20 PM, GPHemsley wrote:
> However, would it be possible to have
> different default unassigned assignees per component (e.g.
> unass...@bespin.mozilla.bugs)? Or would that not be useful?
It's possible, though I don't know if it's useful. It's just a
placeholder, after all, and having different placeholders doesn't seem
to have any really obvious benefits.
> And are the QA fields used for anything but tracking? Can we nuke
> those, too, and allow tracking of components, instead?
That's our current workaround for "component watching isn't supported
yet." Please don't make that blood vessel in shaver's brain pop. Or
better yet, if someone would please just fix that bug, I will find a
way to reward you with... something expensive and delicious. I bet
people would gladly throw into that pool.
> These are the kinds of changes that apply to everybody, and aren't
> specially tailored to Firefox/Gecko. I'm happy so far.
Shocking. ;)
-- Mike
Philip Chee
> On 31-Mar-09, at 3:58 PM, Frédéric Buclin wrote:
>> We also use the ASSIGNED status in the Bugzilla product, for the
>> same reason as described by reed. I would hate to see it going away.
>
> I don't think that we should leave statuses that aren't widely used
> for the sake of a small minority within Mozilla. The idea of
Hmm. What makes you think that we are the "small minority" that uses
ASSIGNED rather than you who don't?
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
John J. Barton
...
> 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.
>
+1! Make a few friends and rename both states "SORRY".
jjb
Michael Connor
On 1-Apr-09, at 12:01 AM, Philip Chee wrote:
> On Tue, 31 Mar 2009 16:33:51 -0400, Michael Connor wrote:
>> On 31-Mar-09, at 3:58 PM, Frédéric Buclin wrote:
>
>>> We also use the ASSIGNED status in the Bugzilla product, for the
>>> same reason as described by reed. I would hate to see it going away.
>>
>> I don't think that we should leave statuses that aren't widely used
>> for the sake of a small minority within Mozilla. The idea of
>
> Hmm. What makes you think that we are the "small minority" that uses
> ASSIGNED rather than you who don't?
Data. Something like 80% of the bugs fixed in the last two weeks went
from NEW to RESOLVED.
-- Mike
Philip Chee
I'm convinced. But we will be getting INPROGRESS won't we? That would
make bugzilla queries easier for me at least.
timeless
> Problems:
>
> * The current workflow is not always obvious, especially bug statuses.
> * Assigned To vs. ASSIGNED is confusing.
the simplest fix is changing ASSIGNED to ACCEPTED.
(this is something bugzilla's out of the box behavior should change,
to fix the confusion, it isn't something we should necessarily use for
our install.)
> For some people, Assigned To + NEW
> doesn't actually mean they're doing anything with the bug.
Oddly, Sun *adds* more steps. one is "INPROGRESS"
> Around 80% of
> FIXED bugs go directly from NEW to RESOLVED, so this is an increasingly
> minor view, and a legacy of the old system of default assignees per
> component.
> * REOPENED is a strange state which doesn't have a lot of perceived value.
> * NEW is overloaded, and there is no status showing when a bug is ready to
> be fixed by a developer.
> Objectives
> * Make it easier to get people with less technical/domain expertise helping
> with triage.
> * Focus domain expert QA on bugs that can be reproduced.
> * Make it easier for developers to pick up a bug and fix it.
> * (Needs Feedback): Make it clear when work is actually happening.
> New flow:
> UNCONFIRMED
> NEW
> READY
> INPROGRESS
> RESOLVED
http://defect.opensolaris.org/bz/page.cgi?id=fields.html#status
NEW
This bug has recently been added to the assignee's list of bugs
and must be processed. Bugs in this state may be accepted, and become
ASSIGNED, passed on to someone else, and remain NEW, or resolved and
marked RESOLVED.
INCOMPLETE
This bug needs more information from the submitter before it can
be properly evaluated, or perhaps even categorized.
ACCEPTED
This bug has enough information to be properly categorized and
prioritized, and possibly enough to be evaluated and assigned.
CAUSEKNOWN
This bug has been evaluated, and the root cause of the problem
identified. The evaluation of the bug should be placed in a comment
field.
FIXUNDERSTOOD
The fix for this bug is understood, even if no implementation has
started yet. The plan for the fix should be placed in a comment field.
FIXINPROGRESS
The fix for this bug is underway.
* I'm not sure they've fixed all of their step descriptions, and
they're talking about touch ups at the moment.
avatr...@gmail.com
> UNCONFIRMED
> NEW
> READY
> INPROGRESS
> RESOLVED
(This is mkanat, but Google Groups won't let me use alternate email
addresses even if I have them in my Google Account.)
So, I think about these sorts of things for a living. My full-time
job is helping people configure and customize their Bugzilla. I'll say
that I've spent no small time thinking about Bugzilla usage in the
last many years that I have been working on Bugzilla.
The workflow that mconnor has proposed here is probably the best
simple workflow that there could be, although some projects may also
want a VERIFIED state (though I can tell you that at least for the
Bugzilla product, it adds little value). However, I would change NEW
to CONFIRMED, for clarity's sake.
When designing a status workflow, there are two questions to ask: 1)
What is the actual process a bug goes through. 2) What key information
does the status field tell us about that process that other fields
don't already tell us?
Example of a useless status: The old definition of ASSIGNED ("I
accept that I am assigned this bug") is useless because the Assignee
field already tells us that.
Useful status: INPROGRESS--it tells us something that no other field
tells us--that the person is actually working on the bug right now, or
that work has begun.
The actual process a bug goes through varies depending on the bug.
Let's say that it's a defect in a large project like Core or Firefox.
Although I haven't done triage for those products in many years, I
would imagine the process is still somewhat similar:
1) A bug is filed. If it is filed by a developer or a trusted QA
technician, it is automagically CONFIRMED, otherwise it is
UNCONFIRMED.
2) Somebody confirms the bug if it is UNCONFIRMED, or closes the
bug.
3) Now that we know it's a bug, somebody has to decide (a) what the
priority of the bug fix should be and (b) who should be fixing it.
Depending on the organization and the product, these happen in
different orders, or sometimes simultaneously. Sometimes the assignee
does the prioritization. This all doesn't matter, because the Priority
and the Assignee field cover this stage, and we don't need a status
for it.
4) Somebody works on the bug. Currently there is no field that tells
us it's being worked on. In the Bugzilla product, we use the ASSIGNED
state for this. (If you do make an INPROGRESS state, please just
rename ASSIGNED, don't delete ASSIGNED. People can reset their bugs to
NEW if they are not actually INPROGRESS.)
5) A patch is posted. We know this because well...a patch is posted.
6) We go through the review process. We know this is happening
because of flags.
7) The patch is committed. We have a status for this: RESOLVED
FIXED.
That comprises the entire actual significant engineering process for
fixing any bug in any product, really. Depending on how much
procrastination you want to go through or how massively many bugs you
have, you could also have a CAUSEKNOWN status, where we know what the
bug is but haven't fixed it yet. I think it requires a tremendous
number of engineers and a tremendous number of bugs for such a status
to actually become useful, and I'd tend to think that it would be
either so transient as to be useless (as bugs are almost always
patched shortly after the cause is known) or merely a method of
procrastination ("Well, I've found the cause, now I should move the
status and go on to something else, since the existence of this status
validates the fact that merely finding a cause is a significant-enough
amount of work to do on a bug").
By the way, "NEW" is a useless status as well, I think--we can tell
that a bug is new by the date it was reported, the lack of comments,
and the lack of changes to it. That's how I actually tell that bugs
are new.
-Max
avatr...@gmail.com
> Or better yet, if someone would please just fix that bug, I will find a
> way to reward you with... something expensive and delicious. I bet
> people would gladly throw into that pool.
How about funding, or hiring somebody to add that feature upstream?
That would be an effective way to actually get that feature into a
future version of Bugzilla. I wrote an initial patch for it, but I
just don't have the time to commit to completing it, as I spend most
of my time these days doing the work that pays my bills and not the
free work that I do on Bugzilla.
-Max
Gervase Markham
> We have historically had a very low rate of return on digging into
> poorly-filed bugs.
Yes. A while back I did some research, the results of which are on my blog:
http://weblogs.mozillazine.org/gerv/archives/2008/09/thoughts_on_bug_volume.html
Gerv
Gervase Markham
> +1! Make a few friends and rename both states "SORRY".
You know, I was going to object because I couldn't think of a state name
which covered both WONTFIX and INVALID. But this is a good candidate :-)
Gerv
Gervase Markham
> The meaning of ASSIGNED also changed a bit in the last years (as far as
> I know). A few years ago every component had a real person as default
> assignee. These days almost every component has nob...@mozilla.org as
> assignee, so there's probably not much need for the ASSIGNED state anymore.
You mean that if there's a non-default assignee, then the bug should
automatically be considered ASSIGNED?
I think that a lot of bugs would need to be changed to make that true.
Gerv
Gervase Markham
> Don't we already have such a distinction: UNCONFIRMED vs. NEW?
> What does this *additional* distinction add?
See Mike's workflow for an explanation of how the states differ.
> 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.)
We can certainly enable that transition in five minutes, if it's agreed
it's a good idea.
Gerv
Gervase Markham
> I filed https://bugzilla.mozilla.org/show_bug.cgi?id=486144 on
> enabling this feature.
This has now been done.
Gerv
Gervase Markham
> 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.
But no-one uses it like that, because lots of other sorts of bugs are
also REOPENED. We use the "regression" keyword instead.
Gerv
Gervase Markham
> Not sure who the "us" is, but I personally use ASSIGNED all the time to
> track bugs I'm actively working on versus ones that are just assigned
> to me to get to sometime.
I think mconnor's point is that, in a collaborative system, this type of
assignment is basically a bit dog-in-the-manger. "No, no-one else can
fix this bug because it's assigned to me. When will it get fixed? When I
get around to it."
If you want to keep track of bugs you might fix someday, can you use
personal keywords?
Gerv
Gervase Markham
> Indeed, this discussion seems to be heavily biased towards Firefox/
> Gecko, and forgetting all the many different pieces of software that
> use BMO for their bug tracking. The software with smaller communities
> and fewer filed bugs (e.g. Bespin) are better able to use all of these
> status names. I use ASSIGNED to categorize bugs that are actually the
> responsibility of a particular person. Otherwise, I just ignore
> whomever the bug is assigned to (usually nobody), because the bug is
> not actually "assigned".
Right. So you don't need ASSIGNED. assignee=nob...@mozilla.org ==
unassigned. assignee=somebody == ASSIGNED.
> And it's true that REOPENED is (should be) used for bugs that were
> originally thought to be RESOLVED, but later turned out that they
> weren't, for reasons that have already been mentioned: fix backed out,
> fix didn't work, etc.
Enhancement we decided in fact to implement rather than WONTFIX, bug
which seemed INVALID but was not... The point is that currently,
REOPENED does not do what you hope it does. And anyway, such bugs are
normally very much on someone's radar. They don't need special flagging.
> As for READY, in the course of reading this
> discussion, I've already forgotten what it means. Ready for what?
> Triage? Testcase? Fix to be written? Fix to be applied? In my opinion,
> READY is a bad name for a new status.
Ready to be fix. Given that to be fixed is the raison d'etre of bugs, I
don't think it's that confusing.
> If you want to combine WONTFIX and INVALID, I suppose I could live
> with that, even though specific situations can help to differentiate
> which would be appropriate. In that case, I'd recommend rolling them
> into NOTABUG.
That would match what GNOME does, I think.
> And they key idea here is: don't forget the little people and how they
> work. Enable/disable status types on a component-by-component basis,
> if you have to.
Unfortunately, that's not possible.
Gerv
Gervase Markham
> Example of a useless status: The old definition of ASSIGNED ("I
> accept that I am assigned this bug") is useless because the Assignee
> field already tells us that.
I think this is key. We need to apply the DRY principle to the Bugzilla
interface. If a bit of information is in two independent places (e.g.
non-nobody assignee and ASSIGNED state) we should eliminate one.
> state for this. (If you do make an INPROGRESS state, please just
> rename ASSIGNED, don't delete ASSIGNED. People can reset their bugs to
> NEW if they are not actually INPROGRESS.)
I agree; but I think we should first work out what's ideal, then work
out how to and whether we can get there from here.
> By the way, "NEW" is a useless status as well, I think--we can tell
> that a bug is new by the date it was reported, the lack of comments,
> and the lack of changes to it. That's how I actually tell that bugs
> are new.
I think it's a poor name; I agree CONFIRMED would be better.
Gerv
Gervase Markham
> However, would it be possible to have
> different default unassigned assignees per component (e.g.
> unass...@bespin.mozilla.bugs)? Or would that not be useful?
This would be very unuseful, because it would complicate queries for
unassigned bugs. If you want to watch a particular component, there's
already per-component QA contacts for that.
> And are the QA fields used for anything but tracking? Can we nuke
> those, too, and allow tracking of components, instead?
If you write the patch :-)
Gerv
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.
But that's not actually true. WONTFIX, INVALID or DUPLICATE bugs can all
be reopened.
> 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.
No, it means it's been reopened. All bugs which are reopened go there
first. :-)
> 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)
Except that they shouldn't; that's why we have the ASSIGNED state, and a
checkbox on the patch submission page to make setting it really easy.
> 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 .
Right, although a textual description in this case is far harder to
understand than a diagram. In any case, we are suggesting modifying the
life cycle - the fact that what I'm proposing is not what necessarily
happens now is a feature, not a bug. :-)
> - 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.
Sure, there are a few tweaks that need to be made. But let's look at the
big picture for now.
Gerv
Gervase Markham
> I propose a zero-net-complexity rule for our bugzilla. If you add a
> state, you have to remove one.
Good rule :-)
> 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.
What would you call the merged state?
> (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.)
Hey, you're the engineering boss. Tell them not to do that ;-P
> 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.
QA contact we could disable today, if we didn't need it for component
watching. Hardware, we could write a patch to hide.
> Here are the things I care about as an engineering/product manager:
>
> - what bugs have had work done on them?
Does this mean that you would want to distinguish bugs which were fixed
and then reopened from bugs which had just arrived in some ready-to-fix
state?
> - 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)
New Charts should allow you to set up queries for all these things.
However, I'm not sure if it's still a bit buggy. One of these decades,
I'll go back and finish it properly. :-|
> - what bugs have patches? what bugs have test cases?
We have a "patch" attachment flag and an "in-testsuite" bug flag. Does
that do the job, or do you need more?
> - in what *@(#&*@*#&@ component should I file this bug I just found?
Yeah, yeah :-) There's a SoC project to improve the bug filing process.
> - why can I still not watch components?
Would it be overly-controversial to answer "because no-one has yet paid
one of the many people on
<http://www.bugzilla.org/support/consulting.html> to implement it, and
further paid them to make sure it's upstreamed"?
> - 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?
See above :-)
Gerv
Frédéric Buclin
> I thought that bug had a patch from a MoCo (maybe then-MoFo?) person
> some time ago, but it wasn't sufficiently general or something?
Wasn't it something about having a better way to manage bug status per
branch? Maybe I'm wrong. :)
But I agree with mkanat. We are basically two hyperactive developers for
the Bugzilla project: mkanat and me. If one of us (or both of us as we
are currently) is busy (meaning we cannot review each other patches),
the project is hibernating. Having a paid person to work on these two
big tasks (component watching + better branch handling) would highly
help everybody, not only b.m.o and Mozilla people, but also other
Bugzilla installations (because you should be fair enough and accept
that we implement something which can be used upstream).
Keep in mind that you guys want many new features or a different
behavior for some existing features or a different UI for such or such
feature, etc... but none of us is hired to work on Bugzilla, and our
free time is often very limited. Another point is that when we have free
time, we give priority to the Bugzilla project, not b.m.o which is very
Firefox/Gecko-centric. So I think it's easy to complain, but you should
also understand why we cannot go faster. It's not because we don't want
to help (we sure want to), it's because a day has 24 hours only.
LpSolit
Benjamin Smedberg
> Objectives
>
> * Make it easier to get people with less technical/domain expertise
> helping with triage.
> * Focus domain expert QA on bugs that can be reproduced.
> * Make it easier for developers to pick up a bug and fix it.
> * (Needs Feedback): Make it clear when work is actually happening.
I don't think these are intrisically bad objectives, but I'm still worried
that the cost is higher than it's worth.
> NEW
>
> Bugs that need testcases, regression windows, evaluation against
> standards, etc. Basically "yes, this is bug, but it's not clear
> whether/how to fix it"
>
> READY
>
> Bugs that have the requirements in place to start work.
I still am skeptical that the extra state here from NEW to READY (or
whatever we call these statuses) will help developers get work done.
> INPROGRESS
>
> The bug owner is working on a fix.
While I understand that it would be nice for management, or outsiders, or
whoever, to see that a developers claims they are working on a bug, I don't
think this status will be used any more than ASSIGNED is today. I suspect
that bug comments and patches attached is a much better indicator of
somebody working on a bug than any status metadata.
--BDS
Shawn Wilsher
> 5) A patch is posted. We know this because well...a patch is posted.
> 6) We go through the review process. We know this is happening
> because of flags.
information, I think an arbitrary end user who's interested in the state
of a bug will not necessarily understand this.
Cheers,
Shawn
Frédéric Buclin
> While an engineer may understand this based on these bits of
> information, I think an arbitrary end user who's interested in the state
> of a bug will not necessarily understand this.
Then these users should learn how to get this information. I think
that's wrong to think the way mentioned here.
Lpsolit
Mike Shaver
> Le 01. 04. 09 13:54, Mike Shaver a écrit :
>>
>> I thought that bug had a patch from a MoCo (maybe then-MoFo?) person
>> some time ago, but it wasn't sufficiently general or something?
>
> Wasn't it something about having a better way to manage bug status per
> branch? Maybe I'm wrong. :)
No, it was component watching. Myk had a backend patch for component
watching, and was told "this other bug will do it more generally":
https://bugzilla.mozilla.org/show_bug.cgi?id=76794#c49 . That was
after Gerv had, afaict from the bug, a wholly-working patch that
implemented this and more.
Mike
Shawn Wilsher
> Le 01. 04. 09 15:56, Shawn Wilsher a écrit :
> that's wrong to think the way mentioned here.
something is not clear, a person should learn to understand it, instead
of just making it clearer? That's a horrible user experience...
/sdwilsh
Mike Shaver
I'm a user who would like to get this information in bugzilla queries.
It would be materially easier to do so based on something that is
reflected in a state, rather than wrestling with boolean charts every
time (if indeed you can distinguish those cases even with boolean
charts).
Mike
Frédéric Buclin
> Er, what? If I'm reading this correctly, you are saying that if
> something is not clear, a person should learn to understand it, instead
> of just making it clearer? That's a horrible user experience...
Yes, I'm saying exactly that. :)
You cannot solve everything with bug states. And most of the time, the
information would be out of sync (a bug has a patch, but its status is
still NEW/OPEN/READY instead of... I don't know what). I don't care
about an "arbitrary end user" who just reports a bug or two and then
disappear, or who is just curious.
LpSolit
Mike Shaver
> On 31/03/09 16:57, Aakash Desai 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.
>
> But that's not actually true. WONTFIX, INVALID or DUPLICATE bugs can all be
> reopened.
I think those are actually the dominant cases for reopening, in fact:
people disputing the WONTFIX or INVALID label, or undoing an incorrect
dup.
Mike
John J. Barton
>> NEW
>>
>> Bugs that need testcases, regression windows, evaluation against
>> standards, etc. Basically "yes, this is bug, but it's not clear
>> whether/how to fix it"
>>
>> READY
>>
>> Bugs that have the requirements in place to start work.
>
> I still am skeptical that the extra state here from NEW to READY (or
> whatever we call these statuses) will help developers get work done.
Yes, but it can help get others involved. CONFIRMED (was NEW) -> READY
is a transition that non-developers can make possible. (As well as
UNCONFIRMED -> CONFIRMED). By having the dev team focus on READY and
making the bar for development action be high, developers can be more
productive (of course they must help get some bugs to READY).
>
>> INPROGRESS
>>
>> The bug owner is working on a fix.
>
> While I understand that it would be nice for management, or outsiders, or
> whoever, to see that a developers claims they are working on a bug, I don't
> think this status will be used any more than ASSIGNED is today. I suspect
> that bug comments and patches attached is a much better indicator of
> somebody working on a bug than any status metadata.
As a 'whoever', +1. A few developers pre-register their work and focus
on one item at a time. But most of the time INPROGRESS will mean "I
really thought I was going to be able to fix this one that day last
month..."
jjb
GPHemsley
> Maybe we want:
>
> UNCONFIRMED
> CONFIRMED
> READYTOFIX
> INPROGRESS
> RESOLVED
>
> -- Mike
I'm not happy anymore, because people are still discussing the list
with NEW and READY. I still think this list, with CONFIRMED and
READYTOFIX, is the ideal list (with addition of VERIFIED).
Gordon
Reed Loden
Gervase Markham <ge...@mozilla.org> wrote:
> If you want to keep track of bugs you might fix someday, can you use
> personal keywords?
No, they are bugs that I will fix sometime in the future (near or
far), but they just aren't my current priority. In a lot of cases, such
bugs have been assigned to me by my manager to fix.
mconnor's proposal of INPROGRESS would work fine for what I need.
~reed
--
Reed Loden - <re...@reedloden.com>
Michael Connor
On 1-Apr-09, at 6:49 AM, avatr...@gmail.com wrote:
> That comprises the entire actual significant engineering process for
> fixing any bug in any product, really. Depending on how much
> procrastination you want to go through or how massively many bugs you
> have, you could also have a CAUSEKNOWN status, where we know what the
> bug is but haven't fixed it yet. I think it requires a tremendous
> number of engineers and a tremendous number of bugs for such a status
> to actually become useful, and I'd tend to think that it would be
> either so transient as to be useless (as bugs are almost always
> patched shortly after the cause is known) or merely a method of
> procrastination ("Well, I've found the cause, now I should move the
> status and go on to something else, since the existence of this status
> validates the fact that merely finding a cause is a significant-enough
> amount of work to do on a bug").
Actually, READYTOFIX is simply a reflection of the fact that some
people are better at finding bugs and creating testcases, and other
people are better at taking those and creating fixes. We have great
QA people like Tomcat and Martijn who can find bugs and provide
everything needed for a developer to fix the bug. A similar concept
is someone like Alex Faaborg, who is a designer, not a developer, and
his skills are best utilized creating designs for problems, and other
people can then pick up those designs and implement them.
Yes, to some extent it's a function of scale, and for a project that
gets a couple dozen bugs a week it's overkill. For a project that
gets 500+ bugs a week during a slow time, it's more like what we need
to thrive at scale.
-- Mike
Boris Zbarsky
> Actually, READYTOFIX is simply a reflection of the fact that some people
> are better at finding bugs and creating testcases, and other people are
> better at taking those and creating fixes. We have great QA people like
> Tomcat and Martijn who can find bugs and provide everything needed for a
> developer to fix the bug. A similar concept is someone like Alex
> Faaborg, who is a designer, not a developer, and his skills are best
> utilized creating designs for problems, and other people can then pick
> up those designs and implement them.
Precisely. The fact of the matter is, there is no shortage of bugs to
work on; if we can identify the ones with the most bang for the buck
(minimal developer time investment for maximal benefit), that's great.
If we can decrease the time investment while keeping the benefit, that's
great too.
Note that I can minimize a testcase if I need to, and Martijn's fixed
quite a number of layout bugs.... so this is a matter of comparative
advantage, mostly.
-Boris
Michael Connor
Right. I don't mean to silo people. The idea is to separate those
steps to enable people to work in the best possible way for their
skillset. People can and will do everything themselves in some cases,
that's fine, which is why the workflow won't enforce the transitions
(i.e. must go to READYTOFIX, then INPROGRESS, then RESOLVED, etc).
-- Mike
Justin Dolske
>> Hmm. What makes you think that we are the "small minority" that uses
>> ASSIGNED rather than you who don't?
>
> Data. Something like 80% of the bugs fixed in the last two weeks went
> from NEW to RESOLVED.
So doesn't this also imply renaming "ASSIGNED" to "INPROGRESS" is a bit
silly?
[I can't believe I'm actually replying to this thread.]
Justin
L. David Baron
> At the risk of blowing this up even further, I'd like to suggest
> another state that was very useful in other projects I've worked on:
> SUSPENDED, which means "no forward progress can be made on this bug
> until some external event happens."
>
> This is for bugs like 403526, 93725, and 451134, which are waiting for
> the CSS committee to make a decision that will determine the correct
> behavior (or perhaps even whether anything needs to be done at all).
I don't think such a status is particularly useful... at least not
for this case, where we pretty much have the ability to cause such
an external event to happen (e.g., by writing a clear explanation of
the issues and a good proposal for what to do about it).
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Mike Shaver
> [I can't believe I'm actually replying to this thread.]
April Fool's.
Mike
Michael Connor
> On 3/31/09 9:09 PM, Michael Connor wrote:
>
>>> Hmm. What makes you think that we are the "small minority" that uses
>>> ASSIGNED rather than you who don't?
>>
>> Data. Something like 80% of the bugs fixed in the last two weeks went
>> from NEW to RESOLVED.
>
> So doesn't this also imply renaming "ASSIGNED" to "INPROGRESS" is a
> bit silly?
Well, the ASSIGNED state has been used to mean the latter, in many
cases, and that's a useful state to reflect. It's not mandatory, but
it's unambiguous and not harmful, and I know that some people will use
it.
-- Mike
avatr...@gmail.com
> > Le 01. 04. 09 15:56, Shawn Wilsher a écrit :
> >> While an engineer may understand this based on these bits of
> >> information, I think an arbitrary end user who's interested in the state
> >> of a bug will not necessarily understand this.
>
> I'm a user who would like to get this information in bugzilla queries.
> It would be materially easier to do so based on something that is
> reflected in a state, rather than wrestling with boolean charts every
> time (if indeed you can distinguish those cases even with boolean
> charts).
Yeah, I agree that there should be an easier way to get that
information. I don't think adding a new state would be effective,
though--most likely people would just forget to set it.
-Max
avatr...@gmail.com
> Actually, READYTOFIX is simply a reflection of the fact that some
> people are better at finding bugs and creating testcases, and other
> people are better at taking those and creating fixes. We have great
> QA people like Tomcat and Martijn who can find bugs and provide
> everything needed for a developer to fix the bug. A similar concept
> is someone like Alex Faaborg, who is a designer, not a developer, and
> his skills are best utilized creating designs for problems, and other
> people can then pick up those designs and implement them.
>
> Yes, to some extent it's a function of scale, and for a project that
> gets a couple dozen bugs a week it's overkill. For a project that
> gets 500+ bugs a week during a slow time, it's more like what we need
> to thrive at scale.
Yeah, that makes sense. It might be better to handle some of these
things with keywords, though. The "testcase" keyword seems to have
worked somewhat well when there were active triagers (I used it back
in my triage days). A "hasdesign" keyword or a "design" flag would
tell us that a bug has a design. Even just a "readytofix" keyword
might do well, although I can see the argument here for a status.
I do think READYTOFIX is clearer than READY.
-Max
Mike Shaver
> Yeah, I agree that there should be an easier way to get that
> information. I don't think adding a new state would be effective,
> though--most likely people would just forget to set it.
It could be set by default when a patch is attached, just as we
default to changing QA contact when changing components.
Mike
Gervase Markham
> Er, what? If I'm reading this correctly, you are saying that if
> something is not clear, a person should learn to understand it, instead
> of just making it clearer?
In some cases, this is entirely reasonable, modulo a quibble about your
use of the word "clear". A piece of technical documentation about
Mozilla innards could be made easier to understand by someone who knows
very little about the subject by making it a lot longer and assuming
less knowledge. But instead, you expect people to have read other
documents or learnt other things first. Not every document works from
first principles.
Similarly, Bugzilla bugs are optimised for developers getting work done,
not Joe Public wondering when he's going to get a version of Firefox
which has the Home button in the bookmarks bar instead of the toolbar
(for example). That doesn't mean we should be deliberately obscure, but
it does mean we shouldn't work towards non-goals. And "Joe Public
understands what's going on" is a non-goal.
Gerv
Robert Kaiser
> - Abolish the REOPENED state (automatically converting all existing
> REOPENED bugs to NEW) as it adds no useful information.
We currently have a case where it's actually useful: Someone mass-closed
a number of bugs that hadn't been touched for a long time, including
some still-valid RFEs, etc. We then mass-reopened them, but need to go
through them to manually triage them to be either valid or to be closed.
The query we have for this relies on those that are still REOPENED to
still need triaging.
Robert Kaiser
Mike Shaver
> We currently have a case where it's actually useful: Someone mass-closed a
> number of bugs that hadn't been touched for a long time, including some
> still-valid RFEs, etc. We then mass-reopened them, but need to go through
> them to manually triage them to be either valid or to be closed. The query
> we have for this relies on those that are still REOPENED to still need
> triaging.
Sure, but REOPENED as a sigil for that is just a convenient
coincidence. If you didn't have the REOPENED state, you would just
have added a keyword or whiteboard annotation when doing the mass
reopen, right? Seems like it wouldn't be hard, given the presence of
your query, to convert to that even after the fact.
Mike
Robert Kaiser
> On 01/04/09 00:59, GPHemsley wrote:
>> As for READY, in the course of reading this
>> discussion, I've already forgotten what it means. Ready for what?
>> Triage? Testcase? Fix to be written? Fix to be applied? In my opinion,
>> READY is a bad name for a new status.
>
> Ready to be fix. Given that to be fixed is the raison d'etre of bugs, I
> don't think it's that confusing.
At least it was confusing to me until I read about READYTOFIX ;-)
Robert Kaiser
> Maybe we want:
>
> UNCONFIRMED
> CONFIRMED
> READYTOFIX
> INPROGRESS
> RESOLVED
Sounds reasonable to me (even though the line between CONFIRMED and
READYTOFIX seems quite blurry).
Robert Kaiser
Robert Kaiser
Probably, yes. I also didn't mean to insist on that state, just point
out one case where it actually has info right now.
Robert Kaiser