MediaWiki 1.20 and the prospects for getting 1.21 code reviewed promptly: In late September, the Technology report published its findings about (particularly median) code review times. To the 23,900 changesets analysed the first time (the data for which has been updated), the Signpost added data from the 9,000 or so changesets contributed between September 17 and November 9 to a total of 93,000 reviews across 45,000 patchsets. Bots and self-reviews were also discarded, but reviews made by a different user in the form of a superseding patch were retained. Finally, users were categorised by hand according to whether they would be best regarded as staff or volunteers. The new analyses were consistent with the predictions of the previous analysis.
Code review statistics bounce back in October after difficult September
In late September, theTechnology reportpublished its findings about (particularly median) code review times. To the 23,900 changesets analysed the first time (the data for which has been updated), theSignpost added data from the 9,000 or so changesets contributed between September 17 and November 9 to a total of 93,000 reviews across 45,000 patchsets. Bots and self-reviews were also discarded, but reviews made by a different user in the form of a superseding patch were retained. Finally, users were categorised by hand according to whether they would be best regarded as staff or volunteers. The new analyses were consistent with the predictions of the previous analysis.
Our investigation found that September represented a particularly poor month for code review (across both extensions and "core" MediaWiki code) but that this loss was more than picked up in October, which was the best month on record for code review. Specifically, 50% of patchsets submitted during October were reviewed just two and a half hours after submission, and 75% within 18 hours. The 95% percentile remains stubbornly high at nearly two weeks, suggesting that finding reviewers for certain types of patch remains hard.
The staff–volunteer divide highlighted in the last report remains. The median patchset was reviewed twice as quickly if you were a staff member working on an extension in October rather than a volunteer, and although it is too early to tell conclusively, there seems to be a similar gap for contributors to "core" and/or WMF-deployed extensions. 44% of all-time first reviews come from five reviewers (all staff), though this figure is down from 55% at the time of the last report, suggesting a significant diversification in the last 7 weeks. On a positive note, the percentage of all-time first reviews coming from volunteers has also increased – from 14% to 25% – as the Foundation gives a large number of volunteers more reviewing power.
As with any statistics, these figures should be taken with a degree of caution. The full dataset is available upon request.
Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for several weeks.
MediaWiki 1.20 released: MediaWiki 1.20, the first release to external sites since May, was finalised this week (wikitech-l mailing list). Thanks to the decoupling of (now biweekly) WMF deployments and (six-monthly) external releases, Wikimedians will already be familiar with its contents, which include new diff colours, action=info pages and the newSpecial:MostInterwikis special page. Most WMF wikis, meanwhile, are currently on MediaWiki 1.21wmf3 and will receive wmf4 (which includes a change to the user toolbox dropping use of the word "my") shortly.
TimedMediaHandler goes live on all wikis: After a development spanning almost two years (seepreviousSignpost coverage), the TimedMediaHandler extension went live on Wikimedia Commons this week, having already gone live on other smaller wikis earlier in the week, meaning that it is now available on all Wikimedia wikis. The extension overhauls MediaWiki's video-handling capabilities, as was highlightedin a post on the Wikimedia blog and in several news articles.
Wikivoyage hosted on WMF servers: Starting from this week,wikivoyage.org and its subdomains (en, fr, and so on) are hosted on Wikimedia servers as part of the Foundation's central wiki cluster. Readers may in fact already be logged in to Wikivoyage as it is also now in the SUL auto-login list. Auser account migration plan is available; as detailed inpreviousSignpost coverage, much technical work is ongoing, including the import of images and support work for the aforementioned user migration.
Wikidata booming, but interface translations needed: As Wikidata.org, the central data repository currently functioning purely as an interwiki repository, has continued its rapid expansion, now documenting the interwiki links of some 50,000 articles (though its is not yet installed on any "client" wiki). WMF Language team member Amir Aharoni took the opportunity to appeal for interface translations for the project as its audience internationalises (Wikimedia blog).
Next week's poll is extremely subjective. All of the available answers (except "Other") rely on the assumption that lowest-priority bugs are worthless. I (and many other) strongly disagree. Lowest means in particular "Patches very welcome", and it is often a gathering point for motivated volunteers to write a patch and get an ACTUAL PROBLEM FIXED. Quite the contrary of "worthless". Please cancel this poll, as its results will necessarily be flawed and mis-used. Also: You write "This week saw a discussion [...]", so the least you could do is provide a link to said discussion. Previous polls were usually of high quality, so I am surprised by how obviously unethical this one is.Nicolas1981 (talk)03:25, 15 November 2012 (UTC)[reply]
The poll reads:
This week saw a discussion about the difference between giving something the "lowest" priority and suggesting it will never be fixed. Which of these best sums up your response: Dealing with bug requests is a case of...
...telling the truth, the whole truth and nothing but the truth, however brutal
...omitting "unhelpful" relevant facts, but never actually lying
...telling the odd white lie if it encourages future participation/engagement
Other / None of the above
Wow. That is just about the worst wording for a poll I have ever seen. It assumes that bugs are worked on in order of priority. That isn't even true where you pay the developers and it certainly isn't true when you have volunteers. Sometimes a lower priority bug is a very simple fix while the higher priority bug has you stumped. Sometimes you simply don't agree with whoever assigned the priorities. Sometimes someone else is working on the high priority task and you don't want to step on his toes.
But does the poll take any of this into account? Nope. It just assumes bad faith and decides that anyone who assigns a bug to the lowest priority must be a scheming liar and that only those who assign it a don't fix priority are honest and truthful.
While theSignpost's writing is generally quite good, several polls lately have been problematic. Perhaps you should run them by someone (perhaps a non-Signposter) for a) clarity, b) completeness, and c) objectivity before publishing them? --PhilosopherLet us reason together.16:19, 15 November 2012 (UTC)[reply]
While there is a subset of bug reports that end up as "lowest" priority or WONTFIX (my guess is less than 10%), I don't see the relation to "Dealing with bug requests is a case of" which refers to ALL bug reports. When it comes to the available answers, what is "telling the odd white lie" meant to describe for a valid and normal or even critical bug report? There simply is nothing to lie that my mind can come up with. "Thanks for reporting, valid issue, should be fixed, patches will speed it up", but where and how to lie here in a way that "encourages future participation"? I don't get it, or my imagination doesn't work well on Friday mornings. --Malyacko (talk)09:58, 16 November 2012 (UTC)[reply]
Some of these responses seem a bit harsh about the poll, but I do also tend to agree with you that lying does not encourage future participation. Being honest causes future participation because then people's time is not wasted. I could perhaps somewhat understand not wanting to mark a wontfix bug as wontfix simply because in some controversial issues the users will yell at you (StringFunctions anyone?), but that's not an excuse for not marking bugs how they need to be marked. Additionally I'm not sure where said discussion took place [but then again I haven't been following all technical discussion recently. There was one about RESOLVED LATER, but that's a tad different].Bawolff (talk)00:18, 17 November 2012 (UTC)[reply]
The second part of the question doesn't need to be related to the first and is not. The fist is only needed to pretend that the poll has some relation to news; the relation being that those discussions and changes had as a stated objective to communicate more clearly/truthfully the status of bugs. The proposed answers were not really problematic because they didn't affect the choice or understanding of what to do next (unless one used a lot of imagination), but they surely were not about what I consider to be the "dealing with bug requests" and I voted "Other" to represent it.[1][2][3] --Nemo08:20, 27 November 2012 (UTC)[reply]
Afterword: In the2012-11-19/Technology report,Jarry1250 announced: "In response to apt criticism of last week's poll title, I have decided to retire the polling feature until I can devote sufficient time to administering it properly." I'd like to take the opportunity to thank Jarry and theSignpost team for their ongoing hard work producing fresh and engaging reports each week and helping to bridge the gap between editors and techies. —Richardguk (talk)06:00, 22 November 2012 (UTC)[reply]
.png)
