104049 - Change "ASSIGNED" status to "INPROGRESS"

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, enhancement, P3)

Description

[Myk Melez [:myk] [@mykmelez]]

There is an incongruence between the ASSIGNED status and the assignee field. 
"Assigning" or "reassigning" a bug does not change its status to "ASSIGNED", and
bugs are always assigned to someone no matter what their status.

The solution to this problem is to change the terminology for one of these
fields, and the status field is the likely candidate for revision since we
already use a different terminology for it: we say that a bug gets "accepted"
when its status changes to "ASSIGNED".

Comment 1

[Matthew Tuck [:CodeMachine]]

This ain't gonna happen automatically for existing installations, we can change
the default once customised statuses (bug #101179) lands though.

Comment 2

[Matthew Tuck [:CodeMachine]]

I'll take this.

Comment 3

[Asa Dotzler [:asa]]

It seems to me that the problem here is the label "Assigned To:" is just wrong
most of the time. If that label was "Developer Contact:" we'd clear out a lot of
confusion.

The bug status "Assigned" seems fine to me if you clear up the label for the
"Assigned To:" field. The only other change that might be helpful to change is
the lable in the status change section. Changing it from "Accept bug (change
status to ASSIGNED)" to "Assign to current Developer Contact" would clear things
up a lot.

Making these two label changes wouldn't require any logic changes and would make
things a lot clearer.

A further enhancement would be to add logic to have the lable actually change
from "Developer Contact:" when the bug status was Unconfirmed, New, or Reopened
to "Assigned To:" when the bug status becomes Asssigned (it would probably also
make sense to change it back to "Developer Contact:" when the bug status becomes
Resolved, Verified and Closed.)

Maybe i'm misreading this report. Am I totally off-base here? Is there a better
bug for my issue?

Comment 4

[Dave Miller [:justdave]]

Taking Jake's bugs...  his Army Reserve unit has been deployed.

Comment 5

[Dave Miller [:justdave]]

Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)

Comment 6

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 7

[Barry Cohen]

I don't see why the ASSIGNED status exists at all.  I think it should just be
ACCEPTED instead.

When a bug is assigned, its status is NEW, regardless of whether it's a
just-created bug or a reassigned bug.  When the developer decides that they want
to accept it, the status should become ACCEPTED.

This would also clear up some of the problems in bug 37613, where one person can
accept a bug for someone else.  It makes sense that you may want to assign a bug
*to* someone else, but nobody should accept a bug *for* someone else.

I'd be interested to hear if there were other reasons why the ASSIGNED status is
necessary.

Comment 8

[Frédéric Buclin]

no idea when bug 101179 will be fixed, probably not before 2.24 or even 3.0

Comment 9

[Max Kanat-Alexander]

For Bugzilla at least, ASSIGNED means "This bug has somebody working on it, and it actually has a patch on it." That's fairly useful, when looking at a bug list.

Comment 10

[Christian Höltje]

From the conversations in IRC with timely:
(13:30:48) docwhat: I was only referring to initial "default assignee".
(13:31:24) timely: well, again, in general that default assignee should be a good person to contact for info about the problem
(13:31:29) timely: (assuming it's not a mailing list)
(13:31:37) timely: (actually, heck, even if it is...)
(13:31:57) timely: it's still more queryable than the default supersize pot
(13:32:31) timely: now, if you're concerned about confusing between actively owned bugs and bugs that were defaulted
(13:32:38) timely: you can encourage people to use the ASSIGNED state
(13:32:51) timely: and have bugs that aren't ASSIGNED be treated as well... not ASSIGNED :)
(13:33:19) timely: (better to read that state as "ACCEPTED" or "WELL OWNED" than "ASSIGNED" because there's some confusion between ASSIGNED and assigned_to, but ...)

I like the idea of seperating these concepts; sending a bug to someone is different than accepting it vs. saying "our expert or responsible member is"...

Ciao!

Comment 11

[Eyal Rozenberg]

Maybe something like "IN THE CHARGE OF" or "IN THE CARE OF" or "TAKEN ON BY". "ACCEPTED" has the semantic disadvantage that when you do what today is a reassign, it would sound as though someone has gone back on accepting the bug; so an adjective which is extensional rather than intentional seems better (not the _reason_ someone is in charge of/working on the bug, just that fact itself).

Comment 12

[Stephen Rasku]

Is anyone actually opposed to the term "ACCEPTED"?  

If I reassign a bug that I originally accepted then I have gone back on accepting the bug.  It happens.  I don't have a problem with it.

Comment 13

[Frédéric Buclin]

*** Bug 358205 has been marked as a duplicate of this bug. ***

Comment 14

[ferg2k]

My users seem to like having both Assigned and Accepted states.  Here's the standard reasoning:

Assigned: this means someone has said the assignee *should* fix (or at least look at) this bug.  Note that an assignee in my installation can be either an individual or a mailing list for a group of individuals.

Accepted: this means a person has said they *will* fix the bug (or at least take responsibility for looking at it).  This can only be an individual user, never a mailing list.

Assigning is a management action from above.  Accepting is a commitment by a developer from below.  (adjust above/below to suit your world view.)

Comment 16

[Andrés G. Aragoneses]

I am the reporter of bug 370050.

In that bug, I stated the confusion between the terms "ASSIGNED" and "Assigned-To" as the justification of the bug, but that doesn't mean, IMHO, that this is a dupe.

In fact, based on the confusion between these two terms, in my Bugzilla installation I have used the word "INPROGRESS" as a substitute of "ASSIGNED" to avoid it. But that workaround doesn't solve my problem (the thing that I want is to only allow the status change to INPROGRESS/ASSIGNED if the user in the Assigned-to field is the same as the one that requests that change).

Regarding again the terms confusion, I would also recommend the change from "Assigned-to" to "Responsible" or something like that.

Comment 17

[Max Kanat-Alexander]

I think INPROGRESS makes much more sense and is much more useful.

How often does it really matter whether or not somebody's *agreed* to work on the bug?

I think the idea of ACCEPTED dates back to when all of our default assignees were real people, and they might not actually have even noticed the bug was filed.

However, nowadays we've realized it's clearer to make fake assignees, and then just set ASSIGNED when you're actually working on the bug.

Comment 18

[Vitaly Fedrushkov]

This is fixed by bug 519142 for anybody willing to change user-visible terms.

Comment 19

[Andrés G. Aragoneses]

(In reply to recent status resolution)
> Max Kanat-Alexander <[e-mail]> changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>             Status|NEW                         |RESOLVED
>         Resolution|                            |FIXED

Hey! Thanks for fixing this. Now I'm wondering what does this really mean:

a) Do new bugzilla installations setup from scratch have an INPROGRESS status instead of ASSIGNED.
b) Do bugzilla installations that are updated to 4.0 replace the ASSIGNED status by the INPROGRESS one?

Comment 20

[Andrés G. Aragoneses]

FYI I filed bug 630829 which is related to this one.