timeless

Spam for the sake of database purity

2005-03-24 01:06 UTC  by  timeless
0
0
Spam for the sake of database purity Spam for the sake of database purity

What's wrong with auto resolving unconfirmed bugs?

Lots of things.

What's wrong with a little spam?

Just because you think there's only a little doesn't mean it won't add up quickly for someone else.

What problem am I really talking about?

Gerv's proposal to autoresolve bugs and other people's counter proposals to auto poke bugs to prevent him from autoresolving bugs.

What did i have to say about gerv's proposal?

It incurs more damage and harm than leaving the problem as is. if the bug reporter is good, as happens to be the case of a reporter (to be named later, pending notification and verification from the innocent), he will eventually resolve the bug as worksforme. if the bug reporter is not good, as is probably the average case, we may never hear from him again, and may instead get 15 other reports of the same problem over time.

What improvements have we made to bugzilla recently?

We changed the default search from searching NEW, ASSI, and REOP to --- and DUPL.

How was that insufficient?

people are never going to search the worksforme pile and simply reopen a previously reported bug. We really should include WFM for canTconfirm users).

What was the challenge?

But let's hear your alternative. Where do you suggest we find the manpower to manually triage all of these old bugs? And, having obtained this mass of manpower, would that really be the best use of it anyway?
timeless

Putting bug filers to work

2005-03-24 01:16 UTC  by  timeless
0
0
Putting bug filers to work Putting bug filers to work

Where can we find "manpower to manually triage all of these old bugs"?

One possibility is to give people a random subset of their open bug list when they log in and asking them to triage it. depending on how annoying you want to be, you could demand that they do so before they take other actions.

How could we harness this potential workforce?

Make people who do not have canconfirm do triage before filing a bug. this could be done in a few steps.
  1. A user files a bug and the bug gets put into a holding bin.
  2. the user is then given some random (* it's best to try to select the list based on the user's bug filing) portion of the unconfirmed or open buglist for that component and asked to select 5 items from it to be tested.
  3. the user would be encouraged to either update the build tested field or add a comment in the case where the bug works for them.
  4. if the component does not have enough open bugs, the list could be changed to only resolved (and not verified bugs), again with the user being requested to test 5 (* number is arbitrary and of course should be tunable) such bugs and either comment indicating the problem still occurs [perhaps simply filling in an item into the build tested list], or adding to the verified field.
So what would this do? we can call these brownie points and allow the user to accrue them.

What would users do with their brownie points?

they've earned enough brownie points, bring them back to the bug report they wanted to file and give them a chance to edit it or submit it. hopefully after they've triaged bugs they'll realize how they can improve their filing.

What if the component is really in mint condition?

  • We could choose not to require this form of pruning
  • Give them a random selection from another component.

What does this give us?

magically you now have "manpower to manually triage all of these old bugs" and while it might not be "the best use of it", it would certainly be a very good use of it.

What's the status of this proposal?

I received a bug report in the Webtools:LXR component, I gave the reporter 3 related open bugs and asked for triage. As it happens, I picked bugs with the same exact url, but we can also do body matching if we don't get good url matches (boy was i lucky). the list of 131 bugs included 72 open bugs.

Back