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.
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):
| “ |
|
” |
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.
Discuss this story
Just for the record, a slideshow gadget has been available for quite some time. The new extension replaced the old one and users with the extension activated should have a seamless transition. --Waldir talk 08:06, 26 October 2010 (UTC)[reply]