328152 - Bug of too many phases of bug's life is categorized as Status=NEW.

Status: RESOLVED DUPLICATE of bug 119305

(bugzilla.mozilla.org :: General, enhancement)

Description

[WADA:World Anti-bad-Duping Agency]

Bug of too many phases of bug's life is categorized as Status=NEW.

"Auto-reply" has successufully reduced number of UNCONFIRMED bugs of no action for long time. But, once the status is changed to NEW, auto-close is almost impossible.

However, it's very difficult to distinguish "valid bugs" and "bugs(problems) which still require analysis", because bug of too many phases is categorized as Status=NEW.
Status=NEW is currently used for all of next phases :
 (1-A) Status=UNCONFIRMED bug(Severity NE Enhancement) is changed to Status=NEW
       by user of "canconfirm" previledge or higer.
       This usually means "Problem was re-created", but sometimes doesn't
       ('me too' like).
 (1-B) Status=UNCONFIRMED bug(Severity EQ Enhancement) is changed to Status=NEW
       by user of "canconfirm" previledge or higher.
       When Seveirity=Enhancement bug, meaning of Stats=NEW is unclear.
       Which? 
       - Mozilla.org agreed to implement
       - One or more user of "canconfirm" or hiher also want this enhancement
 (2-A) Status=NEW bug(Severity NE Enhancement) is opened by user of
       "canconfirm" previledge or higher.
       This usually means "Problem is re-creatable", but sometimes doesn't.
       When this phase, it's usually uncertain whether real bug or not.
 (2-B) Status=NEW bug(Severity EQ Enhancement) is opened by user of
       "canconfirm" previledge or higher.
       When Seveirity=Enhancement bug, meaning is unclear. It's same as (1-B).
 (3)   Above (1-A) or (2-A) is found to be really bug of Mozilla family,
       but developers/triage team are still not aware on it.
 (4)   (3) or (1-B) or (2-B) is awared by triage team.
       When this phase, Priority/TargetMileStone is usually set appropriately.
 (5)   (3) or (4) is awared by developers but implementation of patch/feature
       is not started yet.
       When this phase, comments by developer(s) are usually added.
       But status is not changed to "ASSIGEND" yet.
To know which phase, "read thru the bug" is always needed.

I guess this is because :
  -  "Buzgilla and Bugzlla.mozilla.org" initially assumed that
     "Bug" is opened by developer and almost all "Bug" is valid bug.
But any "canconfirm" priviledge user can now open Status=NEW bug, and can now change Staus=UNCONFIRMED bug to Status=NEW.
I think at least "valid/real bug(already analyzed)" and "problem which still requires analysis" should be isolated.
  (Type-1)   Valid/real bug, Acdepted enhancement : (3), (4) and (5)
  (Type-2-A) Problem still requires analysis      : (1-A) and (2-A)
  (Type-2-B) Enhancement still not accepted       : (1-B) and (2-B)

Is it possible to add status(es) for above (3)/(4)/(5) to bugzilla.mozilla.org system?
If possible, "Auto-Reply" like action can be taken on too old unalayzed bug.

Is there clear procedure or rule for Severity=Enhancement bug?

Comment 1

[timeless]

we're unlikely to deal with this. it's too much work to add additional states. it's also fairly unreasonable to expect people to maintain and properly use additional states. and of course, supposing we did add states specific to enhancements, what happens when people fight over whether a bug is really an enhancement?

that said, there are bugs asking for a NEED status with things like NEED INFO, NEED STEPS, NEED TESTCASE, NEED ... such a thing /might/ be implemented, but is covered by some other bug.

Comment 2

[victory <[e-mail]>]

WADA:
see http://wiki.mozilla.org/Bugzilla:Roadmap

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #2)
> WADA:
> see http://wiki.mozilla.org/Bugzilla:Roadmap
Thanks for pointing.
If Bug 101179 will be implemented(Status=ACCEPTED can be used), and if mozilla.org will decide to use Status=ACCEPTED for both Severity=Enhancement bug and Severity=Non-Enhancement bug(analyzed and valid bug), my request can be achieved.

(In reply to comment #1)
> we're unlikely to deal with this. it's too much work to add additional states.
timeless, will mozilla.org be "unlikely to deal with" even when the enhancemnt will be implememted by future release of Bugzilla.  

> it's also fairly unreasonable to expect people to maintain and properly use
> additional states.
I agree with you. It's always one of the hardest problem in any system...

Comment 4

[WADA:World Anti-bad-Duping Agency]

Changing status to messy "NEW" in order to avoid "Auto Reply" :-)

Comment 5

[Dave Miller [:justdave]]

*** This bug has been marked as a duplicate of 119305 ***

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #5)
Dave Miller, thanks for DUPing. 
I could see proposal of next STATUSes in attachement on 2002-01-15 in Bug 119305.
> UNTRIAGED, TRIAGED, NEW, ACCEPTED, UNASSIGNED, REOPENED, RESOLVED, VERIFIED,
> and CLOSED
(Four years ago, 19-th/Salt Lake City... 20-th/Trino is near end. I hope they'll be implemeted before start of 21-th/Vancouver in 2010.)