rejection/resolution types would be desirable

[Luis Villa]

Currently in malone, one can only 'reject' a bug; in bugzilla we've found that having data about why a bug was rejected/closed (incomplete/invalid, needinfo, duplicate, etc.) is useful for understanding trends within the bugzilla.

[Trent Lloyd (lathiat)]

Yes, this would be great, among other things a NEEDINFO state would be very usefull, and the Wontfix shoudl not be a priority imho but a 'resolution', altho i suppose it makes some sense as a priority, but its an incomplete idea only as a priority

[Luis Villa (luis-villa)]

Waitwaitwait. WONTFIX is a priority? NONONONONONO. Mozilla has known since 1999 that mixing priorities and resolutions is a bad idea:

https://bugzilla.mozilla.org/show_bug.cgi?id=13534

Mix them together and you break:
* triager's and maintainer's mental models
* statistical reporting

Those are the big two, but other little things (queries not returning what you expect, etc.) are also broken as well. Don't repeat their mistake...

[Matthew Paul Thomas (mpt)]

Luis, what has the "understanding [of] trends in Bugzilla" been used for? The more complicated the data model, the greater the proportion of known bugs that stay unreported, so anything extra should have a pretty good justification.

(And yes, we know wontfix shouldn't be a priority, but please, one bug per bug report.:-)

[Vincent Untz (vuntz)]

mpt: "understanding of trends in bugzilla" is useful when you're a bugmaster and you're trying to keep the bug databases clean and useful for the developpers. Also, it's useful to quickly look at a bug and know why it's in a specific state without having to read all the comments.

NEEDINFO is really useful since you can easily know that the bug has been triaged and needs more informations, and close it if no informations has been given after two months (for example).

Now, there's already a way to mark bug as duplicate, but it's in the right sidebar.

The only other thing that is important is a way to differentiate closed because of WONTFIX (that would be Rejected in malone) and closed because there's not enough informations (missing state for this one). INVALID is not that useful.

[Luis Villa (luis-villa)]

Unfortunately I'm swamped at my new job so I have very little time to help out or even read malone mail ATM, but offhand this kind of data can help bugmasters know:
* is the quality of incoming bugs increasing/decreasing? Do we need to recruit more triagers, or more reporters? To find this out you need to know the ratio of closed FIXED to closed INVALID,etc.
* the total number of bugs coming in is almost always rising. Is the number of *valid*/non-dup/non-insane bugs coming in rising, though? If so, that is not a good sign. Can only be known if you have resolution types.
* are our paid developers closing lots of things WONTFIX/INVALID? Does that imply that the triagers are failing? Does that imply that the developers are getting burnt out and more aggressive?
* If lots of things sit unresponded in NEEDINFO, are we not making the requests persuasive enough, or perhaps we've not trained our people to ask the right questions?

Basically, if no one is harvesting this type of data regularly to understand bug trends:
* you don't know whether or not your product is getting more or less buggier
* you don't know whether or not your volunteers are getting more or less effective

TTFN...

[Brad Bollenbach (bradb)]

Luis,

Can we paint a picture of bug report quality through Rejected vs. Fixed? To me, this is the same as Closed + Invalid and Closed + Fixed, respectively.

Can we use "Accepted" to mean "this is a bug and there is enough information in this report for the maintainer to proceed with?"

For "our paid developers...": it doesn't look like we're collecting all the data necessary to make this possible, ATM, unless assignee != NULL were a precondition to setting a resolution status in Malone.

I get the impression that bugmaster reporting is probably some ways down the road for Malone though, of course, your input on the matter is invaluable in giving us things to think about when we do reach that position.

The NeedInfo status is being rolled out as I prepare to hit the "Post Comment" button on this report.

[Matthew Paul Thomas (mpt)]

Now that we have the "Needs Info" status, I think the only remaining step is to make the "Not a Bug"/"Not For Us" distinction (bug 36059). Then we can get useful knowledge from counting/graphing the statuses separately. Luis, does this seem accurate?

[Christian Reis (kiko)]

Yeah, that sounds about correct; that's the most important status information that we currently miss tracking.