Thread:Talk:Groups/Proposals/Bug Squad/How to evaluate Bug Days?/reply (5)

I wouldn't even sign the "ultimate goal is to get more people involved in bug triaging" statement. I'd say "ultimate goal is to get more people involved into MediaWiki, e.g. by starting via bug triage" instead, seeing the fluctuation in other FOSS projects' bugsquads.

"Getting more people contributing to Bug Days, ideally until reaching a point when none of us is really needed to run a successful new Bug Day." - Yes, and on the way there having more people co-organize and co-lead a bugday in order to cover more timezones. Counting bug day contributors is sometimes hard - e.g. two days ago Matma mentioned on IRC that he's sorry to not have joined the LQT triage, but that he triaged some Interface bug reports instead. :) I expect quite some up and downs in the number of people helping, depending on the project to triage, so hard to judge success. Needs time.

"Maybe Bugzilla stats can help finding out how many triagers do we have?" - Not sure how to do that. Naively assuming that RESOLVED FIXED is only used when an identifiable code commit has taken place and that WONTFIX is mostly used by developers who know the direction of their project better than triagers, you could check who has set other resolutions in Bugzilla lately, but that's extremely errorprone.

"organize Bug Days without much overhead organizing, promoting" - still need to improve where to announce and who to invite etc. Rule of thumb: If triaging a specific component, contact its developers (and probably its bug reporters, as Quim did for the last bug day), announce on #wikipedia, #mediawiki, wikitech-l etc., on the specific feedback / project talk page of the project to triage, calendars, and maybe also via microblogging if appropriate.