Bugzilla upstream workflow changes, and our response
Gervase Markham
with one modification (the addition of a READY_TO_FIX state).
There have been discussions in the past about changing the workflow (set
of statuses and transitions between them) of bugzilla.mozilla.org to
better reflect our current development practices.
Soon, Bugzilla 4.0 will be released, and some time after that,
bugzilla.mozilla.org will be upgraded to it. One reason this is
significant is that Bugzilla 4.0 comes with a new default set of
statuses, designed based on the last 12 years of experience in Bugzillas
around the world.
The new lifecycle is here:
http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html
There are two new states - CONFIRMED (a replacement for NEW) and
IN_PROGRESS (a replacement for ASSIGNED). CLOSED and REOPENED are no more.
Some of the rationale for this change is here:
http://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-default-status-workflow/
https://bugzilla.mozilla.org/show_bug.cgi?id=486292
We've tried to update the b.m.o. workflow before, e.g. 2 years ago:
http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/80a8f074ab137f10/f9a60aaf914bcd7e
but the effort stalled. (I.e. I failed to drive it to completion.) This
change in the upstream software reopens the question.
I think we should adopt this change. The two removed statuses will not
be missed much (we no longer use CLOSED anyway), and the new names for
the other two better reflect what is going on. Also, even if the changes
were neutral, it is advantageous to be doing the same thing as upstream
Bugzilla.
However, there is one additional change we can consider at the same
time. The idea of having a READY or READY_TO_FIX state in
bugzilla.mozilla.org goes back 6 years, with some proposals from mconnor
and fantasai:
https://bugzilla.mozilla.org/show_bug.cgi?id=264721
http://snarkfest.net/blog/2005/09/28/a-modest-proposal/
http://steelgryphon.com/testcases/bugzilla-workflow-9.png
In the new workflow bug, Max K-A (a lead Bugzilla developer) says that a
READY_TO_FIX state to go between CONFIRMED and IN_PROGRESS makes sense
only for bigger Bugzillas (which we are). Which is why it's not part of
the default set.
I further propose that we add this state at the same time, for the
reasons given in the above proposals. It provides a clear delineation
between "bugs which are QA's problem" (CONFIRMED/RESOLVED) and "bugs
which are dev's problem" (READY_TO_FIX/IN_PROGRESS), with the latter
distinction showing clearly what dev is working on and what they aren't.
Without this change, a CONFIRMED bug could be on QA's plate or dev's
plate - the status doesn't tell us.
It is somewhat complicated to change the workflow for only a part of
Bugzilla (such as one product or component), so we would like to avoid
having to do that. But if you have a strong case for it, make it.
Note: this discussion is _not_ about resolutions (FIXED, DUPLICATE,
WORKSFORME etc.). Those can also be changed, but independently. Let's
have one discussion at a time.
Gerv
Appendix: How We'd Convert
--------------------------
We don't have to wait until Bugzilla 4.0 is released; we can convert
beforehand if necessary. No new 4.0 features are needed to implement this.
The exact algorithm, as implemented by the conversion script shipped
with Bugzilla, would be:
* "NEW" will become "CONFIRMED"
* "ASSIGNED" will become "IN_PROGRESS"
* "REOPENED" will become "CONFIRMED" (and the "REOPENED" status will be
removed)
* "CLOSED" will become "VERIFIED" (and the "CLOSED" status will be
removed)
The history of each bug will also be changed so that it appears that
these statuses were always in existence. Emails will not be sent.
If we adopt the READY_TO_FIX proposal, then initially no bugs would be
in the READY_TO_FIX state.
Benjamin Smedberg
> which are QA's problem" (CONFIRMED/RESOLVED) and "bugs which are dev's
> problem" (READY_TO_FIX/IN_PROGRESS), with the latter distinction showing
> clearly what dev is working on and what they aren't. Without this change, a
> CONFIRMED bug could be on QA's plate or dev's plate - the status doesn't
> tell us.
I'm opposed to current ASSIGNED status, and the new IN_PROGRESS status. Very
few people use them, and I don't think we'll have more luck convincing
people to use them in the future. They mainly serve to confuse newcomers who
ask "why isn't this bug IN_PROGRESS" even though there are attached patches
and the bug is pending review.
I don't have much input on the READY-TO-FIX state other than I'm skeptical
that it will actually help get bugs fixed, but I'm willing to keep my mouth
shut and find out ;-)
--BDS
Axel Hecht
Axel
Mike Connor
> On 10/28/10 10:18 AM, Gervase Markham wrote:
>
>> which are QA's problem" (CONFIRMED/RESOLVED) and "bugs which are dev's
>> problem" (READY_TO_FIX/IN_PROGRESS), with the latter distinction showing
>> clearly what dev is working on and what they aren't. Without this
>> change, a
>> CONFIRMED bug could be on QA's plate or dev's plate - the status doesn't
>> tell us.
>
> I'm opposed to current ASSIGNED status, and the new IN_PROGRESS
> status. Very few people use them, and I don't think we'll have more
> luck convincing people to use them in the future. They mainly serve to
> confuse newcomers who ask "why isn't this bug IN_PROGRESS" even though
> there are attached patches and the bug is pending review.
I think the goal here is to reduce confusion about the state of a bug.
I can figure out the state of a bug without statuses, but that's a lot
more time consuming. ASSIGNED is weirdly named, since there's an
assigned-to field. (As an aside, it'd be great to auto-set IN_PROGRESS
when a patch is attached by the assignee, because that means the
top-level status would reflect reality.)
I try to argue for a minimum of process/overhead with how we do things,
but I think reflecting actual phases of a bug would be beneficial here.
UNCO/CONF/READY/IN_PROGRESS are all distinct, and require different
actions from different people, so it makes sense that we would call
these out at the top level.
It's worth a shot, at least!
-- Mike
David E. Ross
> Headline: Bugzilla 4.0 has a new status workflow. I propose we adopt it,
> with one modification (the addition of a READY_TO_FIX state).
>
> There have been discussions in the past about changing the workflow (set
> of statuses and transitions between them) of bugzilla.mozilla.org to
> better reflect our current development practices.
>
> Soon, Bugzilla 4.0 will be released, and some time after that,
> bugzilla.mozilla.org will be upgraded to it. One reason this is
> significant is that Bugzilla 4.0 comes with a new default set of
> statuses, designed based on the last 12 years of experience in Bugzillas
> around the world.
>
> The new lifecycle is here:
> http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html
Bad URI. Apparently the domain www.bugzilla.org does not exist.
--
David E. Ross
<http://www.rossde.com/>
I am again filtering and ignoring all newsgroup messages posted
through GoogleGroups via Google's G2/1.0 user agent because of the
amount of spam from that source.
Reed Loden
"David E. Ross" <nob...@nowhere.invalid> wrote:
> On 10/28/10 7:18 AM, Gervase Markham wrote [in part]:
<snip>
> > The new lifecycle is here:
> > http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html
>
> Bad URI. Apparently the domain www.bugzilla.org does not exist.
Works fine for me... Check your browser or DNS settings?
~reed
--
Reed Loden
re...@reedloden.com
Benjamin Smedberg
> I try to argue for a minimum of process/overhead with how we do things, but
> I think reflecting actual phases of a bug would be beneficial here.
> UNCO/CONF/READY/IN_PROGRESS are all distinct, and require different actions
> from different people, so it makes sense that we would call these out at the
> top level.
>
> It's worth a shot, at least!
Sure, reflecting the actual phases of the bug would be valuable, if people
*did* it. Given the current design of bugzilla, there is no incentive to
actually change the status from CONF->READY->IN_PROGRESS, and I just don't
think people are going to do it.
You could certainly make things better by preventing the combination of
assignee=nobody + status = IN_PROGRESS. You could also make it better by
optionally being able to change the status to IN_PROGRESS when somebody
attaches a patch. That will reduce friction and increase the likelihood of
success.
But overall, I still think we'd be better off with a single "open" status,
which, when a bug is assigned to nobody, means "ready", and when it's
assigned to somebody, means "in progress". There are edge cases where
somebody is assigned a bug but isn't working on it or doesn't plan to work
on it, but that's already the degenerate case where more metadata probably
won't help.
--BDS
Shawn Wilsher
> I try to argue for a minimum of process/overhead with how we do things,
> but I think reflecting actual phases of a bug would be beneficial here.
> UNCO/CONF/READY/IN_PROGRESS are all distinct, and require different
> actions from different people, so it makes sense that we would call
> these out at the top level.
It's our primary job to communicate clearly to the community what's
going on with the project (via bugs, meeting notes, blog posts, etc),
and being too lazy to change the status of a bug when you start working
on it just isn't a good enough reason to not do this, IMO.
Cheers,
Shawn
Marco Bonardo
I often find myself setting ASSIGNED status on others' bugs. For most
people the new workflow will continue to be the same they use today:
UNCONFIRMED -> CONFIRMED -> assignedTo -> FIXED -> VERIFIED.
Both the suggested new statused are nice changes but will be hard to
enforce them, noticing how common is the above workflow.
Do we expect assignees to remove IN_PROGRESS if they work on other
higher priority stuff and expect to not go back to that bug soonish? Or
is it just indication that the assignee started doing something for the bug?
Regarding READY_TO_FIX, there should also be a defined way to
differentiate what is needed when a bug is not yet ready (testcase,
design, prototype, triaging, ...).
It looks like an inverse replacement for "qawanted". We have about 3500
bugs marked with it and they don't seem to get more traction from the
community, mostly because it's a large set including also pretty old
bugs, and a lot of newer bugs, not marked with it, are requiring the
same attention. From this point of view could make sense an inverse
approach, where any bug needs attention till it has enough info.
If READY is added, imo IN_PROGRESS is needed; a READY bug with an
assignee doesn't give me the idea of being worked on. Looks like
something that is ready for the assignee to _start_ working on.
-m
Asa Dotzler
> On 10/28/10 11:12 AM, Mike Connor wrote:
>
>> I try to argue for a minimum of process/overhead with how we do
>> things, but
>> I think reflecting actual phases of a bug would be beneficial here.
>> UNCO/CONF/READY/IN_PROGRESS are all distinct, and require different
>> actions
>> from different people, so it makes sense that we would call these out
>> at the
>> top level.
>>
>> It's worth a shot, at least!
>
> Sure, reflecting the actual phases of the bug would be valuable, if
> people *did* it.
In the case that people don't do it, we're no worse off. In the case
that people do use the indicators properly, it's a win. That sounds like
a net win to me.
- A
Sheila Mooney
I never really liked the ASSIGNED status much.
I think it would be helpful to understand why people really don't use
the statuses consistently today. The exception here is maybe RESOLVED
since everybody will reliably mark that because it has a direct
benefit. To look at a bit of data; of the 19 Beta7 blockers, only 5 of
them have status=ASSIGNED. The rest are in the NEW state. Does this
reflect the state of things? I suspect not. The bug assigned to
"nobody" isn't really assigned to "nobody". You are required to go
through each bug individually to figure out what is really going on. I
agree that assuming people will adopt the new statuses simply because
they make more sense isn't a reliable motivator.
I like the idea of coupling the statuses with the assigned field
somehow to prevent cases of assigned=nobody and status=IN_PROGRESS and
possibly some other combinations - understanding there are edge cases
here. I think that would be helpful.
In my experience, using status to figure out what is going on is
somewhat limited. There are bugs that can sit in one state for a long
time, let's say CONFIRMED. There might be all kinds of parallel
activities going on - dev investigation, qa investigation. They are
being worked on in some form. What you really don't see is why they
are getting bogged down or what next step we are blocked on. I know
this is kind of off topic from the initial discussion.
On Thu, Oct 28, 2010 at 8:55 AM, Shawn Wilsher <sdw...@mozilla.com> wrote:
> On 10/28/2010 8:12 AM, Mike Connor wrote:
>>
>> I try to argue for a minimum of process/overhead with how we do things,
>> but I think reflecting actual phases of a bug would be beneficial here.
>> UNCO/CONF/READY/IN_PROGRESS are all distinct, and require different
>> actions from different people, so it makes sense that we would call
>> these out at the top level.
>
> This. At the very least, employees of Mozilla should be doing this. It's
> our primary job to communicate clearly to the community what's going on with
> the project (via bugs, meeting notes, blog posts, etc), and being too lazy
> to change the status of a bug when you start working on it just isn't a good
> enough reason to not do this, IMO.
>
> Cheers,
>
> Shawn
>
>
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
>
David E. Ross
Yes, it's working for me now. But I did nothing to change my browser or
DNS settings.
Mike Hommey
> I kind of like the new statuses. I certainly like IN_PROGRESS better.
> I never really liked the ASSIGNED status much.
>
> I think it would be helpful to understand why people really don't use
> the statuses consistently today. The exception here is maybe RESOLVED
> since everybody will reliably mark that because it has a direct
> benefit. To look at a bit of data; of the 19 Beta7 blockers, only 5 of
> them have status=ASSIGNED. The rest are in the NEW state. Does this
> reflect the state of things? I suspect not. The bug assigned to
> "nobody" isn't really assigned to "nobody". You are required to go
> through each bug individually to figure out what is really going on. I
> agree that assuming people will adopt the new statuses simply because
> they make more sense isn't a reliable motivator.
Maybe if the UI was more helpful to follow the workflow, it would work
better. Changing the status can only be done at the bottom of the page,
and assigning bugs to oneself is not as simple as "Add me to CC list".
Some components also have default values for Assigned To that is not
nobody.
Cheers,
Mike
Reed Loden
Mike Hommey <m...@glandium.org> wrote:
> Some components also have default values for Assigned To that is not
> nobody.
Please file bugs on those components (under mozilla.org :: Bugzilla:
Keywords & Components), and they will be fixed.
Mike Hommey
> On Thu, 28 Oct 2010 20:18:30 +0200
> Mike Hommey <m...@glandium.org> wrote:
>
> > Some components also have default values for Assigned To that is not
> > nobody.
>
> Please file bugs on those components (under mozilla.org :: Bugzilla:
> Keywords & Components), and they will be fixed.
I will when I see one. Or maybe a generic bug should be filed to change
it for all components ?
(I see in the history of bugs against mozilla.org :: Bugzilla: Keywords
& Components that there have been quite a lot of requests to change to
nobody in the past, and a few requests to change it to something else)
Mike
David Mandelin
>
>> I try to argue for a minimum of process/overhead with how we do
>> things, but
>> I think reflecting actual phases of a bug would be beneficial here.
>> UNCO/CONF/READY/IN_PROGRESS are all distinct, and require different
>> actions
>> from different people, so it makes sense that we would call these out
>> at the
>> top level.
>>
>> It's worth a shot, at least!
>
> Sure, reflecting the actual phases of the bug would be valuable, if
> people *did* it. Given the current design of bugzilla, there is no
> incentive to actually change the status from CONF->READY->IN_PROGRESS,
> and I just don't think people are going to do it.
incentive to make that change? Speaking just for myself, I'm not sure
who is using the "intermediate" status values, so it's not clear anyone
cares. Also, they tend not to be set now, so I never rely on them, and I
assume others don't either. I find that in order to track the status of
a bug, I have to read the comments.
On a related note, it seems that for certain kinds of bugs (e.g.,
blockers of the next release or two), status flags could be pretty
valuable, but for other kinds of bugs, people might not care too much.
Maybe if someone who is tracking blockers really wants those flags to be
right, they could go around fixing them/asking assignees to keep them up
to date, and we might be able to get the info for the case where we
actually need it.
I guess the point I'm trying to make is that for most bugs, I'm with you
that the open/in_progress is enough. But for cases where we actually
need to schedule or unblock work, we need more information. I might want
even more than "in_progress" someday, like "to start on date X", "ETA
date X", "blocked on bug X", "blocked, see comment X".
> You could certainly make things better by preventing the combination
> of assignee=nobody + status = IN_PROGRESS.
Yes.
> You could also make it better by optionally being able to change the
> status to IN_PROGRESS when somebody attaches a patch. That will reduce
> friction and increase the likelihood of success.
Why not automatically change the status to IN_PROGRESS when a patch is
attached? And how about automatically changing status back to CONFIRMED
if N days go by with no comments or changes from the assignee?
timeless
> Maybe if someone who is
> tracking blockers really wants those flags to be right, they could go around
> fixing them/asking assignees to keep them up to date, and we might be able
> to get the info for the case where we actually need it.
Please *NO*. Nokia management has entire teams of managers whose sole
purpose appears to be asking people to update bug metadata.
This is done by adding comments to bugs.
The result is that we have much much more requests for metadata
comments than we have actual content in our bugs.
> I guess the point I'm trying to make is that for most bugs, I'm with you
> that the open/in_progress is enough. But for cases where we actually need to
> schedule or unblock work, we need more information. I might want even more
> than "in_progress" someday, like "to start on date X", "ETA date X",
> "blocked on bug X", "blocked, see comment X".
> Why not automatically change the status to IN_PROGRESS when a patch is
> attached? And how about automatically changing status back to CONFIRMED if N
> days go by with no comments or changes from the assignee?
At this point why bother having these as actual statuses?
Why not have them as "VIEWS"?
David Mandelin
> On Thu, Oct 28, 2010 at 9:52 PM, David Mandelin<dman...@mozilla.com> wrote:
>> Maybe if someone who is
>> tracking blockers really wants those flags to be right, they could go around
>> fixing them/asking assignees to keep them up to date, and we might be able
>> to get the info for the case where we actually need it.
> Please *NO*. Nokia management has entire teams of managers whose sole
> purpose appears to be asking people to update bug metadata.
> This is done by adding comments to bugs.
>
> The result is that we have much much more requests for metadata
> comments than we have actual content in our bugs.
do post in bugs asking for updates sometimes when there hasn't been
progress in a while, so it's not unprecedented. More routine requests
could use email in order not to clutter up the bugs. But the hope would
be to foster a change in how people communicate their activity on
high-priority bugs, so that such requests would eventually be unnecessary.
>> I guess the point I'm trying to make is that for most bugs, I'm with you
>> that the open/in_progress is enough. But for cases where we actually need to
>> schedule or unblock work, we need more information. I might want even more
>> than "in_progress" someday, like "to start on date X", "ETA date X",
>> "blocked on bug X", "blocked, see comment X".
>> Why not automatically change the status to IN_PROGRESS when a patch is
>> attached? And how about automatically changing status back to CONFIRMED if N
>> days go by with no comments or changes from the assignee?
> At this point why bother having these as actual statuses?
> Why not have them as "VIEWS"?
Reed Loden
Mike Connor <mco...@mozilla.com> wrote:
> I think the goal here is to reduce confusion about the state of a bug.
> I can figure out the state of a bug without statuses, but that's a lot
> more time consuming. ASSIGNED is weirdly named, since there's an
> assigned-to field. (As an aside, it'd be great to auto-set IN_PROGRESS
> when a patch is attached by the assignee, because that means the
> top-level status would reflect reality.)
Can be done with a little bit of work... File a bug?
Reed Loden
Gervase Markham <ge...@mozilla.org> wrote:
> It is somewhat complicated to change the workflow for only a part of
> Bugzilla (such as one product or component), so we would like to avoid
> having to do that. But if you have a strong case for it, make it.
Re-iterating the "complicated" part of the above paragraph, it is
extremely difficult to split the workflow per-product, and as one of
bmo's maintainers, I'm very likely to veto any such request. We already
have too many hacks to manage, and it's really just not worth it.
Reed Loden
We tried the generic thing. It never works. Specific bugs for specific
components bring actual results to fruition.
Paul Biggar
> Maybe if the UI was more helpful to follow the workflow, it would work
> better. Changing the status can only be done at the bottom of the page,
> and assigning bugs to oneself is not as simple as "Add me to CC list".
I think that this is a large part of the problem. I'm new to using
bugzilla on a daily basis, and it is significantly more difficult to
use than, say, code.google.com, though I don't believe the
functionality/workflow is very different.
In particular for this issue, in code.google.com, every change in the
issue (the status, or the owner or the component) appears in the
comments. As well as its intended purpose, this means that people who
read bugs are reminded to do it themselves.
Paul
--
Paul Biggar
Compiler Geek
pbi...@mozilla.com
Christian Legnitto
https://bugzilla.mozilla.org/show_bug.cgi?id=11368
Which I have pretty much finished. Until that's ready you can install the Bugzilla tweaks extension:
https://addons.mozilla.org/en-Us/firefox/addon/187588/
It adds inline history (and other useful functionality) as well.
Thanks,
Christian
Jens Hatlak
will affect all of bmo so I finally chose to add my 2c here as well.
Benjamin Smedberg wrote:
> Sure, reflecting the actual phases of the bug would be valuable, if
> people *did* it. Given the current design of bugzilla, there is no
> incentive to actually change the status from CONF->READY->IN_PROGRESS,
> and I just don't think people are going to do it.
I have always been wondering why everyone keeps saying that. For the
bugs I've been working on (100+), I always set the status according to
my involvement, i.e. I changed it to ASSIGNED once I posted a patch and
committed to finalizing it. Looking at other bugs of the product of my
choice indicated that other people behaved similarly, and I told people
to act accordingly in the rare cases where they didn't do it themselves.
I feel like the issue here is that the above behavior is directly
related to the actions of the most active ("core") developers. If
everyone of this group thinks alike there is no problem, and OTOH if
everyone of this group thinks there is no point, so will all the rest.
Basically it's a vicious circle: No-one sets the status so it's not
reliable so people don't care and don't set it. And the other way round:
If everyone sets it it's reliable, people care, and set it.
I know Firefox/Core has many more bugs, contributors and core developers
than other products on bmo, but still I'd guess it is the group of most
active developers that makes a difference.
Actually I wonder what's so hard about setting the status to ASSIGNED if
one (e.g. as a reviewer) sees that it's wrong. No bug comment addition
needed, just do it. After some time people will get it (bugmail FTW) and
do it themselves.
> You could also make it better by
> optionally being able to change the status to IN_PROGRESS when somebody
> attaches a patch.
Maybe I'm missing something, but doesn't bmo offer you to change the
status to ASSIGNED at the same time as uploading a patch and taking the
bug? (Actually that's a rhetorical question, I've been using that exact
functionality for as long as it exists. If you asked me, there would be
no need for the drop-down, though; if you take it, the status should
automatically become ASSIGNED, and attaching a patch should
automatically tick the Reassignment checkbox.) What really needs
improvement, though, is how to assign a bug to yourself in all the other
screens (filing a new bug, editing an existing one). Having to enter my
own address, despite being logged in, is just hilarious (yes I know how
to use the form manager, thanks).
Also I think it's very helpful to have the status of the bug reflect its
progress. The status appears at the top and bottom of each bug form
while Assigned To is just a field somewhere in the middle of the form,
which I first have to read/comprehend (mail address = assigned, "Nobody;
OK to take..." = not assigned). But maybe that's just a matter of
presentation; we could probably show some indicator (eye catcher)
somewhere if Assigned To contains a mail address.
Anyway, personally I would have just agreed with Gervase's proposal
as-is. If people don't use the new/changed status, what can you lose?
OTOH you'd break the workflow of the products where it already works,
and block yourself from at least giving it a try.
Greetings,
Jens
--
Jens Hatlak <http://jens.hatlak.de/>
SeaMonkey Trunk Tracker <http://smtt.blogspot.com/>
Joshua Cranmer
> I further propose that we add this state at the same time, for the
> reasons given in the above proposals. It provides a clear delineation
> between "bugs which are QA's problem" (CONFIRMED/RESOLVED) and "bugs
> which are dev's problem" (READY_TO_FIX/IN_PROGRESS), with the latter
> distinction showing clearly what dev is working on and what they
> aren't. Without this change, a CONFIRMED bug could be on QA's plate or
> dev's plate - the status doesn't tell us.
I doubt that having the READY_TO_FIX state will actually solve any
problems. The main issue, as I see it, is that there exists a large
number of bugs (tens of thousands, if not hundreds) which are basically
old open bugs that no one has had any time to go back to and try to
triage under modern rules. I feel that adding this new state will cause
us to start having the same discussions in only a few years.
I do, however, applaud the renaming of `NEW.' It will shut up the people
who keep complaining about bugs that "why is this bug NEW when it was
reported XXX years ago?"
Matt Brubeck
> I'm opposed to current ASSIGNED status, and the new IN_PROGRESS status. Very
> few people use them, and I don't think we'll have more luck convincing
> people to use them in the future.
I use the status field to manage my *own* bugs, and keep track of my
bug queue. Even if no one else used it, I would still benefit from
using this status to track my own progress.
If we removed the ASSIGNED/IN_PROGRESS status I could use other fields
like "whiteboard" to replace it, but that would be less convenient in
several ways (not a simple drop-down; other people don't know how to
interpret it; doesn't appear in the default column set for searches
and reports; etc.).
timeless
> On Thu, Oct 28, 2010 at 11:18 AM, Mike Hommey <m...@glandium.org> wrote:
>> Maybe if the UI was more helpful to follow the workflow, it would work
>> better. Changing the status can only be done at the bottom of the page,
>> and assigning bugs to oneself is not as simple as "Add me to CC list".
fwiw, in the old days it was incredibly easy to assign a bug to
oneself, the result of this was people often accidentally took
ownership of bugs instead of giving them to someone else. It was
perhaps amusing.
> I think that this is a large part of the problem. I'm new to using
> bugzilla on a daily basis, and it is significantly more difficult to
> use than, say, code.google.com, though I don't believe the
> functionality/workflow is very different.
Really?
I have a couple of problems w/ google code, but I'll leave that asside.
> In particular for this issue, in code.google.com, every change in the
> issue (the status, or the owner or the component) appears in the
> comments. As well as its intended purpose, this means that people who
> read bugs are reminded to do it themselves.
Hrm, I find this behavior absolutely useless. It probably depends on
the kind of bug and the size of the bug.
If your bug has 5 comments max, then having 2 state notes in it isn't
a big deal.
If your bug has 100 comments, then having 50-200 additional state
notes in it is a huge deal, it's incredibly painful.
That said, as long as I can turn off your "feature", I don't care.
But please don't shove it down my throat. If I want a stupid Bugzilla,
I'll use my employer's.
FWIW, bugzilla has an option to "require" comments for various
actions. When public bugzillas are stupid enough to do this, the
comments end up being "." because the requirement is *stupid*.
When it happens in corporate bugzillas, the comments are worse, much
longer and even less accurate.
An explanation could be useful in some cases. For instance when a
manager marks a flag X+ or X-, I *want* the *manager* to explain *why*
they did this. Not "Marking FOO+", but "Discussed at FOO Meeting on
FOODay, Agreed to FOO+ because <...>".
Sadly, you can't convince managers in corporations to do this.
Actually, that's unfair, the Netscape managers actually were good
enough to do this. (I miss ADT+ and PDT+, instead we have some four
letter word which doesn't get an explanation).
Some people might think Netscape was "bad" or "broken", but they
haven't worked at a bigger company w/ more managers.
The managers otoh do try to demand what they don't do. Ah well.
Note:
In some cases it's easy to mark a bug as ASSIGNED today:
* When attaching a patch to a bug you *don't* own.
In some cases it *isn't* easy to mark a bug as ASSIGNED today:
* If you already own the bug, then attaching a patch in recent
incarnations of bugzilla wouldn't let you change the state.
Reed: please feel free to fix this.
This is ironic since it actively prevents the natural workflow: unco
=> confirmed => proper assignee => <blocked>assigned
Gervase Markham
> assigned-to field. (As an aside, it'd be great to auto-set IN_PROGRESS
> when a patch is attached by the assignee, because that means the
> top-level status would reflect reality.)
I'm sure we can do that. The attachment screen already has the ability
to set bug statuses; we could auto-set it with JS.
Gerv
Gervase Markham
> Do we expect assignees to remove IN_PROGRESS if they work on other
> higher priority stuff and expect to not go back to that bug soonish?
Yes, I think so. We could have this happen automatically if there is,
say, no activity for a month (or some other time limit). We might want
to do it manually for a while and see if that heuristic is good.
> Regarding READY_TO_FIX, there should also be a defined way to
> differentiate what is needed when a bug is not yet ready (testcase,
> design, prototype, triaging, ...).
Yes. But there is a wide range of things that QA might want done (just
as, when a bug is in progress, there's a wide range of things that devs
might want done) so it's probably best to use keywords for these
subdivisions.
> If READY is added, imo IN_PROGRESS is needed; a READY bug with an
> assignee doesn't give me the idea of being worked on. Looks like
> something that is ready for the assignee to _start_ working on.
Right - that's what it's supposed to mean.
Gerv
Gervase Markham
> I like the idea of coupling the statuses with the assigned field
> somehow to prevent cases of assigned=nobody and status=IN_PROGRESS and
> possibly some other combinations - understanding there are edge cases
> here. I think that would be helpful.
We could certainly add some JS to prevent this combination, if we had a
list of all email addresses representing "nobody". I suspect such a list
isn't long, although I don't think it's of length 1 either.
I think there's a case for allowing assignee to be empty (NULL):
https://bugzilla.mozilla.org/show_bug.cgi?id=369078
but timeless makes some good points in comment 1 there.
> In my experience, using status to figure out what is going on is
> somewhat limited. There are bugs that can sit in one state for a long
> time, let's say CONFIRMED. There might be all kinds of parallel
> activities going on - dev investigation, qa investigation. They are
> being worked on in some form. What you really don't see is why they
> are getting bogged down or what next step we are blocked on. I know
> this is kind of off topic from the initial discussion.
It is :-) The STATUS field is not supposed to define exactly what is the
next step for a bug (a la Jesse's "getting bugs done"), because it can
never be fine-grained enough without having too many choices. I think my
proposal captures the big moves, though - from input to QA to Dev to QA
to done.
Gerv
Gervase Markham
> In particular for this issue, in code.google.com, every change in the
> issue (the status, or the owner or the component) appears in the
> comments. As well as its intended purpose, this means that people who
> read bugs are reminded to do it themselves.
https://bugzilla.mozilla.org/show_bug.cgi?id=11368
which clegnitto is working on.
In the mean time:
https://addons.mozilla.org/en-US/firefox/addon/187588/
Gerv
Gervase Markham
> I doubt that having the READY_TO_FIX state will actually solve any
> problems. The main issue, as I see it, is that there exists a large
> number of bugs (tens of thousands, if not hundreds) which are basically
> old open bugs that no one has had any time to go back to and try to
> triage under modern rules.
Yes, and the addition of the READY_TO_FIX state will mean that
developers can differentiate between those which have been triaged, and
those (the majority) which have not.
Gerv
Mark Banner
> On 10/28/2010 10:18 AM, Gervase Markham wrote:
>> I further propose that we add this state at the same time, for the
>> reasons given in the above proposals. It provides a clear delineation
>> between "bugs which are QA's problem" (CONFIRMED/RESOLVED) and "bugs
>> which are dev's problem" (READY_TO_FIX/IN_PROGRESS), with the latter
>> distinction showing clearly what dev is working on and what they
>> aren't. Without this change, a CONFIRMED bug could be on QA's plate or
>> dev's plate - the status doesn't tell us.
>
> I doubt that having the READY_TO_FIX state will actually solve any
> problems. The main issue, as I see it, is that there exists a large
> number of bugs (tens of thousands, if not hundreds) which are basically
> old open bugs that no one has had any time to go back to and try to
> triage under modern rules. I feel that adding this new state will cause
> us to start having the same discussions in only a few years.
I agree, I find it difficulty to believe that READY_TO_FIX will solve
any significant problems.
I have various concerns about this state:
- Ready to fix seems to imply that a test case is required. Generally, I
would say that this is steps to repeat, however that's what we require
for the confirmed state.
So if we now require a testcase, then according to gerv's text, either
QA or the submitter would have to provide part of a test case, or
something before the bug would get looked at before a developer. There
are so many cases where this isn't possible.
For example, I have an issue in Thunderbird where my testcase is to run
Thunderbird possibly with some add-ons. I have no idea on how to reduce
that which is actually wanted for getting the bug solved.
I think the reality is (and I see this frequently in the MailNews
component) is that developers do frequently need to get involved at the
confirmed state.
- So given the above, all ready to fix seems to mean is that we've got a
testcase, so its basically equivalent to our "NEW" plus keyword testcase
flag. A "CONFIRMED" bug would be "NEW" plus no keywords, or keyword
testcase-wanted.
- I have an issue with the wording. I can see users seeing bugs marked
as "Ready to fix" and asking why hasn't it been fixed yet, and causing
more bugspam.
- I think where there is no test-case required (like many of the website
components, release engineering, etc), then the ready state will
frequently cause more bugspam - at least initially, maybe not after a
few years of learning. I could see a lot of bugs going from unconfirmed
-> confirmed -> ready, rather than straight from unconfirmed -> ready.
Having better opt-outs of bugspam would help here. e.g. don't send me
notification when a bug changes to/from ready and nothing else happens
on that bug. (although generally better opt-outs would help anyway).
- Like Joshua, we also seem to have an issue where our QA people don't
have enough time to triage all the unconfirmed bugs, let alone work out
which ones should be confirmed, which ones needs testcases (and do them)
and then get them moved to ready. I think this is something we still
need to resolve but the ready state isn't going to help at this time.
I don't like being so negative, but I'm having a hard time of seeing the
benefits of this state. I think some of the issues can be worked
around/improved with better bugzilla implementation, wording, and
precise definitions, but we need those *before* we get this state (and
to be agreed), not sometime afterwards.
Mark.
Mark Banner
That's not quite true. The attachment screen can do it only if you are
*not* already assigned to the bug. I.e. so you can assign yourself and
the state at the same time as adding the attachment.
If you're already assigned to the bug, then you can't choose to change
the state from the attachment screen.
My recommendation here would be that if a person is attaching a patch
and they are already assigned to the bug, then the default should be to
move the patch to in_progress, or the person can choose to set the state
as something else (or not change at all). There there's flexibility and
means we can do more from one screen, resulting in only one bugmail.
Standard8
Marco Bonardo
> - Ready to fix seems to imply that a test case is required. Generally, I
> would say that this is steps to repeat, however that's what we require
> for the confirmed state.
Not just a testcase, actually a lot of bugs are even just missing good
STRs, or a design mock, or even just perf measures. A lot of bugs have
qawanted keyword but not all the bugs that would need it.
ready_to_fix would invert the situation where clearly any bug needs
enough information to be worked on when it's in confirmed status, so
it's like any bug has qawanted till it's ready, that is more similar to
the reality. With qawanted I don't mean QA has to go through 600
thusands bugs, the community cand the reporter must help here (qawanted
indeed is somehow bad naming choice indeed).
> So if we now require a testcase, then according to gerv's text, either
> QA or the submitter would have to provide part of a test case, or
> something before the bug would get looked at before a developer. There
> are so many cases where this isn't possible.
If a bug does not need further steps it's just ready. I agree the
developer is involved in confirmed and ready statuses, this won't
change. If you think the bug with STRs is enough and a testcase is just
now worth it (too complicated) you mark it as ready. Regarding bugspam I
agree initially there will be a lot of unconf->conf->ready, most likely
one can set some mail filter on it.
> - I have an issue with the wording. I can see users seeing bugs marked
> as "Ready to fix" and asking why hasn't it been fixed yet, and causing
> more bugspam.
Imo this is not a problem, we already have users asking why a bug is not
yet confirmed, why it's not yet assigned, why it's not yet fixed, even
asking why it's fixed if they still see it. Could probably be an issue
when we start. People has to learn about it, but it's not different from
any other status.
> - Like Joshua, we also seem to have an issue where our QA people don't
> have enough time to triage all the unconfirmed bugs, let alone work out
> which ones should be confirmed, which ones needs testcases (and do them)
> and then get them moved to ready. I think this is something we still
> need to resolve but the ready state isn't going to help at this time.
Setting ready should involve developers and the community too,
especially the bug reporter. You want the bug fixed? Then you have to
provide enough information to make it ready. the 3500 qawanted bugs
should teach us that putting all work on QA shoulders is not going to
work (not their fault clearly!).
Marco
Robert Kaiser
> - I have an issue with the wording. I can see users seeing bugs marked
> as "Ready to fix" and asking why hasn't it been fixed yet, and causing
> more bugspam.
Good point. In that light "READY_TO_FIX" is an even worse state than
"NEW" as users probably assume that someone is supposed to work on this
when it is in READY_TO_FIX state, and reality it's just that we just
have enough info that the bug or RFE can be pinpointed.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)
Frédéric Buclin
> Good point. In that light "READY_TO_FIX" is an even worse state than
> "NEW" as users probably assume that someone is supposed to work on this
> when it is in READY_TO_FIX state, and reality it's just that we just
> have enough info that the bug or RFE can be pinpointed.
So why not do it the other way? Create a NEEDINFO status, which comes
between UNCONFIRMED and CONFIRMED.
UNCONFIRMED = untriaged
NEEDINFO = STR are needed, or a reduced testcase, or more information
CONFIRMED = bug is valid, has all the required information for the
developer to work on.
Power users (mostly those with editbugs privs) would file their bugs as
CONFIRMED directly, unless they are unsure of what they found. The other
ones would be forced to file their bugs as UNCONFIRMED, as we do today
with NEW vs UNCONFIRMED bug statuses.
The risk with READY_TO_FIX is that it sounds like READY_TO_LAND
(checkin-needed), at least to me as english is not my native language.
LpSolit
Mark Banner
> Il 29/10/2010 11:40, Mark Banner ha scritto:
>> - Ready to fix seems to imply that a test case is required. Generally, I
>> would say that this is steps to repeat, however that's what we require
>> for the confirmed state.
>
> Not just a testcase, actually a lot of bugs are even just missing good
> STRs, or a design mock, or even just perf measures.
Good STRs is a reasonable point, though not always possible. A design
mock is an interesting question. Generally that's provided by a
developer or UI-expert and not a user/QA person.
>> - Like Joshua, we also seem to have an issue where our QA people don't
>> have enough time to triage all the unconfirmed bugs, let alone work out
>> which ones should be confirmed, which ones needs testcases (and do them)
>> and then get them moved to ready. I think this is something we still
>> need to resolve but the ready state isn't going to help at this time.
>
> Setting ready should involve developers and the community too,
> especially the bug reporter. You want the bug fixed? Then you have to
> provide enough information to make it ready. the 3500 qawanted bugs
> should teach us that putting all work on QA shoulders is not going to
> work (not their fault clearly!).
However, QA (or someone) still has to come along and look at the bug and
determine if it is ready or not. We have to explain that to the
reporters, and we have to explain what's necessary to get it into the
ready state.
Whilst the ready state could work, I'm not convinced we're doing enough
on the passive help (e.g. documentation, bug filing helpers etc) side to
offset the extra workload that it seems to want to introduce.
Standard
Joshua Cranmer
In the near term, we would have to expend serious labor to get the old
morass of untriaged bugs into that possible state. Given that QA is
having difficulty just keeping up with new bugs being filed (at least
for Thunderbird), it doesn't solve anything for developers in the near
term: they still have to look at the CONFIRMED bugs to figure out what
is good and what isn't.
In the long term, given the rate of bug filing to bug fixing, it seems
likely that, again, a large pile of bugs will fall through to the
READY_TO_FIX state and will languish there for years, to the point where
developers are no longer sure about their validity anymore. It also
seems likely that the semantics of these states will alter slightly too,
so that not all the bugs in this state match what the state is supposed
to claim. In other words, we would end up with a similar situation to
what we have now, except that it's in another state.
Robert Kaiser
> So why not do it the other way? Create a NEEDINFO status, which comes
> between UNCONFIRMED and CONFIRMED.
Surely a possibility - though I wonder where the difference between
NEEDINFO and UNCONFIRMED is, actually.
The more I think about it, the less I'm sure about needing an additional
state there.
> The risk with READY_TO_FIX is that it sounds like READY_TO_LAND
> (checkin-needed), at least to me as english is not my native language.
One more source of confusion, true.
E Wong
> The new lifecycle is here:
> http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html
>
> There are two new states - CONFIRMED (a replacement for NEW) and
> IN_PROGRESS (a replacement for ASSIGNED). CLOSED and REOPENED are no more.
>
I might be speaking out of order (being a relatively new dev) so please
correct me if I'm wrong.
To me, the ASSIGNED status makes more sense than IN_PROGRESS which
may not even reflect the truth of the progress. I have a few bugs
which are assigned to me; but they've stalled so having their status
changed to IN_PROGRESS is a misnomer (to me a sort of a lie) since
the bugs are stalled and aren't in progress.
I guess it's a psychological thing such that IN_PROGRESS challenges
the dev to actually work on the bug whereas ASSIGNED allows the dev
to assign him/her self to the bug but take one's time in figuring
it out. (Of course, this would apply to the less-urgent bugs and
not those that require a fix immediately.)
Of course, I cannot deny my workflow could be quite flawed.
1) I look at a bug. If it is something that I could do without a doubt,
I ASSIGN myself to it. If it is something which sounds difficult,
I keep it to NEW and figure it out. Only when I am 100% sure that
I can handle it do I ASSIGN myself.
2) If the progress to the bug has stalled, I can at least keep the
ASSIGNED status so I can keep track of which bugs I have.
(With the new STATUSES, if I'm stalled, I need to reset the
bug to CONFIRMED. The problem I see is if I work on and off
this bug, I foresee multiple bugmails to the assignee and to
the CC.) I guess if I were to do something like that, I'd
likely get a mail from some veteran dev saying along the
lines of "Look. If you are going to work on it, KEEP working
on it or set it to IN_PROGRESS and don't change. Setting
the status to IN_PROGRESS then CONFIRMED, then IN_PROGRESS ad
nauseum irritates me."
>
> However, there is one additional change we can consider at the same
> time. The idea of having a READY or READY_TO_FIX state in
> bugzilla.mozilla.org goes back 6 years, with some proposals from mconnor
> and fantasai:
> https://bugzilla.mozilla.org/show_bug.cgi?id=264721
> http://snarkfest.net/blog/2005/09/28/a-modest-proposal/
> http://steelgryphon.com/testcases/bugzilla-workflow-9.png
>
> In the new workflow bug, Max K-A (a lead Bugzilla developer) says that a
> READY_TO_FIX state to go between CONFIRMED and IN_PROGRESS makes sense
> only for bigger Bugzillas (which we are). Which is why it's not part of
> the default set.
>
I'm finding it a little difficult to understand the difference
between CONFIRMED and READY_TO_FIX in the sense that if the
bug is CONFIRMED, then it should be ready for any developer to
dive in and fix it. Are there cases in which a bug could be
CONFIRMED but not READY_TO_FIX? I understand that a READY_TO_FIX
bug has all the information for the dev to use to create a patch.
I suppose, a CONFIRMED bug could be a bug which is certified to
exist; but, information is lacking. Perhaps I'm a bit dim;
but, is it necessary to have READY_TO_FIX in order for a dev
to say "Ok, I'll start on it." or "I have a patch."? Maybe the
READY_TO_FIX is for new devs like me that need a specific
notice that says "Ok. Since you're a beginner, here is a bug
that has all the necessary information for you to create
a patch." And the CONFIRMED status are for veteran devs?
Edmund
Boris Zbarsky
> I have a few bugs
> which are assigned to me; but they've stalled so having their status
> changed to IN_PROGRESS is a misnomer (to me a sort of a lie) since
> the bugs are stalled and aren't in progress.
So shouldn't their status reflect that, so that someone else who has the
time to work on them right now can pick them up and know he's not
getting in your way?
> I guess it's a psychological thing such that IN_PROGRESS challenges
> the dev to actually work on the bug whereas ASSIGNED allows the dev
> to assign him/her self to the bug but take one's time in figuring
> it out.
Again, this assumes that no one other than "the dev" is interested in
fixing the bug, right?
> I'm finding it a little difficult to understand the difference
> between CONFIRMED and READY_TO_FIX in the sense that if the
> bug is CONFIRMED, then it should be ready for any developer to
> dive in and fix it. Are there cases in which a bug could be
> CONFIRMED but not READY_TO_FIX?
Yes. Example of "confirmed" bug:
If I go to apple.com I can't click on any links.
This is trivial to confirm; you go to the site and try clicking.
To be ready to fix, one needs to have a handle of some sort on what's
going on. For example, some information on the CSS rules involved, JS
involved etc. A developer _could_ gather this information while working
on the bug, of course. But the key point is that this is information
that can be gathered by anyone at all familiar with web technologies and
requires no knowledge whatsoever of Gecko internals. So if we have
people who want to help and know JS+CSS but not really our layout code,
it makes the most sense for them to help by locating the relevant
information and putting it in the bug in a form that doesn't require a
developer trying to fix it to sort through megabytes of site javascript.
And the point is we do have people like that, and they do exactly that
sort of thing, and it's very much appreciated. All READY_TO_FIX is
about is having a way for them to indicate "ok, I'm done here; someone
familiar with the Mozilla code needs to take over at this point".
> I suppose, a CONFIRMED bug could be a bug which is certified to
> exist
Right, that's the definition.
> but, is it necessary to have READY_TO_FIX in order for a dev
> to say "Ok, I'll start on it." or "I have a patch."?
No, but focusing on READY_TO_FIX bugs helps to prioritize time where it
will help the most....
-Boris
L. David Baron
> On 10/28/2010 10:18 AM, Gervase Markham wrote:
> >I further propose that we add this state at the same time, for the
> >reasons given in the above proposals. It provides a clear
> >delineation between "bugs which are QA's problem"
> >(CONFIRMED/RESOLVED) and "bugs which are dev's problem"
> >(READY_TO_FIX/IN_PROGRESS), with the latter distinction showing
> >clearly what dev is working on and what they aren't. Without this
> >change, a CONFIRMED bug could be on QA's plate or dev's plate -
> >the status doesn't tell us.
>
> I doubt that having the READY_TO_FIX state will actually solve any
> problems.
If we use it well, I think it could.
In particular, if module owners/peers know how to fix a bug, but
don't have time, they could explain how the bug should be fixed in
the bug and change its state to READY_TO_FIX. This provides a
source of bugs that newcomers could approach more easily.
(I'm looking at the distinction between CONFIRMED and READY_TO_FIX
as the difference between "Yes, this Web page doesn't seem to work
correctly" and "We should do X to make it work correctly." I'm not
sure if that was the intended distinction, though.)
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Dustin J. Mitchell
> In particular, if module owners/peers know how to fix a bug, but
> don't have time, they could explain how the bug should be fixed in
> the bug and change its state to READY_TO_FIX. This provides a
> source of bugs that newcomers could approach more easily.
As a n00b, this would be very useful for me. I can find such bugs
already, but it involves a lot of reading between lines about stuff I
don't understand very well yet.
My $0.02.
Dustin
Mike Connor
been talking about this for five years, and every thread devolves into
speculation and forks in many ways. Either we do nothing, or we try
something to see if it works. I would propose that we take the
following actions, and revisit later:
* I don't think there is any opposition to removing REOPENED or CLOSED.
These make sense, and should be done immediately.
* NEW -> CONFIRMED seems to be generally accepted, so let's rename it
(pick a time, preferably before a weekend, so queries don't break)
* ASSIGNED -> IN_PROGRESS seems entirely rational, and ASSIGNED vs.
assigned-to is a point of confusion. IN_PROGRESS remains optional, but
we should explore auto-changing to that when patches are added to bugs.
This can be done at the same time as the NEW->CONFIRMED rename.
* READY_TO_FIX is something we can add without code changes, and it
seems clear that certain parts of the project can and will make good use
of this status, so I think we should try it and see if it actually works.
If people don't want to use IN_PROGRESS and READY_TO_FIX, that's fine.
If the cost is deemed too high after a year, we can always cull one or
both. But we've been talking for five years about a better, more
transparent workflow, and we keep ending up with the same proposal, so
let's try it for 6-12 months, and then we'll have data to discuss,
instead of speculation.
-- Mike
On 28/10/2010 10:18 AM, Gervase Markham wrote:
> Headline: Bugzilla 4.0 has a new status workflow. I propose we adopt
> it, with one modification (the addition of a READY_TO_FIX state).
>
> There have been discussions in the past about changing the workflow
> (set of statuses and transitions between them) of bugzilla.mozilla.org
> to better reflect our current development practices.
>
> Soon, Bugzilla 4.0 will be released, and some time after that,
> bugzilla.mozilla.org will be upgraded to it. One reason this is
> significant is that Bugzilla 4.0 comes with a new default set of
> statuses, designed based on the last 12 years of experience in
> Bugzillas around the world.
>
> The new lifecycle is here:
> http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html
>
> There are two new states - CONFIRMED (a replacement for NEW) and
> IN_PROGRESS (a replacement for ASSIGNED). CLOSED and REOPENED are no
> more.
>
> Some of the rationale for this change is here:
> http://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-default-status-workflow/
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=486292
>
> We've tried to update the b.m.o. workflow before, e.g. 2 years ago:
> http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/80a8f074ab137f10/f9a60aaf914bcd7e
>
> but the effort stalled. (I.e. I failed to drive it to completion.)
> This change in the upstream software reopens the question.
>
> I think we should adopt this change. The two removed statuses will not
> be missed much (we no longer use CLOSED anyway), and the new names for
> the other two better reflect what is going on. Also, even if the
> changes were neutral, it is advantageous to be doing the same thing as
> upstream Bugzilla.
>
> However, there is one additional change we can consider at the same
> time. The idea of having a READY or READY_TO_FIX state in
> bugzilla.mozilla.org goes back 6 years, with some proposals from
> mconnor and fantasai:
> https://bugzilla.mozilla.org/show_bug.cgi?id=264721
> http://snarkfest.net/blog/2005/09/28/a-modest-proposal/
> http://steelgryphon.com/testcases/bugzilla-workflow-9.png
>
> In the new workflow bug, Max K-A (a lead Bugzilla developer) says that
> a READY_TO_FIX state to go between CONFIRMED and IN_PROGRESS makes
> sense only for bigger Bugzillas (which we are). Which is why it's not
> part of the default set.
>
> I further propose that we add this state at the same time, for the
> reasons given in the above proposals. It provides a clear delineation
> between "bugs which are QA's problem" (CONFIRMED/RESOLVED) and "bugs
> which are dev's problem" (READY_TO_FIX/IN_PROGRESS), with the latter
> distinction showing clearly what dev is working on and what they
> aren't. Without this change, a CONFIRMED bug could be on QA's plate or
> dev's plate - the status doesn't tell us.
>
> It is somewhat complicated to change the workflow for only a part of
> Bugzilla (such as one product or component), so we would like to avoid
> having to do that. But if you have a strong case for it, make it.
>
> Note: this discussion is _not_ about resolutions (FIXED, DUPLICATE,
> WORKSFORME etc.). Those can also be changed, but independently. Let's
> have one discussion at a time.
>
> Gerv
>
> Appendix: How We'd Convert
> --------------------------
>
> We don't have to wait until Bugzilla 4.0 is released; we can convert
> beforehand if necessary. No new 4.0 features are needed to implement
> this.
>
> The exact algorithm, as implemented by the conversion script shipped
> with Bugzilla, would be:
>
> * "NEW" will become "CONFIRMED"
> * "ASSIGNED" will become "IN_PROGRESS"
> * "REOPENED" will become "CONFIRMED" (and the "REOPENED" status will be
> removed)
> * "CLOSED" will become "VERIFIED" (and the "CLOSED" status will be
> removed)
>
> The history of each bug will also be changed so that it appears that
> these statuses were always in existence. Emails will not be sent.
>
> If we adopt the READY_TO_FIX proposal, then initially no bugs would be
> in the READY_TO_FIX state.
Daniel Veditz
> What really needs improvement, though, is how to assign a bug to
> yourself in all the other screens (filing a new bug, editing an
> existing one).
Do you use bugzilla with JavaScript disabled? If JavaScript is
running every edit page has an "Assign to me" button on the Assigned
to line.
-Dan
Daniel Veditz
> We could certainly add some JS to prevent this combination, if we
> had a list of all email addresses representing "nobody". I suspect
> such a list isn't long, although I don't think it's of length 1 either.
It's not a small list. The short list of "nobodies" may give one hope...
nob...@bugzilla.org
nob...@mozilla.org
nob...@nss.bugs
...but there are 125 additional effective nobodies:
https://bugzilla.mozilla.org/report.cgi?y_axis_field=assigned_to&query_format=report-table&emailassigned_to1=1&emailtype1=regexp&email1=\.bugs%24&format=table&action=wrap
> I think there's a case for allowing assignee to be empty (NULL):
> https://bugzilla.mozilla.org/show_bug.cgi?id=369078
> but timeless makes some good points in comment 1 there.
I would love the unassigned nobodies to be coalesced, but it MUST be
a searchable value.
In order to not mess up watching we'd want to make sure some
products aren't using unique fake assignees rather than unique fake
QA Contacts. A few people might have to adjust their queries from
"quicksearch=@uni...@assignee.bugs" to "quicksearch=@unassigned
:mycomponent"
-Dan
Nicholas Nethercote
hasn't been covered already...
Some basic principles:
- STATUS is used inconsistently -- some people update it, some don't.
- From a bug reporter's point of view the STATUS isn't much use. Comments
will indicate if someone is actually working on the bug.
- In fact, an inappropriate STATUS can confuse/annoy bug reporters. Also,
STATUSes whose meaning is unclear lead to big email threads that consume
everyone's time. So fewer STATUS alternatives is preferable.
- On the other hand, STATUS *is* useful to devs/QA/managers for searching
for groups of bugs. We want to facilitate important kinds of searches.
Applying those principles:
- Minimum is obviously two STATUSes: OPEN and CLOSED.
- A common search would be from someone wanting to know which bugs have been
triaged and which haven't. So we need a third STATUS indicating that a
bug has been viewed and is considered valid: CONFIRMED. Might as well
take this chance to rename the three states CONFIRMED, UNCONFIRMED,
RESOLVED.
- As for knowing if somebody is assigned to work on a bug, we have the
"assigned to" field already, so adding a STATUS for that is silly. Well,
except for the awkward fact that there isn't a way to indicate that a bug
doesn't have anyone assigned to it, because there's always a silly default
assignee like "gen...@js.bugs". (I could be wrong about that.) If that
could default to empty, it would allow easy searches for unassigned bugs.
- Then there's VERIFIED. It seems to hardly ever be used and doesn't seem
necessary to me but maybe I'm missing an important use case. It's certainly
not part of the lifecycle of most bugs, so if it is needed maybe it
could be in
the whiteboard or a keyword.
And that's it. IN_PROGRESS and READY_TO_FIX appear to be unnecessary.
I'm probably wrong about some of the above, but I think the basic principle
"STATUS is good for searching and not much else" holds; if you want to add
a STATUS, ask whether anyone will do important searches based on it.
Nick
Daniel Veditz
> Headline: Bugzilla 4.0 has a new status workflow. I propose we adopt
> it, with one modification (the addition of a READY_TO_FIX state).
Consistency with the upstream is an important factor, but I'm not
keen on the name CONFIRMED if we add a READY state. CONFIRMED sounds
like a stable point at which a bug sits until someone starts fixing
it--which it is in a standard bugzilla w/out a READY state. If we're
going to have a READY state I'd prefer a name that makes people
uncomfortable and want to move the bug further along, such as
INCOMPLETE or UNREADY.
-Dan
Frédéric Buclin
> Do you use bugzilla with JavaScript disabled? If JavaScript is
> running every edit page has an "Assign to me" button on the Assigned
> to line.
No, there is no such button. Must me something you have implemented with
Greasemonkey. Or maybe you have the "Reassign to default" checkbox in mind.
LpSolit
Steffen Wilberg
The "Assing to me" button is one of the many features of the Bugzilla
Tweaks extension. Highly recommended:
https://addons.mozilla.org/de/firefox/addon/187588/
Steffen
Jens Hatlak
> On 30.10.2010 11:27, Frédéric Buclin wrote:
>> Le 30. 10. 10 04:33, Daniel Veditz a écrit :
>>> Do you use bugzilla with JavaScript disabled? If JavaScript is
>>> running every edit page has an "Assign to me" button on the Assigned
>>> to line.
>>
>> No, there is no such button. Must me something you have implemented with
>> Greasemonkey. Or maybe you have the "Reassign to default" checkbox in
>> mind.
>>
>> LpSolit
>
> The "Assing to me" button is one of the many features of the Bugzilla
> Tweaks extension.
Exactly, it's not me. But AFAIK it depends on Jetpack which would mean I
couldn't get it to work with my browser anyway (which is of course not
the add-on author's fault!).
Greetings,
Jens
--
Jens Hatlak <http://jens.hatlak.de/>
SeaMonkey Trunk Tracker <http://smtt.blogspot.com/>
Steffen Wilberg
> Steffen Wilberg wrote:
>> On 30.10.2010 11:27, Frédéric Buclin wrote:
>>> Le 30. 10. 10 04:33, Daniel Veditz a écrit :
>>>> Do you use bugzilla with JavaScript disabled? If JavaScript is
>>>> running every edit page has an "Assign to me" button on the Assigned
>>>> to line.
>>>
>>> No, there is no such button. Must me something you have implemented with
>>> Greasemonkey. Or maybe you have the "Reassign to default" checkbox in
>>> mind.
>>>
>>> LpSolit
>>
>> Tweaks extension.
>
> Exactly, it's not me. But AFAIK it depends on Jetpack which would mean I
> couldn't get it to work with my browser anyway (which is of course not
> the add-on author's fault!).
The add-on is self-contained, you don't have to install Jetpack
separately. And it's compatible with Firefox 3.6 and higher, so you
could try whether you can hack its install.rdf to run it in Seamonkey.
Steffen
timeless
You're running with a jetpack:
http://fredericiana.com/2009/11/25/assign-to-me-jetpack/
Please note that it is not possible to change a bug to 'ASSIGNED'
while attaching a patch if you are the current assignee.
Plus these days it's moderately hard to change the assignee, you have
to click 'edit' if you have javascript enabled.
John Thomsen
> I might as well add my two cents, I think some of what I'm about to say
> hasn't been covered already...
I also want to add my "25-øre".
Reading all the posts and summing everything together, I think Bugzilla
should have status sets for different types of users. Here the initial
results after some thinking about 3 essential types of users (default,
qa, and dev):
1. Default view (4 states)
UNCONFIRMED
NEEDINFO
CONFIRMED (incl. READY_TO_FIX)
RESOLVED (incl. VERIFIED)
2. QA view (all 6 states)
UNCONFIRMED
NEEDINFO (for communication between QA and reporter)
CONFIRMED
READY_TO_FIX (QA done)
RESOLVED
VERIFIED (QA done)
3. Dev view (3 states)
UNCONFIRMED (incl. NEEDINFO)
CONFIRMED (incl. READY_TO_FIX)
RESOLVED (incl. VERIFIED)
The IN_PROGRESS is not in the above proposal. If needed, it should IMO
be turned into an auto extracted (, auto inserted,) and optional status
*message* in addition to the status.
The above proposal suggests READY_TO_FIX and VERIFIED are private to QA.
The above proposal suggests QA sets NEEDINFO until proper STR are
established. If no activity happens in a NEEDINFO bug it could be auto
RESOLVED INCOMPLETE after a few weeks (and QA would cease interest in
that bug).
----
The above text stick to the nomenclature used in this thread. In
addition, if I had total power, I would rename two of the above states.
First. Since developers and other Bugzilla users with privileges have
the illogical power to mark their bugs self-CONFIRMED on creation, I
would rename the CONFIRMED state above to something else. E.g. TODO.
Second. I think READY_TO_FIX is a wrong angle to view the task at hand.
READY_TO_FIX is an exit status. It should be an entry status instead.
Daniel Veditz suggests UNREADY elsewhere in this thread.
The final result after these two changes is this updated overview:
1. Default view (4 states)
UNCONFIRMED
NEEDINFO
TODO (incl. UNREADY)
RESOLVED (incl. VERIFIED)
2. QA view (all 6 states)
UNCONFIRMED
NEEDINFO (for communication between QA and reporter)
UNREADY
TODO (QA done)
RESOLVED
VERIFIED (QA done)
3. Dev view (3 states)
UNCONFIRMED (incl. NEEDINFO)
TODO (incl. UNREADY)
RESOLVED (incl. VERIFIED)
----
The above changes may not make it into Bugzilla 4.0, but maybe they
should be considered for Bugzilla 5.0
For Bugzilla 4.0:
I agree with Mike Connors proposal of removing REOPENED and CLOSED for a
start.
I disagree renaming NEW to CONFIRMED because of e.g. the confusing
self-confirming power of some users.
I disagree introducing READY_TO_FIX because it is an exit status. An
entry status is better.
I agree with Mike Connors that changes to bugzilla.mozilla.org cannot
wait another 5 years.
----
With a delicious QA view like the one I suggest above, I would actually
be tempted to do some QA work within Bugzilla myself.
Regards,
John
Frédéric Buclin
> Reading all the posts and summing everything together, I think Bugzilla
> should have status sets for different types of users.
This is something that we are not going to implement, and which doesn't
make sense. Some users belong to several categories, and Bugzilla has no
information about your roles related to the products. Moreover, you
could be a developer for product A, but have no role concerning other
products (or have another role there). This would be totally unmanageable.
> First. Since developers and other Bugzilla users with privileges have
> the illogical power to mark their bugs self-CONFIRMED on creation
This is totally logical. It looks like you don't understand the
definition of "users with privileges". Those are users who know what
they are doing and have a better understanding of some products. If they
are unsure about what they are doing, then they know that they should
file their bugs as UNCONFIRMED, especially in products where they play
no role.
> The above changes may not make it into Bugzilla 4.0, but maybe they
> should be considered for Bugzilla 5.0
We won't.
LpSolit
John Thomsen
> Le 31. 10. 10 03:16, John Thomsen a écrit :
>> Reading all the posts and summing everything together, I think Bugzilla
>> should have status sets for different types of users.
>
> This is something that we are not going to implement, and which doesn't
> make sense. Some users belong to several categories, and Bugzilla has no
> information about your roles related to the products. Moreover, you
> could be a developer for product A, but have no role concerning other
> products (or have another role there). This would be totally unmanageable.
At first glance it may look totally unmanageable, but it isn't. The
feature is actually more about making it easier to search BMO. Roles are
not an issue, so they need no managing.
Here is how it could be implemented:
There are 6 states (in the proposal) which are all visible to the
Bugzilla user no matter what if any role you may have.
If you select a specific type of user, say the dev user, then the 3
statuses of little relevance when searching Bugzilla with dev hat on -
no matter if you are a real dev or not - become sub statuses and are
1. greyed out in the UI list of states.
2. appended automatically when doing a search.
Example:
You are looking for a bug and don't care if it is CONFIRMED or
READY_TO_FIX (or IN_PROGRESS). You just want to find the bug as quickly
as possible. You enter some search information and select CONFIRMED. You
do not need to select (the greyed out) READY_TO_FIX (or IN_PROGRESS)
because it/these is/are auto selected/included. Then you press the
Search button.
This would make searching Bugzilla so much easier, IMO.
----
In retrospect, I probably should have used the term "search mode" and
not "user type", so my proposal is to make it easier to search Bugzilla
by introducing the mentioned 3 search modes.
That is not hard to do. Can be done on top of the current Bugzilla with
a new fashioned Jetpack PageMod or an old fashioned GM-script.
>> First. Since developers and other Bugzilla users with privileges have
>> the illogical power to mark their bugs self-CONFIRMED on creation
>
> This is totally logical. It looks like you don't understand the
> definition of "users with privileges".
I probably don't.
After about 7-8 years, I am still an unprivileged user of BMO. From an
unpleasant state it has become a lifestyle over the years. A variant of
the Stockholm syndrome.
> Those are users who know what
> they are doing and have a better understanding of some products. If they
> are unsure about what they are doing, then they know that they should
> file their bugs as UNCONFIRMED, especially in products where they play
> no role.
Nice. We agree on something.
I may be dumb with respect to Bugzilla, and I may stay dumb forever, but
I am no more dumb, that I see examples of "users with privileges", who
currently files bugs as NEW, while they should have been filed as
UNCONFIRMED.
Since one "user with privileges" won't (in practise) - for human reasons
- change a bug status of another "user with privileges" from NEW to
UNCONFIRMED. These bugs will stay NEW.
In the world to come, these bug will be changed from NEW to CONFIRMED
and stay CONFIRMED. No matter the fact that some of them are garbage.
That hurts my intelligence and it annoy me that unprivileged users, like
myself, will search Bugzilla and end up finding and reading CONFIRMED
garbage. Not to mention reading a lot - probably the majority - of great
bugs, witch are illogically self-CONFIRMED.
Another issue is of course that logically the sum of CONFIRMED and
UNCONFIRMED bugs should be equal to the set of all bugs. I remember that
missing logic as yet another obstacle when I first met Bugzilla.
>> The above changes may not make it into Bugzilla 4.0, but maybe they
>> should be considered for Bugzilla 5.0
>
> We won't.
Thank you for that clear answer and for the upcoming removal of REOPENED
and CLOSED.
/John
Robert Kaiser
> Plus these days it's moderately hard to change the assignee, you have
> to click 'edit' if you have javascript enabled.
And then you need to enter something and wait for the autocomplete to
appear, while in earlier times, you did get the browser-internal list of
already-used entries for that field on just a double-click, so it was
much faster if you already had assigned at least one bug to yourself.
Robert Kaiser
> At first glance it may look totally unmanageable, but it isn't. The
> feature is actually more about making it easier to search BMO.
Then this should be implemented as some search UI, and not as an actual
bug status change, I think.
Robert Kasier
E. Wong
>> I have a few bugs
>> which are assigned to me; but they've stalled so having their status
>> changed to IN_PROGRESS is a misnomer (to me a sort of a lie) since
>> the bugs are stalled and aren't in progress.
>
> So shouldn't their status reflect that, so that someone else who has the
> time to work on them right now can pick them up and know he's not
> getting in your way?
>
I understand this. I think I don't have the correct mentality as yet
with respect to the whole work flow. I look at a bug, and before
I even consider assigning to myself, I try to think it out; that is,
make sure I understand it and that it is 'easy' to do. Only when
I'm 100% sure do I assign myself to it. Of course, there are a few
exceptions (particularly those bugs that have been assigned to me by
someone else who thinks I can handle it).
Is it wrong to feel that once I take a bug, I'm responsible for fixing
it? Once I stall, I still need to find ways of solving it (or if the
stalled is due to a dependent bug, wait for the dependency to be fixed)?
>> I guess it's a psychological thing such that IN_PROGRESS challenges
>> the dev to actually work on the bug whereas ASSIGNED allows the dev
>> to assign him/her self to the bug but take one's time in figuring
>> it out.
>
> Again, this assumes that no one other than "the dev" is interested in
> fixing the bug, right?
No, I don't believe I assumed that. Any other dev has the opportunity
to take the bug from me, regardless of the status, no? I just feel
like a failure were that to happen though.
>> but, is it necessary to have READY_TO_FIX in order for a dev
>> to say "Ok, I'll start on it." or "I have a patch."?
>
> No, but focusing on READY_TO_FIX bugs helps to prioritize time where it
> will help the most....
>
True. It would help a bit more were that flag set (properly ;)).
Edmund
Boris Zbarsky
> Is it wrong to feel that once I take a bug, I'm responsible for fixing
> it?
No, but in practice priorities and circumstances change. A volunteer
might assign a bug to himself, then discover he doesn't actually have
time to work on it anymore. A manager may assign a bug to an employee,
then tell him something else is more important right this minute.
Maybe such bugs should just get assigned to nobody. But if X assigns a
bug to Y and then Z comes along and thinks he can fix it, it's worth it
if Z can tell whether Y has actually started working on it. Of course
they could check over e-mail...
> No, I don't believe I assumed that. Any other dev has the opportunity
> to take the bug from me, regardless of the status, no?
Yes, but if you're actively working on it that seems pointless. ;)
>> No, but focusing on READY_TO_FIX bugs helps to prioritize time where it
>> will help the most....
>
> True. It would help a bit more were that flag set (properly ;)).
Well, yes. :)
-Boris
Gervase Markham
> And then you need to enter something and wait for the autocomplete to
> appear, while in earlier times, you did get the browser-internal list of
> already-used entries for that field on just a double-click, so it was
> much faster if you already had assigned at least one bug to yourself.
I think that the idea that Bugzilla's username autocomplete JS code
should know your username without having to make a network request, and
so autocomplete your own name very fast indeed, is an awesome one and
you should file a bug on it :-)
Gerv
Gervase Markham
> That's not quite true. The attachment screen can do it only if you are
> *not* already assigned to the bug. I.e. so you can assign yourself and
> the state at the same time as adding the attachment.
Having tested, it turns out that's a UI issue, not a back-end issue. It
would be pretty easy to make the status-changing UI always available on
the attachment screen. (And then to set it automatically with
JavaScript.) Or, for that matter, to have hidden JS merely add the
relevant hidden form field for submission.
Gerv
Gervase Markham
> In the near term, we would have to expend serious labor to get the old
> morass of untriaged bugs into that possible state.
Not necessarily. No-one is asking QA to do more work than they are doing
now. We are just saying that, going forward, they need to denote the
results of that work in a different way.
Over time, READY_TO_FIX will come closer and closer to denoting the full
set of bugs which are ready to fix.
> In the long term, given the rate of bug filing to bug fixing, it seems
> likely that, again, a large pile of bugs will fall through to the
> READY_TO_FIX state and will languish there for years, to the point where
> developers are no longer sure about their validity anymore.
Because the code has changed around them, or the bug is no longer
reproducible? I guess that is a concern, but any bug marked READY_TO_FIX
should be in a position for a developer to jump in and reproduce it (or
not), whatever its age.
> It also
> seems likely that the semantics of these states will alter slightly too,
> so that not all the bugs in this state match what the state is supposed
> to claim.
Why is that problem specific to the changes we are suggesting we make?
Gerv
Gervase Markham
> - Ready to fix seems to imply that a test case is required.
If a test case is required for the bug to be ready to fix, then it's
required. If it's not, it's not :-) Surely this depends on the bug, the
product, and the requirements of developers working on that product?
> So if we now require a testcase, then according to gerv's text, either
> QA or the submitter would have to provide part of a test case, or
> something before the bug would get looked at before a developer. There
> are so many cases where this isn't possible.
What text is this? Are you talking about mconnor's flowcharts?
> For example, I have an issue in Thunderbird where my testcase is to run
> Thunderbird possibly with some add-ons. I have no idea on how to reduce
> that which is actually wanted for getting the bug solved.
If there is nothing more that QA can do to make things any easier, then
the bug is as ready to fix as it will ever be, and READY_TO_FIX would be
appropriate.
> - I have an issue with the wording. I can see users seeing bugs marked
> as "Ready to fix" and asking why hasn't it been fixed yet, and causing
> more bugspam.
Do we get much bugspam about the fact that bugs are NEW when they are
very old? I've certainly not seen much.
If you can think of a better name which doesn't have that issue, I'd be
glad to hear it.
> Having better opt-outs of bugspam would help here. e.g. don't send me
> notification when a bug changes to/from ready and nothing else happens
> on that bug. (although generally better opt-outs would help anyway).
Surely that's exactly the notification you want, as a developer? If a
bug has moved into READY_TO_FIX, it probably means that a QA person has
decided it's time for you to look at it.
Gerv
Gervase Markham
> To me, the ASSIGNED status makes more sense than IN_PROGRESS which
> may not even reflect the truth of the progress. I have a few bugs
> which are assigned to me; but they've stalled so having their status
> changed to IN_PROGRESS is a misnomer (to me a sort of a lie) since
> the bugs are stalled and aren't in progress.
Then you should change the state.
> I guess it's a psychological thing such that IN_PROGRESS challenges
> the dev to actually work on the bug whereas ASSIGNED allows the dev
> to assign him/her self to the bug but take one's time in figuring
> it out. (Of course, this would apply to the less-urgent bugs and
> not those that require a fix immediately.)
Right. And the latter is a problem, because if a bug is ASSIGNED to a
developer, it makes it less likely that another community member will
come along and fix it. So encouraging people not to have bugs as
ASSIGNED/IN_PROGRESS when they aren't actually working on them is a good
thing. And if changing the name makes that more likely, that's good.
> 1) I look at a bug. If it is something that I could do without a doubt,
> I ASSIGN myself to it. If it is something which sounds difficult,
> I keep it to NEW and figure it out. Only when I am 100% sure that
> I can handle it do I ASSIGN myself.
>
> 2) If the progress to the bug has stalled, I can at least keep the
> ASSIGNED status so I can keep track of which bugs I have.
I think you are being overly-possessive about bugs. :-)
Gerv
> I'm finding it a little difficult to understand the difference
> between CONFIRMED and READY_TO_FIX in the sense that if the
> bug is CONFIRMED, then it should be ready for any developer to
> dive in and fix it. Are there cases in which a bug could be
> CONFIRMED but not READY_TO_FIX?
Absolutely - loads. Here's an example: CONFIRMED means "I've crashed
doing the same thing the reporter did". READY_TO_FIX means "I've worked
out which bit of the web page is causing the crash and have uploaded a
reduced test case. Over to you, developer."
The difference between CONFIRMED and READY_TO_FIX is the work of QA :-)
Gerv
Gervase Markham
> I don't think we're going to get to a broad consensus here. We've been
> talking about this for five years, and every thread devolves into
> speculation and forks in many ways. Either we do nothing, or we try
> something to see if it works.
If it's any comfort, I have no intention of attempting to achieve
universal consensus before action.
> I would propose that we take the following
> actions, and revisit later:
>
> * I don't think there is any opposition to removing REOPENED or CLOSED.
> These make sense, and should be done immediately.
We can remove them from the standard workflow at any time through the
Bugzilla UI (this has already been done for CLOSED, quite a while ago);
eliminating them from the database either requires a script to be run,
or would result in the mother of all bugspam deluges.
> * NEW -> CONFIRMED seems to be generally accepted, so let's rename it
> (pick a time, preferably before a weekend, so queries don't break)
Except that Dan thinks it should be ("INCOMPLETE" or) "UNREADY", if we
have READY_TO_FIX. Or, for that matter, we could call it NEED_INFO!
As I said, there is value in being consistent with upstream; but if we
are, logically speaking, splitting CONFIRMED into two by the addition of
READY_TO_FIX, it may be that neither half retains the old name.
> * ASSIGNED -> IN_PROGRESS seems entirely rational, and ASSIGNED vs.
> assigned-to is a point of confusion. IN_PROGRESS remains optional, but
> we should explore auto-changing to that when patches are added to bugs.
> This can be done at the same time as the NEW->CONFIRMED rename.
> * READY_TO_FIX is something we can add without code changes, and it
> seems clear that certain parts of the project can and will make good use
> of this status, so I think we should try it and see if it actually works.
I think the only question is whether we do it as READY_TO_FIX, or we do
it as NEED_INFO (i.e. the other way around, a negative rather than a
positive statement about the bug). As someone who has thought about this
a lot, did you consider this question and, if so, what made you pick
READY_TO_FIX over NEED_INFO?
I think that the other states, with the possible exception of
UNCONFIRMED, denote what has just happened to the bug - it's just been
CONFIRMED, it's just been RESOLVED, it's just been VERIFIED. Therefore,
"it's just been made READY_TO_FIX" fits in better than "the next thing
required is some info".
In practice, I think over time, as bugs age, they are more likely to
need info anyway, so having a new READY_TO_FIX state, and perhaps having
bugs automatically fall out of it after a year of inactivity, makes more
sense than a NEED_INFO status.
Gerv
Gervase Markham
> Consistency with the upstream is an important factor, but I'm not
> keen on the name CONFIRMED if we add a READY state. CONFIRMED sounds
> like a stable point at which a bug sits until someone starts fixing
> it--which it is in a standard bugzilla w/out a READY state.
It sounds to me that there has been an acknowledgement that the bug is
actually a bug - i.e. it's not INVALID, and the stated behaviour is both
present and unwanted. I don't think "CONFIRMED" necessarily implies it's
ready to be fixed.
> If we're
> going to have a READY state I'd prefer a name that makes people
> uncomfortable and want to move the bug further along, such as
> INCOMPLETE or UNREADY.
INCOMPLETE is already a resolution; it would be rather confusing for it
to be a status too.
I sort of see your point, but the other statuses are positive statements
about what has most recently happened to the big - it has just been
RESOLVED, it has just been VERIFIED, it has just been CONFIRMED (or
filed by someone who confirmed it before they filed it). UNREADY doesn't
quite fit that scheme.
Gerv
Gervase Markham
> On 2010-10-30 05:08, Nicholas Nethercote wrote:
>> I might as well add my two cents, I think some of what I'm about to say
>> hasn't been covered already...
>
> I also want to add my "25-øre".
>
> Reading all the posts and summing everything together, I think Bugzilla
> should have status sets for different types of users.
LpSolit has well explained why this isn't a great plan.
> The above changes may not make it into Bugzilla 4.0, but maybe they
> should be considered for Bugzilla 5.0
Note that we are considering changes to bugzilla.mozilla.org, not to
core Bugzilla.
> I disagree introducing READY_TO_FIX because it is an exit status. An
> entry status is better.
I don't think the right distinction is entry vs. exit, I think it's
"what has happened" vs. "what needs to happen next". See other messages
in this thread.
Gerv
Mike Connor
>> * NEW -> CONFIRMED seems to be generally accepted, so let's rename it
>> (pick a time, preferably before a weekend, so queries don't break)
>
> Except that Dan thinks it should be ("INCOMPLETE" or) "UNREADY", if we
> have READY_TO_FIX. Or, for that matter, we could call it NEED_INFO!
>
> As I said, there is value in being consistent with upstream; but if we
> are, logically speaking, splitting CONFIRMED into two by the addition
> of READY_TO_FIX, it may be that neither half retains the old name.
I think the negative status is wrong here. I like the "this is how far
the bug has progressed" concept for statuses, and I think for the most
part the original is fine here. My original goal was to make the first
filter pass very simple: Can the triager reproduce this bug, and is it a
reasonable assumption that it's not a dupe?
Note: NEEDINFO is possibly misleading, we may not need info, we may need
a testcase, or a mockup, or whatever. This is why I didn't want a
NEEDINFO status.
>> * ASSIGNED -> IN_PROGRESS seems entirely rational, and ASSIGNED vs.
>> assigned-to is a point of confusion. IN_PROGRESS remains optional, but
>> we should explore auto-changing to that when patches are added to bugs.
>> This can be done at the same time as the NEW->CONFIRMED rename.
>> * READY_TO_FIX is something we can add without code changes, and it
>> seems clear that certain parts of the project can and will make good use
>> of this status, so I think we should try it and see if it actually
>> works.
>
> I think the only question is whether we do it as READY_TO_FIX, or we
> do it as NEED_INFO (i.e. the other way around, a negative rather than
> a positive statement about the bug). As someone who has thought about
> this a lot, did you consider this question and, if so, what made you
> pick READY_TO_FIX over NEED_INFO?
See below, but ultimately it was consistency. Either status should be
all "next steps" or all "how far we are" in order to have an
understandable progression. I also like the positive state over the
negative state.
> I think that the other states, with the possible exception of
> UNCONFIRMED, denote what has just happened to the bug - it's just been
> CONFIRMED, it's just been RESOLVED, it's just been VERIFIED.
> Therefore, "it's just been made READY_TO_FIX" fits in better than "the
> next thing required is some info".
Yep, I agree with this. Status == what the current state of the bug
is. Without adding a lot of statuses, we probably can't do "next steps"
as some would prefer.
UNCONFIRMED = not confirmed.
CONFIRMED = can repro, not an obvious dupe
READY_TO_FIX = has appropriate QA/UX work complete, ready for a developer
IN_PROGRESS = developer is working on a patch
RESOLVED = report is resolved
-- Mike
Robert Kaiser
I have no idea if filing a bug to have it make the users I used
previously available in a double-click selection menu really makes sense
- but if it does, that would be awesome and would fill in the gap of
feature loss I saw with adding this piece of automation here ;-)
Robert Kaiser
> Over time, READY_TO_FIX will come closer and closer to denoting the full
> set of bugs which are ready to fix.
I still fear that the wording of this status actually makes it
dangerous, as it sounds like everything has already been done to fix
this bug, i.e. everything is "ready to fix it in the code" while in
reality it means that all info is there to possibly start working on a
potential fix.
If we have hordes of comments about "why isn't this fixed, it has been
READY_TO_FIX for ages", this is even worse than then implication of NEW
right now.
Any ideas on how we could improve the wording to make this less likely?
Daniel Veditz
Ah yes, the "Bugzilla Tweaks" jetpack is doing it. I installed that
one to get the interleaved history, I hadn't consciously noticed the
other changes and thought some of them (including this button) came
with the most recent BMO upgrade.
-Dan
Daniel Veditz
> 2) If the progress to the bug has stalled, I can at least keep the
> ASSIGNED status so I can keep track of which bugs I have.
Regardless of status, the bug will at this point be assigned to you
and can be kept track of that way.
If you're worried someone will steal the bug away you could turn on
the "Enable tags for bugs" bugzilla preference and then tag all
"your" bugs. Nothing anyone else does to that bug will remove it
from your tagged list.
-Dan
Max
> Yep, I agree with this. Status == what the current state of the bug
> is. Without adding a lot of statuses, we probably can't do "next steps"
> as some would prefer.
>
> UNCONFIRMED = not confirmed.
> CONFIRMED = can repro, not an obvious dupe
> READY_TO_FIX = has appropriate QA/UX work complete, ready for a developer
> IN_PROGRESS = developer is working on a patch
> RESOLVED = report is resolved
I think that this sounds like an entirely sensible plan, and is in
line with the long discussion we had in this newsgroup many months ago
on this topic.
-Max
Daniel Veditz
>> * NEW -> CONFIRMED seems to be generally accepted, so let's rename it
>> (pick a time, preferably before a weekend, so queries don't break)
>
> Except that Dan thinks it should be ("INCOMPLETE" or) "UNREADY", if
> we have READY_TO_FIX.
I seem to be a lone voice--absolutely no one voiced any affection
for the proposal. Don't let me hold up this otherwise helpful change.
> Or, for that matter, we could call it NEED_INFO!
NEEDINFO means something quite different: the reporter (in most
cases) needs to provide additional information and the bug is almost
certainly not yet CONFIRMED. NEEDINFO is a stop on the road to
RESOLVED INCOMPLETE.
I have been a NEEDINFO supporter in the past as a way to indicate
the responsibility lies with the reporter rather than the assignee.
These days, however, we're using "nobody" as the default assignee
and it's clear to everyone no developer is on the hook. If there's
no response from the reporter after a reasonable period we can see
if RESOLVED INCOMPLETE prods a response. If not the bug is disposed
of properly.
[off-topic: what's with all the underscores? WORKSFORME hasn't
caused any problems all these years and the new words with
underscores seem stylistically out of place.]
> I think the only question is whether we do it as READY_TO_FIX, or we
> do it as NEED_INFO (i.e. the other way around, a negative rather
> than a positive statement about the bug). As someone who has thought
> about this a lot, did you consider this question and, if so, what
> made you pick READY_TO_FIX over NEED_INFO?
If you're going to have a NEEDINFO you still need READYTOFIX.
NEEDINFO represents QA getting stuck, most likely between UNCO and
CONFIRMED, but occasionally between CONFIRMED and READYTOFIX. The
typical reporter won't have the permissions to flip NEEDINFO back to
UNCONFIRMED nor know that they need to do so to reactivate the bug,
leading to bug stall.
I suppose it could potentially represent a developer disagreeing
that the bug is READYTOFIX, but we don't need a special case for
that any more than we needed REOPENED. Flipping the bug back to
CONFIRMED is good enough for that case.
NEEDINFO may well make sense for an internal bugzilla at some
company where bug reporters are trained in their role and you need a
state to put the reporter (rather than the assignee or QA contact)
on the hook; NEEDINFO does not make sense for our public-facing BMO.
> I think that the other states, with the possible exception of
> UNCONFIRMED, denote what has just happened to the bug - it's just
> been CONFIRMED, it's just been RESOLVED, it's just been VERIFIED.
> Therefore, "it's just been made READY_TO_FIX" fits in better than
> "the next thing required is some info".
NEEDINFO represents a bug in a stalled state. These days I'd rather
just go with RESOLVED INCOMPLETE and move on to a more useful bug.
Please drop my proposal of renaming CONFIRMED to a negative state
like INCOMPLETE or UNREADY.
-Dan
Daniel Veditz
> I may be dumb with respect to Bugzilla, and I may stay dumb forever,
> but I am no more dumb, that I see examples of "users with
> privileges", who currently files bugs as NEW, while they should have
> been filed as UNCONFIRMED.
>
> Since one "user with privileges" won't (in practise) - for human
> reasons - change a bug status of another "user with privileges" from
> NEW to UNCONFIRMED. These bugs will stay NEW.
Shhh. You have stumbled on the secret of the READY state. Its real
purpose is to demote NEW/CONFIRMED bugs without hurting the feeling
of all the privileged folks by taking the privilege away.
Daniel Veditz
> - Then there's VERIFIED. It seems to hardly ever be used and doesn't seem
> necessary to me but maybe I'm missing an important use case. It's certainly
> not part of the lifecycle of most bugs, so if it is needed maybe it
> could be in
> the whiteboard or a keyword.
It _should_ be part of the bug lifecycle. The fact that we don't
verify fixes is terrible and has led to us shipping broken releases.
Daniel Veditz
Christian Legnitto
But verified means what exactly? On trunk? On branch? On which platforms? Debug or opt?
I think VERIFIED would be better handled by keywords and whiteboard entires. There is other metadata that is needed to determine where the bug actually sits when it is in VERIFIED, and such is a useless bug state IMHO.
Christian
E. Wong
> On 29/10/10 16:22, E Wong wrote:
>> To me, the ASSIGNED status makes more sense than IN_PROGRESS which
>> may not even reflect the truth of the progress. I have a few bugs
>> which are assigned to me; but they've stalled so having their status
>> changed to IN_PROGRESS is a misnomer (to me a sort of a lie) since
>> the bugs are stalled and aren't in progress.
>
> Then you should change the state.
But I don't change the assignee, right?
>> 1) I look at a bug. If it is something that I could do without a doubt,
>> I ASSIGN myself to it. If it is something which sounds difficult,
>> I keep it to NEW and figure it out. Only when I am 100% sure that
>> I can handle it do I ASSIGN myself.
>>
>> 2) If the progress to the bug has stalled, I can at least keep the
>> ASSIGNED status so I can keep track of which bugs I have.
>
> I think you are being overly-possessive about bugs. :-)
>
Actually, I think you've pretty much hit the nail. I couldn't find the
right words, but "overly-possessive about bugs" certainly describes
me in a way such that "I am determined to fix this bug if it's
the last thing I do, come what may and I would be very disappointed
at myself should someone take it."
This is where I think, as a new developer, I need lots of advice from
veteran devs. I do appreciate them.
> Absolutely - loads. Here's an example: CONFIRMED means "I've crashed
> doing the same thing the reporter did". READY_TO_FIX means "I've worked
> out which bit of the web page is causing the crash and have uploaded a
> reduced test case. Over to you, developer."
>
> The difference between CONFIRMED and READY_TO_FIX is the work of QA :-)
Oh. Ok. Thanks for clarification.
Edmund
Uli Link
> Gervase Markham schrieb:
>> Over time, READY_TO_FIX will come closer and closer to denoting the full
>> set of bugs which are ready to fix.
>
> I still fear that the wording of this status actually makes it
> dangerous, as it sounds like everything has already been done to fix
> this bug, i.e. everything is "ready to fix it in the code" while in
> reality it means that all info is there to possibly start working on a
> potential fix.
READY_TO_GO || READY_TO_START ???
--
Uli Link
Uli Link
I guess the verified status has to/should be implemented by whiteboard
keywords because for branch overlapping bugs, the status usually will be
tracked separately for all affected branches.
To make it even more complicated, what was trunk 6 months ago maybe a
stable branch with different rules in the meantime. And 6 months isn't
an unusual timeframe... Just an example.
Nonetheless: tracking the verified state after each checkin + sufficiant
green tinderboxen should be mandatory.
--
Uli Link
Gervase Markham
> I think that the idea that Bugzilla's username autocomplete JS code
> should know your username without having to make a network request, and
> so autocomplete your own name very fast indeed, is an awesome one and
> you should file a bug on it :-)
"Username autocomplete should know who I am"
https://bugzilla.mozilla.org/show_bug.cgi?id=608936
And, for good measure:
"Username autocomplete should use localStorage"
https://bugzilla.mozilla.org/show_bug.cgi?id=608937
Gerv
Gervase Markham
>> I still fear that the wording of this status actually makes it
>> dangerous, as it sounds like everything has already been done to fix
>> this bug, i.e. everything is "ready to fix it in the code" while in
>> reality it means that all info is there to possibly start working on a
>> potential fix.
>
> READY_TO_GO || READY_TO_START ???
I'm not sure there's a way of avoiding Kairo's potential problem while
still conveying the right message. Also, READY_TO_START is a bit rude to
QA, who may have been working on the bug for hours already :-)
Gerv
Gervase Markham
>> Then you should change the state.
>
> But I don't change the assignee, right?
If you aren't working on it, you should reset the assignee to the
default (which is usually a "nobody" address).
Gerv
Gervase Markham
> But verified means what exactly? On trunk? On branch? On which platforms? Debug or opt?
Multiple statuses for a bug depending on branches is, as you certainly
know, a larger problem :-) In the mean time, the convention is that it
means verified on trunk.
Gerv
Gervase Markham
> [off-topic: what's with all the underscores? WORKSFORME hasn't
> caused any problems all these years and the new words with
> underscores seem stylistically out of place.]
ASSIGNED_TO has an underscore, as does the new IN_PROGRESS.
For some reason, historically, statuses have had underscores but
resolutions have not. <shrug>
Gerv
fantasai
Then READY doesn't fit that scheme either. Maybe PREPARED?
~fantasai
Boris Zbarsky
> If you aren't working on it, you should reset the assignee to the
> default (which is usually a "nobody" address).
I think that assigning a bug to self if you're planning to work on it
but not working on it yet is reasonable. Especially since we have no
other sane way to keep track of such bugs...
The corollary is that we need a way to flag bugs as "planning to, but
not working on this right this moment".
-Boris
Robert Kaiser
> On 01/11/10 23:49, Daniel Veditz wrote:
>> [off-topic: what's with all the underscores? WORKSFORME hasn't
>> caused any problems all these years and the new words with
>> underscores seem stylistically out of place.]
>
> ASSIGNED_TO has an underscore, as does the new IN_PROGRESS.
There is no ASSIGNED_TO, it's just ASSIGNED, IIRC.
> For some reason, historically, statuses have had underscores but
> resolutions have not. <shrug>
Really? I think I've never seem one with an underscore historically.
Daniel Veditz
> On 11/2/10 6:09 AM, Gervase Markham wrote:
>> If you aren't working on it, you should reset the assignee to the
>> default (which is usually a "nobody" address).
>
> I think that assigning a bug to self if you're planning to work on
> it but not working on it yet is reasonable. Especially since we
> have no other sane way to keep track of such bugs...
If you're tracking it for your own interest we have the bugzilla
tagging feature. If you're trying to announce your interest in the
bug to the wider team then you're right, nothing does that better
than the assignee field.
Boris Zbarsky
> If you're tracking it for your own interest we have the bugzilla
> tagging feature.
That's a "will have", right?
> If you're trying to announce your interest in the
> bug to the wider team then you're right, nothing does that better
> than the assignee field.
I mostly want to keep track of a priority-sorted and easily searchable
list of bugs I plan to work on. If I can use the upcoming tagging to do
that without messing with assignee until I'm working on it, great.
-Boris
Daniel Veditz
> But verified means what exactly? On trunk? On branch? On which
> platforms? Debug or opt?
And RESOLVED means what exactly? On trunk? On branch? On which
platforms?
Our convention is that the bug status represents the trunk status
(except for certain branch-only bugs) and there's no need for
verified to be any different. Whether verification requires testing
on all platforms or with particular build options is up to the
judgment of the verifier. Can it be done poorly? Sure, just as some
patches turn out to be ill-conceived.
As a state RESOLVED means the developer is done with the bug, but
the bug is not done until we get an independent check that the
problem the developer fixed is the problem that was reported.
There are lots of cases where VERIFIED doesn't make a lot of sense.
Self-reported bugs that represent work items, for example. It would
be nice if the assignee could be trusted to self-verify for such
bugs but apparently that's a separate magic permission in bugzilla.
If we expect to use VERIFIED it should probably be bundled with
editbugs permission so every trusted member can do it.
-Dan
Daniel Veditz
> platforms? Debug or opt?
And RESOLVED means what exactly? On trunk? On branch? On which
platforms?
Our convention is that the bug status represents the trunk status
Daniel Veditz
> I guess the verified status has to/should be implemented by
> whiteboard keywords because for branch overlapping bugs, the status
> usually will be tracked separately for all affected branches.
Sure, until we get "sightings" branches are a PITA and we have to do
something else, just as we have to for the resolved status itself.
On the branches we're using pre-branch verified keywords (on earlier
branches we used per-release keywords).
-Dan
Frédéric Buclin
> list of bugs I plan to work on. If I can use the upcoming tagging to do
> that without messing with assignee until I'm working on it, great.
The feature dveditz is talking about exists since Bugzilla 2.22, and is
available for 4 years now. :)
Boris Zbarsky
Uh... how do I use it? Is it not enabled on BMO? I see no mention of
"tags" other than the status whiteboard in the Help link off a BMO bug,
and no obvious tagging UI in the show_bug page.
-Boris
timeless
> Uh... how do I use it? Is it not enabled on BMO? I see no mention of
> "tags" other than the status whiteboard in the Help link off a BMO bug, and
> no obvious tagging UI in the show_bug page.
https://bugzilla.mozilla.org/userprefs.cgi
Enable tags for bugs : Site Default (Off)
Justin Wood (Callek)
READY_FOR_DEV || READY_TO_PATCH ?
--
~Justin Wood (Callek)