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.
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.
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.
> 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 ;-)
> 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.
> 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.
> 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.
>> 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.
On 10/28/10 7:18 AM, Gervase Markham wrote [in part]:
> Headline: Bugzilla 4.0 has a new status workflow. I propose we adopt it, > with one modification (the addition of a READY_TO_FIX state).
> There have been discussions in the past about changing the workflow (set > of statuses and transitions between them) of bugzilla.mozilla.org to > better reflect our current development practices.
> Soon, Bugzilla 4.0 will be released, and some time after that, > bugzilla.mozilla.org will be upgraded to it. One reason this is > significant is that Bugzilla 4.0 comes with a new default set of > statuses, designed based on the last 12 years of experience in Bugzillas > around the world.
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.
> 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.
> 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.
> On 10/28/2010 8:12 AM, Mike Connor wrote: > At the very least, employees of Mozilla should be doing this. It's > our primary job to communicate clearly to the community what's going on > with the project (via bugs, meeting notes, blog posts, etc), and being > too lazy to change the status of a bug when you start working on it just > isn't a good enough reason to not do this, IMO.
I often find myself setting ASSIGNED status on others' bugs. For most people the new workflow will continue to be the same they use today: UNCONFIRMED -> CONFIRMED -> assignedTo -> FIXED -> VERIFIED. Both the suggested new statused are nice changes but will be hard to enforce them, noticing how common is the above workflow.
Do we expect assignees to remove IN_PROGRESS if they work on other higher priority stuff and expect to not go back to that bug soonish? Or is it just indication that the assignee started doing something for the bug?
Regarding READY_TO_FIX, there should also be a defined way to differentiate what is needed when a bug is not yet ready (testcase, design, prototype, triaging, ...). It looks like an inverse replacement for "qawanted". We have about 3500 bugs marked with it and they don't seem to get more traction from the community, mostly because it's a large set including also pretty old bugs, and a lot of newer bugs, not marked with it, are requiring the same attention. From this point of view could make sense an inverse approach, where any bug needs attention till it has enough info.
If READY is added, imo IN_PROGRESS is needed; a READY bug with an assignee doesn't give me the idea of being worked on. Looks like something that is ready for the assignee to _start_ working on.
>> 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.
I kind of like the new statuses. I certainly like IN_PROGRESS better. I never really liked the ASSIGNED status much.
I think it would be helpful to understand why people really don't use the statuses consistently today. The exception here is maybe RESOLVED since everybody will reliably mark that because it has a direct benefit. To look at a bit of data; of the 19 Beta7 blockers, only 5 of them have status=ASSIGNED. The rest are in the NEW state. Does this reflect the state of things? I suspect not. The bug assigned to "nobody" isn't really assigned to "nobody". You are required to go through each bug individually to figure out what is really going on. I agree that assuming people will adopt the new statuses simply because they make more sense isn't a reliable motivator.
I like the idea of coupling the statuses with the assigned field somehow to prevent cases of assigned=nobody and status=IN_PROGRESS and possibly some other combinations - understanding there are edge cases here. I think that would be helpful.
In my experience, using status to figure out what is going on is somewhat limited. There are bugs that can sit in one state for a long time, let's say CONFIRMED. There might be all kinds of parallel activities going on - dev investigation, qa investigation. They are being worked on in some form. What you really don't see is why they are getting bogged down or what next step we are blocked on. I know this is kind of off topic from the initial discussion.
On Thu, Oct 28, 2010 at 8:55 AM, Shawn Wilsher <sdwi...@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.
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.
On Thu, Oct 28, 2010 at 10:52:29AM -0700, Sheila Mooney wrote: > I kind of like the new statuses. I certainly like IN_PROGRESS better. > I never really liked the ASSIGNED status much.
> I think it would be helpful to understand why people really don't use > the statuses consistently today. The exception here is maybe RESOLVED > since everybody will reliably mark that because it has a direct > benefit. To look at a bit of data; of the 19 Beta7 blockers, only 5 of > them have status=ASSIGNED. The rest are in the NEW state. Does this > reflect the state of things? I suspect not. The bug assigned to > "nobody" isn't really assigned to "nobody". You are required to go > through each bug individually to figure out what is really going on. I > agree that assuming people will adopt the new statuses simply because > they make more sense isn't a reliable motivator.
Maybe if the UI was more helpful to follow the workflow, it would work better. Changing the status can only be done at the bottom of the page, and assigning bugs to oneself is not as simple as "Add me to CC list".
Some components also have default values for Assigned To that is not nobody.
On Thu, Oct 28, 2010 at 11:23:53AM -0700, Reed Loden wrote: > 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)
>> I try to argue for a minimum of process/overhead with how we do >> things, but >> I think reflecting actual phases of a bug would be beneficial here. >> UNCO/CONF/READY/IN_PROGRESS are all distinct, and require different >> actions >> from different people, so it makes sense that we would call these out >> at the >> top level.
>> It's worth a shot, at least!
> Sure, reflecting the actual phases of the bug would be valuable, if > people *did* it. Given the current design of bugzilla, there is no > incentive to actually change the status from CONF->READY->IN_PROGRESS, > and I just don't think people are going to do it.
I agree, partially. Your point brings up the question, why is there no incentive to make that change? Speaking just for myself, I'm not sure who is using the "intermediate" status values, so it's not clear anyone cares. Also, they tend not to be set now, so I never rely on them, and I assume others don't either. I find that in order to track the status of a bug, I have to read the comments.
On a related note, it seems that for certain kinds of bugs (e.g., blockers of the next release or two), status flags could be pretty valuable, but for other kinds of bugs, people might not care too much. Maybe if someone who is tracking blockers really wants those flags to be right, they could go around fixing them/asking assignees to keep them up to date, and we might be able to get the info for the case where we actually need it.
I guess the point I'm trying to make is that for most bugs, I'm with you that the open/in_progress is enough. But for cases where we actually need to schedule or unblock work, we need more information. I might want even more than "in_progress" someday, like "to start on date X", "ETA date X", "blocked on bug X", "blocked, see comment X".
> You could certainly make things better by preventing the combination > of assignee=nobody + status = IN_PROGRESS. Yes. > You could also make it better by optionally being able to change the > status to IN_PROGRESS when somebody attaches a patch. That will reduce > friction and increase the likelihood of success.
Why not automatically change the status to IN_PROGRESS when a patch is attached? And how about automatically changing status back to CONFIRMED if N days go by with no comments or changes from the assignee?
> But overall, I still think we'd be better off with a single "open" > status, which, when a bug is assigned to nobody, means "ready", and > when it's assigned to somebody, means "in progress". There are edge > cases where somebody is assigned a bug but isn't working on it or > doesn't plan to work on it, but that's already the degenerate case > where more metadata probably won't help.
On Thu, Oct 28, 2010 at 9:52 PM, David Mandelin <dmande...@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.
> 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"?
> On Thu, Oct 28, 2010 at 9:52 PM, David Mandelin<dmande...@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.
Of course I would not recommend anything so bureaucratic than that. We do post in bugs asking for updates sometimes when there hasn't been progress in a while, so it's not unprecedented. More routine requests could use email in order not to clutter up the bugs. But the hope would be to foster a change in how people communicate their activity on high-priority bugs, so that such requests would eventually be unnecessary.
>> I guess the point I'm trying to make is that for most bugs, I'm with you >> that the open/in_progress is enough. But for cases where we actually need to >> schedule or unblock work, we need more information. I might want even more >> than "in_progress" someday, like "to start on date X", "ETA date X", >> "blocked on bug X", "blocked, see comment X". >> Why not automatically change the status to IN_PROGRESS when a patch is >> attached? And how about automatically changing status back to CONFIRMED if N >> days go by with no comments or changes from the assignee? > At this point why bother having these as actual statuses? > Why not have them as "VIEWS"?
Mike Connor <mcon...@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?
Gervase Markham <g...@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.
Mike Hommey <m...@glandium.org> wrote: > On Thu, Oct 28, 2010 at 11:23:53AM -0700, Reed Loden wrote: > > 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)
We tried the generic thing. It never works. Specific bugs for specific components bring actual results to fruition.
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".
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.
> 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".
> 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 > pbig...@mozilla.com > _______________________________________________ > dev-planning mailing list > dev-plann...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-planning
The latest post from Reed implies that the result of this discussion 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.
> 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?"
