Project talk:WikiProject Bug Squad/Flow

Who is going to challenge a developer that's trying to humiliate a bug hunter by marking correct bug reports as invalid? I used to make many bug reports. I was accused of vandalism and humiliated because one of my bug reports was invalid, and further accused of not being able to make decent bug reports (bugzilla:33403#c1). Next, I counted my bug reports, and found that at least 75% of them were good bug reports, and posted the information on my user page here. Then, humiliation tactics changed to marking my good bug reports as invalid, even when they're not, so I couldn't keep score anymore (example: bugzilla:33479).

I haven't done anywhere near as much bug hunting for WMF since 2012 because of this. It turns out shooting the messenger is a common problem for bug hunters, because they frequently encounter hostility from a small but significant fraction of developers, throughout the world, not just in WMF projects. Can WMF be progressive in leveling the playing field, discouraging developer hostility, and encouraging bug hunter enthusiasm for their difficult and thankless tasks? At what point do the interests of volunteer bug hunters matter to an authority figure in WMF enough to overrule a developer on a minor issue like marking a bug report as valid so we can keep score of the number of valid bug reports someone has contributed? Who is going to stand up for me, to ensure that I continue to enjoy doing the jobs that nobody else likes to do (without being paid for it)?

How many dedicated volunteer bug hunters are there, anyway? Am I the only one? I'm sure dedicated specialist bug hunters are few in number, even if I'm not the only one. Who is hurt and who is helped when bug hunters stop bug hunting? Could WMF benefit from having more bug hunters? Could WMF benefit if bug hunters were encouraged to count their successful bug reports?

You're not alone. There are some components where I never file bug reports because maintainers just make it a waste of time: it's their loss, not mine. Just ignore them and report bugs in other components.

By the way, as it seems there may be some extremists advocating for suppression of bugzilla and volunteer bug reporters, I added a section Talk:Project_management_tools/Review/Options#Reporters_engagement_ideal.

Nemo: Uh, "it seems there may be some extremists advocating for suppression of bugzilla and volunteer bug reporters"? Either link or differentiation welcome. I haven't seen anybody saying "We want no volunteer bug reports at all" yet.

No but I've seen "in case we want them, then"; which, for me, equals advocating there is a chance we don't want them.

That was probably me argumenting for the needs of reporters and users, as discussion on Product Management Tools was so far mostly focused on needs of developers, maintainers and managers. "In case we want peace on earth" equals advocating a chance of war too, I guess. Interpretation of words in another language; sorry if I created confusion or a wrong impression here.

I don't think it was you, don't worry.

Hi Badon, yeah, I dislike bugzilla:33403#c1 reading that comment, but I have no idea about potential previous tension already at that time (two years ago) as I wasn't around at that time. I understand such comments are demotivating and I appreciate your rationale followup comment! For a few months now we have mw:Bug management/Bugzilla etiquette in place which provides guidelines that everybody in Bugzilla should follow. If you face any hostility again, please notify me so I can take a look. For bugzilla:33479 the term "INVALID" seems to be the problem? I prefer to not have too many bug resolutions that try to cover each potential situation (in this case maybe BUG_ALREADY_FIXED_WHEN_FILED), so there will always be some space left for interpretation that reporters and developers might disagree on, unfortunately. And "bad" bug reports happen to everybody, may they be duplicates or having been fixed already. These reports are not a problem and are still very welcome as they might provide more information and as each reporter's motivation clearly is to help and to make the project better. Decisions should be explained to reporters (as it happened in comment 1 and 3). I'd interpret FIXED as an identifiable code commit that was merged into the code repository after the report was filed, but this is not 100% clear in mw:Bug management/Bug report life cycle either. Anyway, as I wrote above, I don't think we should over-define each resolution and end up coming up with lots of new ones trying to cover each potential situation as I don't see how this would help anybody. I understand the motivation to "keep score of the number of valid bug reports someone has contributed" but I don't think that some "success" ratio should be the main objective here - in the end nearly all bug reports are helpful, whatever resolution they end up with. I'd rather go with general activity in the bugtracker (e.g. helping by commenting to track down an issue also when you're not the reporter of it), which is currently being worked on as part of community metrics. Surely WMF could benefit from having more bug hunters, though I would replace "WMF" by "the Wikimedia community" and I'd expect this to be true for any free and open software project out there. Again, I am sorry that the process of bug handling is sometimes demotivating for some of the involved parties.

