Hi, thanks to the metrics reports now we know that the top bug fixers in November were Nobody (228) and Wikidata bugs (83)... followed by Michael Dale (28), Roan Kattouw (23), etc.
http://www.mediawiki.org/wiki/Community_metrics/November_2012#People
Even if the visible problem is a less accurate Bugzilla hall of fame, the actual problem is that a big bunch of developers don't notify when they are taking a bug. This decreases transparency and increases the chances of duplicated work.
This wouldn't be a big deal if it wouldn't happen to 55% of the bugs resolved as FIXED last month. In practice this means that you can't be really sure that a NEW bug is being fixed by someone while you are looking at it.
Can we solve this? Actual and potential contributors will be happier, and probably you as well. At the end we are talking about the practice of a small, very active group of (probably full time employed) developers. The solution is simply to click "take" and "assigned" when you start working with a bug.
See this report of November: http://bit.ly/TJZLWU
"Wikidata bugs" is focused in 5 components: WikidataRepo, WikidataClient, ContentHandler, Wikidata, OAI.
"Nobody" is all over but these are the top 10 components that could start fixing their practices:
* Semantic MediaWiki 23 * Wikimedia & MediaWiki General/Unknown 20 * Wikimedia Site requests 17 * MobileFrontend (Beta) 12 * MediaWiki Interface 10 * UploadWizard 10 * MobileFrontend 9 * MediaWiki Internationalization 8 * Wikimedia Bugzilla 8 * ArticleFeedbackv5 8
There's hope to see progress in the next Metrics report. :)
On Thu, Dec 6, 2012 at 7:07 PM, Quim Gil qgil@wikimedia.org wrote:
Hi, thanks to the metrics reports now we know that the top bug fixers in November were Nobody (228) and Wikidata bugs (83)... followed by Michael Dale (28), Roan Kattouw (23), etc.
http://www.mediawiki.org/wiki/Community_metrics/November_2012#People
Even if the visible problem is a less accurate Bugzilla hall of fame, the actual problem is that a big bunch of developers don't notify when they are taking a bug. This decreases transparency and increases the chances of duplicated work.
This wouldn't be a big deal if it wouldn't happen to 55% of the bugs resolved as FIXED last month. In practice this means that you can't be really sure that a NEW bug is being fixed by someone while you are looking at it.
Can we solve this? Actual and potential contributors will be happier, and probably you as well. At the end we are talking about the practice of a small, very active group of (probably full time employed) developers. The solution is simply to click "take" and "assigned" when you start working with a bug.
See this report of November: http://bit.ly/TJZLWU
"Wikidata bugs" is focused in 5 components: WikidataRepo, WikidataClient, ContentHandler, Wikidata, OAI.
"Nobody" is all over but these are the top 10 components that could start fixing their practices:
- Semantic MediaWiki 23
- Wikimedia & MediaWiki General/Unknown 20
- Wikimedia Site requests 17
- MobileFrontend (Beta) 12
- MediaWiki Interface 10
- UploadWizard 10
- MobileFrontend 9
- MediaWiki Internationalization 8
- Wikimedia Bugzilla 8
- ArticleFeedbackv5 8
There's hope to see progress in the next Metrics report. :)
For Wikidata at least we do set bugs to ASSIGNED most of the time. But we do leave the assignee set to the mailing list. If there is a strong preference to also change the assignee I can bring it up in the team.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata
Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
On Thu, 2012-12-06 at 10:07 -0800, Quim Gil wrote:
Hi, thanks to the metrics reports now we know that the top bug fixers in November were Nobody (228) and Wikidata bugs (83
Even if the visible problem is a less accurate Bugzilla hall of fame, the actual problem is that a big bunch of developers don't notify when they are taking a bug. This decreases transparency and increases the chances of duplicated work.
Setting the assignee field makes sense when working on something for a longer time so you don't duplicate work.
I don't see much advantage by setting an assignee for a quick fix (but it's easier now as you only need to click "take" below the "Assigned to" field and don't need to enter your email address manually anymore).
I consider Gerrit a way better place when it comes to creating statistics about bug *fixes* ("RESOLVED FIXED" in Bugzilla terms). Obviously I exclude any other Bugzilla resolutions here. :)
andre
Hello,
On Fri, Dec 7, 2012 at 11:56 AM, Andre Klapper aklapper@wikimedia.org wrote:
On Thu, 2012-12-06 at 10:07 -0800, Quim Gil wrote:
Hi, thanks to the metrics reports now we know that the top bug fixers in November were Nobody (228) and Wikidata bugs (83
Even if the visible problem is a less accurate Bugzilla hall of fame, the actual problem is that a big bunch of developers don't notify when they are taking a bug. This decreases transparency and increases the chances of duplicated work.
Setting the assignee field makes sense when working on something for a longer time so you don't duplicate work.
I don't see much advantage by setting an assignee for a quick fix (but it's easier now as you only need to click "take" below the "Assigned to" field and don't need to enter your email address manually anymore).
I consider Gerrit a way better place when it comes to creating statistics about bug *fixes* ("RESOLVED FIXED" in Bugzilla terms). Obviously I exclude any other Bugzilla resolutions here. :)
I've already been in a situation on Wikimedia where someone fixed a bug in the same time than me.
This bug qualified under "quick fix". I had set the assignee but were told this assignee field weren't really used.
Not to use this field is wrong, even for quick fixes. We never know what is short or not and this it's also more polite to let the bug submitter to know someone is taking care of the bug.
I would actively recommend we assign bugs to the code submitter each time we see a nobody bug.
On 12/07/2012 02:56 AM, Andre Klapper wrote:
On Thu, 2012-12-06 at 10:07 -0800, Quim Gil wrote:
Hi, thanks to the metrics reports now we know that the top bug fixers in November were Nobody (228) and Wikidata bugs (83
Even if the visible problem is a less accurate Bugzilla hall of fame, the actual problem is that a big bunch of developers don't notify when they are taking a bug. This decreases transparency and increases the chances of duplicated work.
Setting the assignee field makes sense when working on something for a longer time so you don't duplicate work.
I don't see much advantage by setting an assignee for a quick fix (but it's easier now as you only need to click "take" below the "Assigned to" field and don't need to enter your email address manually anymore).
Let's see. No mater how quick you fix is: isn't there a moment when you are sitting in front of the bug report to see what needs to be fixed? Or even if you manage to fix bugs by heart, isn't there a moment when you are in front of the bug report, resolving it as FIXED?
Anonymous developer: whenever you are in this situation, please click "take". It's extra 5 seconds at most. Thank you. :)
I consider Gerrit a way better place when it comes to creating statistics about bug *fixes* ("RESOLVED FIXED" in Bugzilla terms). Obviously I exclude any other Bugzilla resolutions here. :)
Not all bugs are related with Gerrit. But in any case: sure, where is the link to the data? I'll do my best adding that data to the metrics reports.
In the meantime, those Bugzilla links are the best data point I could get.
On Fri, Dec 7, 2012 at 12:54 PM, Quim Gil qgil@wikimedia.org wrote:
Let's see. No mater how quick you fix is: isn't there a moment when you are sitting in front of the bug report to see what needs to be fixed?
Well yes - but just because I know how to fix a bug in theory, doesn't mean I'm actually going to fix the bug :P
----
So hypothetical situation
*I'm bored one day and decide to fix a bug. For sake of argument lets say I'm not in an internet zone. *I go somewhere to get wifi. upload my patch to gerrit *I comment on bug that there's a patch in gerrit. I also assign the bug to myself.
In this situation I'm really unclear on what the point of taking the bug is. By the time I have the ability to mark the bug assigned, I've already done it. If someone happens to fix the bug in the intermediate time, while that happens sometimes. For a quick fix bug, I'm not going to be upset about it.
-bawolff
Ok, so this discussion can be summarized this way:
If assigning a bug to the developer that is working on it takes less than 5 extra seconds, please do it.
If it takes more than 5 extra seconds, don't bother.
Deal? :)
On Fri, Dec 7, 2012 at 6:19 PM, Quim Gil qgil@wikimedia.org wrote:
Ok, so this discussion can be summarized this way:
If assigning a bug to the developer that is working on it takes less than 5 extra seconds, please do it.
If it takes more than 5 extra seconds, don't bother.
Deal? :)
Deal ;-)
-- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata
Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
On Thu, Dec 6, 2012 at 10:07 AM, Quim Gil qgil@wikimedia.org wrote:
Hi, thanks to the metrics reports now we know that the top bug fixers in November were Nobody (228) and Wikidata bugs (83)... followed by Michael Dale (28), Roan Kattouw (23), etc.
http://www.mediawiki.org/wiki/Community_metrics/November_2012#People
Those statistics don't actually measure who fixes bugs, they measure who the fixed bugs were assigned to. Those aren't necessarily the same person (although I imagine this is rare), but the larger issue is that, as you say, most bugs have no human assignee. Another statistic that is used in the BZ reports sent to this list is who closed the bug (i.e. changed its status to RESOLVED FIXED), but this is also suboptimal. For instance, in the VisualEditor team, James somewhat frequently cleans up after developers who fix a bug but forget to close it, or even mention the bug in the commit summary, so he's probably the top bug "fixer" in VE by that metric, even though most of that is just him taking paperwork off our hands. Another problem is that bugs can bounce between REOPENED and FIXED multiple times, and can be set to FIXED by different people each time.
So both metrics are noisy, although I imagine the latter would not have a 50% signal-to-noise ratio like the former. Getting more accuracy would be complicated: you'd probably have to look for Gerrit links on the bug and identify their authors, or something like that.
Not saying the metric you used is wrong (it has advantages and disadvantages), but I do think it's a bit misleadingly labeled.
Roan
On 12/08/2012 08:25 PM, Roan Kattouw wrote:
On Thu, Dec 6, 2012 at 10:07 AM, Quim Gil qgil@wikimedia.org wrote:
Hi, thanks to the metrics reports now we know that the top bug fixers in November were Nobody (228) and Wikidata bugs (83)... followed by Michael Dale (28), Roan Kattouw (23), etc.
http://www.mediawiki.org/wiki/Community_metrics/November_2012#People
Those statistics don't actually measure who fixes bugs, they measure who the fixed bugs were assigned to. Those aren't necessarily the same person (although I imagine this is rare), but the larger issue is that, as you say, most bugs have no human assignee.
Yes, it's not perfect. However, I'm curious to see what happens after paying attention to this detail during this month. Maybe the next report will make more sense, maybe not. Maybe it will help improving a bit our processes or maybe not.
If the whole thing is pointless and more noisy than anything then I will just put it to rest. Like I did with the identification of "new contributors" based on who Ohloh thought that was new. Still, the exercise was useful for a few developers that claim their multiple identities in Ohloh. At least Jon Robson seemed to be very happy discovering the huge amount of Javascript lines of code he had contributed to several projects over time. :)
I'll keep doing my best this month assigning bugs to whoever seems to fix them, checking the gerrit commits when available. Thank you for your patience and collaboration. :)
wikitech-l@lists.wikimedia.org