1151371 - Activate IN_PROGRESS in BMO

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: Administration, task)

Description

[Tobias B. Besemer [:BesTo] (QA)]

I read in Bug 1036834 about the status "IN_PROGRESS".

And I read in Bug 630829 that the "status IN_PROGRESS was introduced in 4.0".

Because I had problems with the statuses NEW and ASSIGNED https://groups.google.com/forum/?hl=de#!topic/mozilla.dev.platform/3DAYBckD2C4 it would be nice if the status IN_PROGRESS gets activated and the outdated https://bugzilla.mozilla.org/page.cgi?id=fields.html updated.

Comment 1

[:glob ✱]

changing the statuses we use to track our process would break many many things, so we unfortunately cannot do this.

from the thread:

> From my experience, many (most?) teams never change a bug's "Status"
> from NEW to ASSIGNED, but they still use "Assigned To". A few teams set
> both, but change "Status" from NEW to ASSIGNED when the assigned
> developer actually begins to work on the bug. 

that's accurate.

bmo is set up for the process where a bug is assigned to someone to put it into their work queue, and then they change it to assigned when they start working on it.  however as each team uses bugzilla differently this isn't used consistently or enforced strictly by most teams that follow that process.

Comment 2

[Tobias B. Besemer [:BesTo] (QA)]

(In reply to Byron Jones ‹:glob› from comment #1)
> changing the statuses we use to track our process would break many many
> things, so we unfortunately cannot do this.
> 
> from the thread:
> 
> > From my experience, many (most?) teams never change a bug's "Status"
> > from NEW to ASSIGNED, but they still use "Assigned To". A few teams set
> > both, but change "Status" from NEW to ASSIGNED when the assigned
> > developer actually begins to work on the bug. 
> 
> that's accurate.
> 
> bmo is set up for the process where a bug is assigned to someone to put it
> into their work queue, and then they change it to assigned when they start
> working on it.  however as each team uses bugzilla differently this isn't
> used consistently or enforced strictly by most teams that follow that
> process.

That's exactly why I think it should be activated!

The solution that a dev set the status to ASSIGNED when he start to work on it and the bug is "in progress" comes IMHO from a time where the status "IN_PROGRESS" not existed!
But the status "IN_PROGRESS" was implemented to cover exactly this problem!

Daniel Holbert wrote in his comment to the topic in mozilla.dev.plattform:
> To be clear, I don't think he's planning on mass-changing the *assignee*
> field -- rather, it sounds like his next plan was to reset Status to
> "NEW", for bugs that are ASSIGNED but have no assignee.
>
> That seems like a reasonable sort of change to me.  Of course, any
> mass-change in Bugzilla could have unintended consequences or step on
> toes in some obscure component with its own rules; but AFAIK, this
> particular change seems likely to just be a change to better-reflect
> reality.
>
> (I'm not sure how much value it adds, but I don't see it doing much harm.)
>
> ~Daniel

And this is the reason why I think it should be activated.
Only if the status "NEW" is used from QA to verify that a bug is new and unique in the db and when devs use "ASSIGNED" to do bugs on there to-do-list, the db is usable for newbies, Non-Mozilla-Employees and volunteers in a usable way.

Lets say a new, young volunteer is searching for a bug he can try to fix ... How should he search ???
If he search ATM for "NEW" he will find a lot of bugs that are verified but not "free" to assign and he can't try to fix them. He needs to go through a long list to find one thats is assignable for him, he is interested in and he think he can fix it.

Also if someone now is interested in the project(s) and want to follow the dev progress to maybe make QA have ATM not the change to find the bugs with "progress" on to make e.g. QA for them.

Not activating "IN_PROGRESS" just brings the benefit that no dev or team have to change a little bit the way they work with bmo, but brings a huge list of negative things to all others!

So please rethink to activate "IN_PROGRESS"! Thx!

Comment 3

[Tobias B. Besemer [:BesTo] (QA)]

Btw.: No volunteer will understand the actual use of this field until he did something wrong and he gets trouble! Not really intuitive! (Also because not used by everybody in the same way.) ;-)