Thank you very much for your attention to this issue. Fortunately, serious conflicts like we saw in bugzilla:33403#c1 are very rare, and have not happened again in the last 2 years (maybe partly because I stopped reporting bugs). Most problems are more like the one in bugzilla:33479, where a bug reporter feels like he is experiencing hostility when really there may not be any hostility at all. From the point of view of a bug reporter, to spend much time testing and writing the report, only to have it marked invalid when it clearly is valid, is destined to be (mis)interpreted as an insult. Considering how dead the Bug Squad project is, I think WMF needs to decide either to make volunteer bug hunters a priority, or simply be satisfied with not having any volunteer bug hunters.

In the case of good bug reports being marked invalid - and that being the only status they are eligible for in some cases - constitutes full dismissal of a bug hunter's contributions. Really, it couldn't be any more completely dismissed, unless you want to give me a punch in the nose too. So, if you care about bug reports, something needs to be changed. A problem has been identified.

If you can't measure it, it isn't happening. I began with zero knowledge or experience with MediaWiki, extensions, PHP, JavaScript, etc. Many of my early bug reports were invalid, but by keeping score, I can gauge my progress in producing better bug reports, and becoming more familiar with the architecture of the code I'm studying. I'm exactly the kind of volunteer bug hunter you want to have, simply because I'm trying to improve. Developers can keep score of the bugs they've fixed, so why can't bug reporters do the same thing?

I wanted to start bug hunting again, but I had an unexpected very strong negative reaction to the idea, which is why I started this discussion. I don't have the energy to hunt the bugs, and get treated like a sack of manure too. I'm dissatisfied with my experiences from the current way of doing things, where bug hunters have no value, no importance, and no priority. But, it would be easy to fix with some policy formulations that would also serve to encourage good quality bug reports. It would be especially good if the policies are aimed at neutralizing a developer's natural tendency to feel insulted when a bug hunter triumphantly swaggers in to announce the difficult bug he found - that also happens to be the big bad developer's fault.

Once again, this is essentially a natural phenomenon that can sometimes lead to conflict, when it should lead to cooperation instead. There needs to be SOMETHING in place to shepherd the relationship between bug hunters and developers, and structure them in a way to prevent feelings of conflict. This is especially a problem for developers that answer to no one due to their dominance in some bit of software, like a MediaWiki extension. In other words, bug hunters need to be encouraged to feel pride in their accomplishments, without causing developers to feel like they're being accused or criticized. As it is, the bug hunter's victory is sometimes viewed as the developer's loss, in a zero-sum game.

You write "only to have it marked invalid when it clearly is valid". I disagree with this (or at least want to say that validity is something very subjective) - the bug was already fixed when it was reported and not existing anymore in the codebase at the moment of reporting it. I know that some bugtrackers use an ALREADYFIXED status for this, looks like this would have been the case here. Nobody stops bug reporters from keeping score, but everybody (also developers) can have interpret words and resolutions differently (if developer A wrote a patch to fix the problem but developer B calls it an ugly hack or workaround you can have the same conflicts about interpretation)...

"It would be especially good if the policies are aimed at neutralizing a developer's natural tendency to feel insulted when a bug hunter triumphantly swaggers in to announce the difficult bug he found" - where does this strong feeling come from? Any specific examples that "developers feel insulted by bug reports"? If you think that the Bugzilla etiquette misses something, please feel free to discuss on its talk page. Thanks!

Check out the scripts that Andre has developed!

These scripts include for example stuff like

• provide one-click stock comments,
• embed several links (to Extension product homepage; query tickets previously filed by the reporter)
• display email addresses of people and not just the name
• color people based on a manual list (e.g. green = "I know this person and don't need to look at this report")
• color MWExtensions based on a manual list (e.g. "green = deployed")

