If I understand http://bugzilla.mozilla.org/bug_status.html correctly, a bug should only be CLOSED when it's been first RESOLVEd, then VERIFIED, and then the product ships. So probably not everyone should be able to mark a bug CLOSED.

I agree, it would be nice to have a feature similar to "Can confirm a bug" that would be called "Can close a bug". This could be expanded to include "Can ________ a bug" and insert whatever state a bug may be in. In our QA process, only the person who opened the bug is allowed to close it, so perhaps something like this could be an option as well?

tara@tequilarista.org is the new owner of Bugzilla and Bonsai. (For details, see my posting in netscape.public.mozilla.webtools, news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)

Bah. More and more people use "Closed" where they really mean "Verified". This is partially an education thing, and partially a "mistake is easily made" thing. By not making it possible for people to close the bug unless they are actually allowed to close it you'd solve a lot of problems. CC'ing david@krause.net per timeless' request.

This seems like a good idea to me too. Maybe this option could even be disabled in the mozilla.org bugzilla installation until Mozilla 1.0 begins to see the light of day.

Add my vote.

also think this is a good idea

Bug 49808 has a patch for this. It doesn't seem to leave the options off of show_bug.cgi for users without the permissions, though.

Asa/DawnTara, what's the status on this?

*punt* we are getting more and more people helping out, and the number of closed bugs is rising. Another options would be a "unclose" bug button which would reset the bug to the inital resolution.

It might be partly a `mistake is easily made' thing ... but the fact that <http://bugzilla.mozilla.org/bug_status.html> doesn't actually mention anything about shipping a product can't help.

mpt, it does. VERIFIED QA has looked at the bug and the resolution and agrees that the appropriate resolution has been taken. Bugs remain in this state until the product they were reported against actually ships, at which point they become CLOSED.

i asked nearly a month ago, but never got a response: what's the status of this issue? or, rather, when will this be fixed? how difficult could it be to make the Close radio button only visible to people with the right privs? i guess it [partially?] depends on when and whether the patch for bug 49808 is checked in... thanks much!

Ok Asa, your turn to reopen bug 50174. :-) But I still think the resolution page should clarify the meaning of CLOSED in the CLOSED section itself.

So can someone explain what the rationale behind having CLOSED at all is, anyways? It doesn't seem to be any more than VERIFIED. And bugs that have been CLOSED are just as likely to get reopened as VERIFIED ones are. So what's up? Is it just meant as a third level of QA (RESOLVED -> VERIFIED -> CLOSED) ?

It makes sense to do away with the option altogether. As Blake said, a bug can just as easily regress after the product ships (bug marked CLOSED) as it is before the product ships (bug marked VERIFIED). It seems that the CLOSED option may just be redundant.

Where CLOSED would make sense is for RFE kinda bugs. I'd rather not people reopen those because of a regression (since they'd have to change the bug from "RFE implement foo" to "foo doesn't do bar any longer" anyway).

I think what Stephen says about CLOSED being unnecessary is true. It should be up to the product team to check for regressions when the product ships. And whenever else they choose to. And it would be nice if we didn't get the extra VERIFIED -> CLOSED notification. That being said, CLOSED gives them an easy way to maintain a list of unchecked bugs. How can we provide that functionality in a better way?

just a comment. i think closed is fine as a state. it helps me determine easily determine the bugs which have been reopened due to customer response (reopen after a close) and those which have been caught in QA (reopen after resolved/fixed). this in turn helps me to oversee the effectiveness of our QA people.

This may be more of a mozilla.org thing really -- should it be moved to the Mozilla.org component? Asa?

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

moving to Bugzilla product reassign to default owner/qa for INVALID/WONTFIX/WORKSFORME/DUPLICATE

Verified dupe