Comment 4

[Mark Côté [:mcote]]

(In reply to Tobias B. Besemer from comment #2)
> (In reply to Byron Jones ‹:glob› from comment #1)
> > changing the statuses we use to track our process would break many many
> > things, so we unfortunately cannot do this.
> > 
> > from the thread:
> > 
> > > From my experience, many (most?) teams never change a bug's "Status"
> > > from NEW to ASSIGNED, but they still use "Assigned To". A few teams set
> > > both, but change "Status" from NEW to ASSIGNED when the assigned
> > > developer actually begins to work on the bug. 
> > 
> > that's accurate.
> > 
> > bmo is set up for the process where a bug is assigned to someone to put it
> > into their work queue, and then they change it to assigned when they start
> > working on it.  however as each team uses bugzilla differently this isn't
> > used consistently or enforced strictly by most teams that follow that
> > process.
> 
> That's exactly why I think it should be activated!
> 
> The solution that a dev set the status to ASSIGNED when he start to work on
> it and the bug is "in progress" comes IMHO from a time where the status
> "IN_PROGRESS" not existed!
> But the status "IN_PROGRESS" was implemented to cover exactly this problem!

The main problem is that "each team uses bugzilla differently".  Adding another status will not change this.  Instead, we'll now have one more convention, and hence even more confusion.

> 
> Daniel Holbert wrote in his comment to the topic in mozilla.dev.plattform:
> > To be clear, I don't think he's planning on mass-changing the *assignee*
> > field -- rather, it sounds like his next plan was to reset Status to
> > "NEW", for bugs that are ASSIGNED but have no assignee.
> >
> > That seems like a reasonable sort of change to me.  Of course, any
> > mass-change in Bugzilla could have unintended consequences or step on
> > toes in some obscure component with its own rules; but AFAIK, this
> > particular change seems likely to just be a change to better-reflect
> > reality.
> >
> > (I'm not sure how much value it adds, but I don't see it doing much harm.)
> >
> > ~Daniel
> 
> And this is the reason why I think it should be activated.
> Only if the status "NEW" is used from QA to verify that a bug is new and
> unique in the db and when devs use "ASSIGNED" to do bugs on there
> to-do-list, the db is usable for newbies, Non-Mozilla-Employees and
> volunteers in a usable way.
> 
> Lets say a new, young volunteer is searching for a bug he can try to fix ...
> How should he search ???
> If he search ATM for "NEW" he will find a lot of bugs that are verified but
> not "free" to assign and he can't try to fix them. He needs to go through a
> long list to find one thats is assignable for him, he is interested in and
> he think he can fix it.

The volunteer should search for both "NEW" and assigned to nobody.

> Also if someone now is interested in the project(s) and want to follow the
> dev progress to maybe make QA have ATM not the change to find the bugs with
> "progress" on to make e.g. QA for them.
> 
> Not activating "IN_PROGRESS" just brings the benefit that no dev or team
> have to change a little bit the way they work with bmo, but brings a huge
> list of negative things to all others!
> 
> So please rethink to activate "IN_PROGRESS"! Thx!

I understand your concerns, and I agree that some of the ways we use Bugzilla are not clear or are downright confusing.  

However, adding a new status will only be effective if there is a lot of buy-in from teams.  If only a few switch over, we'll have even more confusion.  Also, as mentioned, it can also have a big effect on existing tools and dashboards; the current set of statuses and resolutions can be seen as a stable API and not changed without good reason.

If you really want to see this through, I would try to come to a general agreement in a forum such as dev.platform.  Until such time as we believe a good number of people will support this decision, I'm going to leave this as WONTFIX.

Comment 5

[Tobias B. Besemer [:BesTo] (QA)]

OK, I point to this bug in the topic in dev.platform. Lets have a look what the others say ...