Thanks for the promotion! :) Your comment motivated me to clean up the code a bit and blog about it at http://blogs.gnome.org/aklapper/2013/08/23/bugzillatips-triage-helpertools-greasemonkey/

After the great bugday on Skin and page rendering issues yesterday, any preferences for the next bugday which will be about old and rotten bug reports? The list of ancient UsabilityInitiative issues feels a bit short (stuff would nowadays be WikiEditor, or Vector, or probably invalid for PrefSwitch and NavigableTOC) and that won't really help anybody. :) Also wondering about the vague stuff under "Wiktionary Tools" but I don't know the story behind either, plus will require something where a better place would be for these requests.

We could have a default for Old Bug weeks: list in a whiteboard the 50 oldest bugs that haven't got a single comment and are not Lowest, and go after them.

Not bad. More ideas. The [Drafts extension] contains some the oldest unanswered bug reports we have, although perhaps we could simply assign Lowest to all of them and be done with it.

Also fwiw, I got pretty interesting lists of bugs searching for "WhatLinksHere", scattered in different places.

Thanks, that's a really good idea (as usual), though I'd extend the amount of tickets (50 feels low, we triaged 86 this week, see mw:Bug management/Triage/20130402). Currently thinking of setting up Monday 20130418 for the next bugday (as start of the bug week) and keeping #wikimedia-office instead #wikimedia-dev (it went pretty well last week).

Drafts extension: I think valerie investigated the situation but I cannot remember the outcome whether "Drafts" is still under development at all. :( Valerie?

WhatLinksHere: Interesting. I'd put it under SpecialPages by default but if backend issues are only *shown* or triggered by that special page they might be correctly filed under e.g. File management.

Choose your preferred number. 100?

Drafts, it was developed by Trevor. Not working on it anymore.

Yeah, most of the Drafts bug reports were assigned to Trevor, and after confirming that Trevor was not working on the reports, I assigned them to Nobody.

I would add Lowest for all of them, if they don't have them already.

On a global priority level that's likely correct. Refering to bug reports under "Drafts" only, this would remove any kind of prioritization, so I wouldn't do it. See bug 40482 being the main blocker for bug 37992).

Fair enough.

Re "list in a whiteboard": Either that (by a whiteboard entry, if we want specific "bugday-YYYYMMDD" style), or reuse the existing "bugsmash" keyword (generic without a date) what once upon a time was meant for this and dormant (I just cleaned up all remaining reports with that keyword). Whiteboard might be less noisy than keyword, as we wouldn't have to remove the entry every time after the bugday to keep the list clean. On the other hand, if the "rotten bugs" query more or less stays the same (and hence the tickets for the next bugday), we could also use the keyword. Hmm, hmm. Too many options, as usual with Bugzilla. :)

I like the idea with "one comment only" a lot, and it's a good workaround for the "no comments except for the reporter" query that is broken in Bugzilla upstream code. I think I'd prefer to exclude enhancement requests (there's very often not much to comment on) and set it to 18 months, which would currently result in 138 tickets.

Proposing next Monday for the bugday - could be a nice start for the week. If we agree I (or anybody who is faster) will create mw:Bug management/Triage/20130415 soon and do all the rest listed on our Meeting preparations wikipage.

Ok, but let's offer a default list sorted by bug number, which reflects the real age of te reports.

Yeah, doing some queries it is evident that enhancement requests accumulate a lot of dust alone: 78 enhancements vs 23 bugs unanswered after 2 years or more. If you count 18 months or more the numbers are 331 requests vs 136 bugs... I think these links would be very useful for Product_development.

Here we go: https://www.mediawiki.org/wiki/Bug_management/Triage/20130415

I don't know if it is the best place to post an Annoying Little Bug opened 6 years ago about the image gallery not being to show a specific djvu page. As billinghurst suggested 3 years ago it would be a matter of supporting the "File:Book.djvu/5" syntax. Any volunteer to kill this bug?

In case you're looking for somebody to fix the bug report, Bugsquad does not write software patches, that's work for developers. :) You might want to list that ticket on https://www.mediawiki.org/wiki/Annoying_little_bugs ?

