Bugs, Repairs, and Internal Operational News
Pageview counts inflated; CentralNotice blamed
About a week ago, significantly inflated pageview counts began to be noticed in Wikimedia's official statistics (for example, see Gerard Meijssen's blog post). Was it the result of some new technology directing users to WMF sites? Or just a technical glitch? Upon further investigation it (unfortunately) proved to be the latter, the result of requests to the new "Extension:CentralNotice" fundraising banner campaign. The statistics software was logging requests to
http://en.wikipedia.org/wiki/Special:BannerController as it would log requests to a "useful" page that should be logged, such as articles and some special pages. The current convention, it was discovered (since, as Rob Lanphier noted, it had not been documented anywhere) was that requests of the "pretty" format
/wiki/ would be counted, and that requests that ought not to be logged should use the alternative format
/w/index.php?title=. Discussion then centred on whether this was a sustainable format or not, with a number of alternatives proposed, but no agreement was reached on the wikitech-l mailing list.
How and when should new versions of MediaWiki be released?
As reported last week, there has been a lot of discussion about getting the MediaWiki software onto a more useful development cycle, both for WMF purposes (potentially very regular updates, but of potentially imperfect software) and for that of third parties (releases months apart but thoroughly checked for bugs). Staff developer Roan Kattouw outlined his plan for getting the development cycle back on track (wikitech-l mailing list):
- Catch up with the code review backlog (about 1,200 rev[ision]s currently). I expect this to be entirely uncontroversial, and this can be (and is being) done while we argue about the rest
- When trunk is fully reviewed and we feel it's probably stable, release 1.17.0beta1 and deploy it on Wikimedia
- Fix the numerous bugs that will inevitably rear their ugly heads when 8 months' (or more) worth of code is deployed [to WMF sites]
- Once deployment stabilizes... release and deploy that [to WMF sites].
- Repeat 2-4 until we feel comfortable releasing the currently deployed code as 1.17.0 [to third parties]
- From there on out, do weekly deployments [to WMF sites]
This week, Rob Lanphier opened a discussion on the topic in response to "a number of calls to make the release process more predictable (or maybe just faster)". In understanding how best that could, and whether it should, be implemented, he asked first whether contributors felt "release cadence" (shipping to a specified deadline, regardless of how many features actually got released) or a feature-dominated release (shipping X, Y and Z features however long it took to develop them) was preferable. For the former, should writers of features not ready at a given date be prepared to see them cut? For the latter, how far in advanced could the list of features be reliably drawn up? And how deep is the belief that deployment to WMF sites must precede a release to third parties?
The resulting discussion was wide-ranging. Why shouldn't a new version just be released when it would be useful to release one, rather than at a specific point, some asked. Ultimately, the sentiment that garnered most support was a strong "yes" to the last question, and that the best way to implement this would be to get back to having a very fast turnaround on deploying to WMF sites (the "weekly deployments" of Roan's post, if not faster; Flickr, as Neil Kandalgaonkar pointed out, often deploys multiple times a day). "Wikipedia", wrote volunteer Aryeh Gregor, "is a great place to test new features, and we're in a uniquely good position to do so, since we wrote the code and can very quickly fix any reported bugs."
Wikimedia tech staff, contractor developers, and volunteers gathered this past weekend in Tysons Corner, Virginia (in the Washington, D.C. area) for Hack-A-Ton DC. (TechBlog post) The focus was on fixing bugs and reducing the backlog of fixmes in code review, but there also was discussion of operations issues, and on moving forward in implementing some maps features. Naren Datha of Microsoft gave a demo of the WikiBhasha translation tool, and Jan Paul Posma demoed his student project, Sentence Level Editing. On Saturday evening, hackers joined DC-area Wikipedians for DC Meetup #12.
Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for many weeks.
is written by editors like you — join in!