It seems that the "votes to confirm" threshold got bumped down to 2 in the wake of the reorg. This resulted in a number of bugs being confirmed, a lot of them incorrectly (bug not actually valid or worksforme, poorly explained, misfiled, etc). I really don't see the usefulness of this functionality for bugzilla.mozilla.org. I realize we have to have the number set to nonzero for unconfirmed to work at all, but perhaps we should just set it really high (say in the thousands)?
Three has served us fairly well over the years. I accidentally set it to 2 briefly. It's back at 3 now. If I run across a bug that's got 4 people saying they see it, I usually confirm it. Four people reporting the same thing is often a better indicator that it's a real bug than a bug filed by someone like me where the bug starts off as new. One reporter and three voters seems like a pretty good barometer to me so I don't think we should change this.
The problem is that we're treating "NEW" as the "triaged" status, not as the "it's a real bug" status... If we had a state that indicated triaged bugs, I'd have no problems with this auto-confirming...
(In reply to comment #2) > The problem is that we're treating "NEW" as the "triaged" status, not as the > "it's a real bug" status... So when the thousands of people with Can Confirm priveleges file a bug it's considered "triaged"? That doesn't seem make a lot of sense. Nearly 40% of my bugs turn out to be crap yet they start out as New. How do you keep those separate from bugs that have actually been triaged? Should we take Can Confirm away from everyone and have all bugs start out as Unconfirmed until they're triaged? That's a fairly major change, but not one I'm firmly opposed to.
> So when the thousands of people with Can Confirm priveleges file a bug it's > considered "triaged"? At the moment, yes, due to lack of ability to distinguish it from actually triaged bugs. This is why the READY state received such support when it was mentioned.... > How do you keep those separate from bugs that have actually been triaged? We don't. This is a major problem with current triage efforts. > Should we take Can Confirm away from everyone and have all bugs start out as > Unconfirmed until they're triaged? I'd rather we had READY or some other way of marking triaged bugs so we don't have to make NEW do double duty ("issue actually exists" and "this is a real bug").
Taking all of myk's bugs in the Other b.m.o issues component that he isn't actively working on, since he's no longer the default assignee for this component, and these were all filed while he was.
Assignee: myk → justdave
Assignee: justdave → marcia
Component: Bugzilla: Other b.m.o Issues → Bugzilla: Keywords & Components
QA Contact: justdave → timeless
Is this still needed? Last comments date back to 2004.
Status: NEW → ASSIGNED
The votes to confirm threshold has already been raised to some high number for most b.m.o components, mostly by timeless (see e.g. bug 314256). I think this bug can be resolved.
Resolving WORKSFORME. Gerv
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
Component: Bugzilla: Keywords & Components → Administration
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.