Thanks for letting me know! :) I added it to the list, hopefully someone will notice it!

I triaged the bug a bit.  :) Next time you can simply put Andre and/or me in CC in the bug report.

We have two bug days in April. One the Week of April 1st (fresh bugs) and the other in the week of April 15th (old bugs).

Reply here if you have any suggestions on topics for those bug days!

Maybe the Interface component? There's a lot of bugs there that need verifying (and often a WONTFIX or a priority bump), some with latest comments from 2006. BZ search link.

Valerie, good to see you planning events for April! ;) I have added the slots to Project:Calendar.

If we take MediaWiki - Interface restricting the search to reports that have received comments in the past 6 months we get 136 reports.

(Yes, I'm still trying to find the perfect algorithm to define what is a fresh bug). ;)

I support the "Interface" idea (skins etc), thanks Matma! So if there are no other quick objections we can set it up... Bugday testing instructions should probably mention appending "?useskin=foo" to a URL to make MediaWiki use the skin named "foo". Matma: Any other good tricks for testing that come to your mind?

Thanks for adding those dates! Matma Rex was the impetus for the thread creation, so thanks goes to Matma as well.

As proposed, the next week will be about Skin and page rendering issues. See https://www.mediawiki.org/wiki/Bug_management/Triage/20130402 for more information, and feel free to add yourself to the Attendees list!

See this write-up for more info.

I guess I never said Thanks for all the initial work on this, so:

Thanks a lot Mark!

I've picked it up and enhanced it a bit. Not yet there, but on the way.

Hi, now we have MediaWiki Groups and this WikiProject is a good candidate to become one. What do you think?

More: Talk:Groups#Deprecating_MediaWiki_WikiProjects.

I like the idea -- but I'm unclear on what is involved. I also realize I need to maybe begin to work on developing this more -- ideas welcome!

There are two aspects: the form and the content.

Changing the form of this WikiProject into a MediaWiki Group is simple. It can be as simple as a simple formality  :) with the benefit that once this MediaWiki Group is approved it will be officially recognized as a Wikimedia Group and will et the compatibility and potential benefits of any other official group e.g. possibility to request a budget to organize a face to face bugsquad sprint somewhere without even needing the WMF.

What really matters is the content, though. And here what we need to look is the best way to integrate all this content here with Bug management and related pages being maintained by Andre & co. Now it still feels like separate efforts when it should be just one.

The good news is that we are getting extra help from Valerie, who will work as full time intern during three months starting in January, as part of the Outreach Program for Women (and I hope she sticks around after that).  :) We have already started discussing about this MediaWiki group and other things that could be done.

... and right know I will point this discussion to both Valerie and Andre. Thank you Mark for your quick reply!

I started the creation of the Bug Squad Proposal Page (as the Group page specifies) and welcome any edits. I have not added the group proposal to the Proposal page yet.

I agree that content integration is important, and I'm willing and able to help once we get a better idea of what to do.

Thank you Valerie!

> I have not added the group proposal to the Proposal page yet.

Why not? The draft is solid enough and perhaps you will start drawing more attention there.

I wanted confirmation that this is the direction Andre and Mark want to go. I'll go ahead and add it, and, again, feedback and edits are welcome.

Threads that I missed... Sorry, on the watchlist now. :( I do support turning this WikiProject into a MediaWiki Group!

Bugs start out in the "Unprioritized" state. When a new bug comes in, if it is urgent, mark the priority to "Highest" and make sure someone who can fix it is available. Usually, this means finding someone in #mediawiki^connect know. Have a look at this bug to see what kind of difference making sure someone who can fix the bug has sprung into action in time.

This is a place to collect bugs for the API triage. I'll start:

• Borked API response has html DB error appended
• API returns invalid JSON despite HTTP status 200
• wikitech-l thread
• perhaps something here

Direct means to identify the proofread status of a page. All Wikisources. Extension:Proofread Page