This post by Qgil-WMF was moved on 2013-03-19. You can find it at Thread:Talk:Groups/Proposals/Bug Squad/How to evaluate Bug Days?.
Talk:Groups/Proposals/Bug Squad
As I asked in Git/Gerrit Bug Day Results message, has the time of the first two bug days (Tuesday 17:00 to 23:00 UTC) been a barrier for attendance?
I would also appreciate suggestions for an alternate time or day to hold bug days so that we may increase attendance.
Let's move it two hours earlier for the next bugday on Thursday, March 7th (plus have a Thursday): Bug management/Triage/20130307
Also, if the Bug "Day" page is available already at the beginning of the week then we can start promoting it and people can start with the work if they wish. Having a point during the week with all the focus is good, but we can also get a lot of work done by people in more DIY mode during the rest of the week.
Time to start the promotion for this Thursday I guess (blame me for already being late)... :-/
Announcement: http://lists.wikimedia.org/pipermail/wikitech-l/2013-March/067227.html - wondering whether to hit some microblogs and the English VillagePump. And shortly before starting with the bugday, some IRC channels of course.
I will promote Bug management/Triage/20130307 later today in social media, homepage, wikitech-ambassadors & Village pump of English Wikipedia. I will also send translation to Spanish & Catalan Village pumps, and you are encouraged to do it to the languages you manage.
Finally, I will collect the email addresses of the bug reporters affected and I will send them an email, as a test of targeted promotion.
Thanks, very appreciated!
I have been editing the page and doing other things, and now Asia and part of Europe is heading to bed. I will do it tomorrow morning. Except the mailing to bug reporters, I will work on this now.
Also, please sign up at the page. Thank you!
I won't be sending emails today either. We need to agree on the selection criteria of the reports first. Instead of blocker-normal AND immediate-normal, why not go for [https://bugzilla.wikimedia.org/buglist.cgi?list_id=184286&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&bug_severity=enhancement&resolution=---&chfieldto=Now&query_format=advanced&chfield=[Bug+creation]&chfieldfrom=6m&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=General%2FUnknown&product=MediaWiki everything created in the past 6 months]? 92 bugs by [https://bugzilla.wikimedia.org/report.cgi?x_axis_field=reporter&y_axis_field=&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&product=MediaWiki&component=General%2FUnknown&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&resolution=---&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&bug_severity=enhancement&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfield=[Bug+creation]&chfieldvalue=&chfieldfrom=6m&chfieldto=Now&j_top=AND&f1=noop&o1=noop&v1=&format=table&action=wrap 48 reporters], most with familiar names. Closer to the definition of fresh.
Good point ("fresh"), but the email to wikitech-l is already out, so let's have this for the next time if it still applies?
The email to wikitech and the wiki page text can stay as they are. We would change onoy the Bugzilla search query at the wiki page...
I think I have found the best URL for everybody. You can direct people to the priority/severity levels you think more appropriate. Still people looking at that page might find about the rest. I keep putting myself as an example, feeling more inclined to kick minor & enhancements, especially when not prioritized yet.
I will send the posting to the reporters of bugs within the scope you defined at the wikitech-l list though.
Is there a benefit in having an Etherpad for each Bug Day? Why not having a mpore established URL for the Bug Day etherpad?
One bug day etherpad makes sense. We archive all addressed bug day reports on that bug day's page, so we don't lose that information. If we encourage everyone to test reports throughout the week as well as on the bug day, we can just wait to archive the addressed bug reports at the end of the week.
Is there a reasons we would want to keep a list of reports we didn't address on the bug day? If there is a reason, that may lead us to having separate etherepads.
"so we don't lose that information" <--- This doesn't sound like an etherpad to me.
Why not just saving the content of the etherpad in the dedicated wiki page at the end of the day?
"Why not just saving the content of the etherpad in the dedicated wiki page at the end of the day?" <- Yes, that's what we do. Sorry, if I wasn't clear. I am agreeing that we can have an established URL for the bug day etherpad.
I'll explain what the process has been for the past two bug days. The etherpads I have created for the past two bug days are based on the months they were held, e.g. http://etherpad.wmflabs.org/pad/p/BugTriage-2013-01 and http://etherpad.wmflabs.org/pad/p/BugTriage-2013-02. I was following Bug Management's Meeting Preparations page. Before the bug day, Andre links all the bug reports from the query we are working from. The first bug day had ~170 reports and I can't find the number of initial reports for the second bug day. During the bug day we comment below each link about actions we took or questions we have about that report. The information we archive on the bug day pages are the reports that have comments under them, which we assume are the only 'addressed' reports, e.g First Bug Day's Page and Git/Gerrit Bug Day's Page.
I agree that we could have one Bug Day etherpad, since we save the reports we address on the event's bug day page.
Good point - We have to move the Etherpad content anyway to the wiki after the bugday in order to preserve it, so we could also flush the Etherpad and reuse it. Let me fix that right away...
According to Project:Calendar the next Bug Day is on Monday 18. We need to update that to... when? Thursday tends to be a busy day in Wikimedia Tech world since we have either Tech Talks or meetups. Wednesday?
I'd also like to create at least a placeholder for the next Fresh bug day on the first week of April.
Specifying the next bugday on LQT is done now, placeholder for April is not done yet.
I will be submitting this group proposal to the Affiliations Committee this Thursday, March 7, around 17:00 UTC. The group proposal submission process is detailed here: Groups - Submitting a Proposal. Please make any final edits to the proposal page before then. I also welcome any feedback. Thanks!
Oh awesome, thanks!
Sooo.... after thinking a lot and seeing how some user groups proposals are received by the AffCom, chapters, etc....
I think the best is to just decide ourselves in the MediaWiki context what we want to do with the Bug Squad. Being present as a group in face to face events or asking for grants are not priorities of this group. The projects are basically online and money doesn't pay much role, except for paying the people and the infrastructure that the WMF is already financing.
Personal conclusion: let's merge/update/rename Project:WikiProject Bug Squad, let's work in the way we were plannoing to wok anyway and let's forget about official recognition as Wikimedia User Group. I will find a way to connect this and other initiatives in similar situations under Groups, so people can find you through that route anyway.
Let's talk via Hangout on Tuesday, after our weekly meeting. Ok?
Sounds good!
Yes, let's do that!
Any ideas for offline activities? Possibility to organize bug squad activities aroound MediaWiki & Wikimedia events? Are there conferences or other tech events especially suitable for bug wranglers? If you don't specify this in the proposal the questions will likely come.
I've thought of this but no ideas for bug management offline activities, unfortunately. If you meant events for bug wranglers in general (not Wikimedia only): I'm not aware of any. Bugzilla (as one available bug management tool out there) itself is a Mozilla project but at Mozilla conferences it's nothing that receives much attention (one person came to my Bug management session at MozCamp 2011). The only bigger offline meetings/discussions on bug management with a number of free and open source software projects (using a variety of bug management tools, not Bugzilla only) I had was at Google Summer of Code Mentor Summit in the last years. I guess any MediaWiki/Wikimedia conferences could have dedicated sessions or meetings on Wikimedia bug management, if only enough members of our bugtriage community are around, however it would still require online access, as it sounds cumbersome to discuss a database and its tickets without being able to access it to check impressions or test ideas. :)
It would be interesting to know more about Bug Squad - why was created and why got stalled. That experience surely contains many good lesson for this proposed group.
I guess that Mark (hexmode) would be the best person to contact in order to find out.
I thought the Bug Wrangler would be a perfect promoter for this group. I hope he reconsiders. :)
I see. Sure, correct assumption, I just didn't really read up on groups so far. :)
The scope of the group is still unclear. Is there anything else apart from organizing Bug Days?
Currently the Bug Wrangler aka Andre Klapper holds lots of responsibilities. Will any of these responsibilities be shared, discussed and agreed upon within this group? Look for instance Groups/Proposals/Promotion, where actual promotion responsibilities are organized at a group level. At then end it might be the same people doing the same things (if nobody else volunteers) but even if that happens the aim is very different.
The Bug_Squad Project has an Activities page and Bug Management has an Activity Scope section.
Going through the Ubuntu-Bugsquad list there's a message that talks about 'adopting a package':
- Previously we used to have 'adopt a package' where someone or multiple
- people would adopt a certain package for triage and will take
- responsibility of moving bugs uptream and getting important bugs cherry
- picked to Ubuntu by indicating people in the desktop team or in some cases
- doing that themselves.
That could be an activity we do as well.
Oh, they also mention Operation Cleansweep
"Adopt an extension"?
Yes, that's what I was thinking. Triage Tasks mentions beginning with triaging a single application.
However, if someone (or some group) "adopted an extension", would a prospective bug triager be deterred from participating if that's an extension they wanted to work with? I wonder if that would be a problem at all.
This is a wiki community where anybody can edit. The same principle can be applied to bug reports. I hope the adoption doesn't deter anybody, although the devil is in the details and we need to pay attention to the wording.
Ok, can you then edit the page and add that information? The proposal needs to make sense on its own, without needing to check other pages. Thank you!
For what is worth:
There are no older topics