Project talk:WikiProject Bug Squad
| Home | Discussion | Participants | Activities | Barnstars |
 |
This is a place to share and brainstorm ideas specifically related to the Bug Squad and its activities. Please use the support desk for any MediaWiki software related help inquiries and the current issues noticeboard for discussing issues related to MediaWiki.org site. |
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| Topic proposals for "old bugs" triage week from Apr 15–Apr 21 | 15 | 17:42, 13 April 2013 |
| Bug Day Topics for April | 5 | 15:13, 28 March 2013 |
| How to triage | 1 | 17:43, 11 January 2013 |
| Convert this to a MediaWiki Group? | 6 | 17:42, 11 January 2013 |
| Marking priority | 0 | 17:33, 2 April 2012 |
| List of API Bugs for Triage | 1 | 01:39, 21 March 2012 |
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.
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.
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 ?
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.
Hi, now we have MediaWiki Groups and this WikiProject is a good candidate to become one. What do you think?
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.
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 #mediawikiconnect 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:
