We’re sitting here in Wikimania Underground, where our “hacking days” at Buenos Aires happen. Seeing each other face to face can allow us to discuss much faster how we should approach some of possible changes, that could make the site faster  for everyone.

We eliminated quite a few web response headers (which cannot be compressed, due to how HTTP works), especially some of large ones we are using inside the cluster to achieve better caching, or debugging information – causing few hundred megabit savings (it is difficult to know exact numbers, due to the nature of caching).

Also, we’re experimenting with trade offs in content compression – by choosing more expensive compression methods, we decrease size of transmitted pages by up to 15%, though doubling compression costs on our side. We still think that we may end up doing different levels of compression for different types of content (something what will be efficiently cached from anonymous users will have way higher relative wins).

Of course, we will have reduced bandwidth bills, probably more than the additional hardware to cover the change would cost us in resources.

Many folks do not know, but we actually try to upload and make available all our presentations.  Presently, you can see a list of them on our Wikitech wiki.  You can follow this link to see them all.

Keep checking back, because the conference isn’t finished!!

Yesterday’s tech talks from Wikimania are online at our temporary video file staging location (Ogg Theora format). They should appear on Commons soon. :)

Update: Some of the movies have encoding problems; reencoded versions should be reposted within a couple days. Sorry!

Hacking was cut short a bit on our first day at Wikimania yesterday due to troubles with the conference facility network :( but we did get a lot done:

• Some basic specs and programming interface for a configuration database have been hashed out — once implemented, this’ll give us infrastructure to start phasing out the more fragile parts of LocalSettings.php editing and making it much easier to manage both multi-wiki sites and one-off installs!
• Bunch of folks hashed out some details on getting our mapping servers set up and online
• Lots of general code review and poking!

Feel free to join us during the day — project page on Wikimania wiki and #wikimania-codeathon on IRC!

One of the wonderful characteristics of Wikimedia’s wikis, including Wikipedia, is that every change ever made to a page is recorded, back to the very first version (compare, for example, the first version of the article about chess with the most recent version of the same article). This characteristic also makes it possible to assign quality assessments to specific versions, thereby giving our readers greater transparency about the perceived current or past quality of an article.

A very powerful software feature called Flagged Revisions makes it possible to systematize such quality assessments.  It’s been in production use in many of our wikis for more than a year now, including the second-largest Wikipedia, the German language edition. Fundamentally it’s a very flexible feature, and different project communities (the German Wikipedia, the English Wikibooks, etc.) can come up with configurations that suit their needs. By means of our public issue tracker, they can then request from the Wikimedia Foundation that such configurations be turned on.

Even though we’ve made no official announcements about this, you may have seen media reports that Flagged Revisions will soon be enabled in the English Wikipedia. Indeed, there is a specific proposal that was developed by the English Wikipedia community, entitled Flagged protection and patrolled revisions. It’s a very thoughtful proposal that attempts to balance the desire for higher quality, and more systematic assessment thereof, with the immediacy of Wikipedia as it exists today, and was supported by a large majority of interested Wikipedia editors. The idea behind this proposal is to allow regular contributors to systematize a first, basic assessment of all edits by new contributors. However, this assessment will be purely for informational purposes to the reader: a reader will see whether or not the version of an article they look at has been patrolled, and if not, whether a prior patrolled version is available.

Only in a small percentage of cases, we would require changes to be patrolled before becoming the default view for readers. The proposal is to do so initially in the case of articles at high risk of vandalism, including high risk biographies of living people, where false information can do the most serious harm to an individual.

A popular media narrative of this proposal (in the cases where it has been reported roughly correctly to begin with) is that it represents a “clamping down” on Wikipedia’s open editing process. That is nonsense. It is presently the case that many high-risk articles are completely uneditable by new contributors, which is referred to as page protection. For example, as a completely new user, you are not able to alter the article about Barack Obama. These kinds of protections of high-risk articles have been common for many years now. If the proposed model works as intended, it will actually allow us to open up many articles for editing which are currently protected from being edited. Edits will have to be patrolled, which is clearly a step up from edits not being possible at all.

It is true that some implementations of Flagged Revisions are more conservative than that. Any edit in the German Wikipedia by a new or unregistered user has to be patrolled before becoming visible to readers. This is definitely not the case in the proposed English Wikipedia configuration. We believe in letting our communities experiment with different approaches in an attempt to find the right balance.

A test wiki for the English Wikipedia configuration has just been set up in the Wikimedia Labs, and we’ll be importing articles from Wikipedia soon and make a broad call for testing. It’s important for us to get this right – we want to make sure that we don’t make Wikipedia harder to use, for our readers or our editors, in the process of deploying this functionality. That said, we hope to be able to deploy Flagged Revisions in production use on the English Wikipedia within 2-3 months.

From Wikimania in lovely Buenos Aires,
Erik Moeller
Deputy Director, Wikimedia Foundation

[UPDATE 8/26] This post originally said that all biographies of living people would be “flagged protected”. This is not correct. The current proposal is for for articles that are currently under normal mechanisms of protection (where new and unregistered users cannot edit) to be eligible for the new protection model, which allows for more open editing. I apologize for the confusion; thanks to Sage Ross for the quick correction.

The fun is starting! Get your code on…

• Wikimania_Codeathon/Projects
• #wikimania-codeathon on irc.freenode.net

Wikimania starts this week!  Today we reminded everyone about this year’s Wikimania here in Buenos Aires.  Most of the staff and Board are here in the city, as well as hundreds of project volunteers and stakeholders.  The local organizing crew and Wikimedia Argentina are doing a great job.

Follow the events of the conference on twitter and identi.ca, and keep an eye on the Wikipedia Weekly podcasts.  Hopefully we’ll have time to blog about events as they unfold at Wikimania.

We also want to thank all of our sponsors this year.  Without them we couldn’t pull events like this together: Telefonica, Terra, Speedy, The Richard Lounsbery Foundation, Answers.com, Kaltura, Wikimedia Deutschland, The Government of the City of Buenos Aires, Open Society Institute, wikiHow, Wikia, and Banco Credicoop.  Thank you!

More as the event unfolds…

Jay Walsh, Communications

What happened?

A few highlights from the last week…

• The first version of Wikimedia’s official Wikipedia Mobile app for iPhone has hit the iTunes app store (free download). As with all Wikimedia software, it’s open source and we welcome patches and bug reports! (Unfortunately there’s a known problem with this release which prevents installation on first-gen iPod Touches — just use the mobile web site for now, which shares the same backend.)
• Test wikis with Flagged Revisions and ReaderFeedback configurations have been set up to shake down UI and workflow before we prepare to deploy these extensions on English Wikipedia in the coming weeks. The test sites have been populated with featured articles, and should be getting some decent front pages soon. ;)
• A push of new donation buttons to English Wikipedia to test response rates has been delayed until we’ve got more of our techs in one place again.
• Mark is completing performance testing of SSD-based Squid proxy servers.
• We encountered failures on ms2, one of our text storage servers, which has required some behind-the-scenes running about.
• Ariel and River are bringing media storage replication between our Tampa master and Amsterdam off-site copy back up to date after cleaning up most of the base configuration.
• There’s been a lot of talk on-list in the last couple weeks about testing infrastructure, with various people poking at the parser tests and the other half-done test suites. This is a happy thing and I hope to see more solid tests going — and more automated reports into CodeReview like the parser tests!

The week ahead…

Come with us if you want to code!

It’s Wikimania week in Buenos Aires, and the Wikimania Codeathon starts this Tuesday at 10am (15:00 UTC). If you can’t be there in person, join us online in #wikimania-codeathon on FreeNode.

What’s going to happen? We can’t say for sure ahead of time, but here’s a few of my favorites I hope to work on:

• Deploying updated MediaWiki code to Wikimedia sites!
• Exploring the power of jQuery and Michael Dale’s advanced media features in JS2 mode!
• Pushing LocalisationUpdate to fast-track the work of our tireless translators!
• Driving plans for the Usability Initiative’s new UI work!
• Bringing forth the power of Flagged Revisions!
• Awesome times with OpenStreetMap testing!
• Hashing out plans for a MediaWiki configuration database… down with LocalSettings.php once and for all!
• Figuring out how to start Selenium-based MediaWiki testing!
• …YOUR project?

Now put on yer codin’ legs and get typing!

Wikimania’s classic “Hacking Days” event is back, and better than ever as the Wikimania Codeathon will be open throughout the entire conference this year.

Based on the success of April’s Developer Meet-up in Berlin, we’re starting with an “unconference”-style planning session to let attendees break out into common working groups 10am Tuesday, August 25 (note — this is the day before the main conference begins). The coding room will remain open throughout the rest of the conference, so folks can pop in and out between other sessions.

We’ll be in Room F at the Centro Cultural, which should be nicely spacious. Non-developers are welcome during the conference if you just need a quiet place to sit and check on your sockpuppet accounts. ;)

There’ll be a wrap-up presentation in Room 3 at 14:00 Friday, August 28 to give folks a chance to do mini-talks on what they’ve been working on.

If you’re planning to attend, either in person or virtually via IRC, please add yourself to the list.

Fresh off the whiteboard of the Wikipedia Usability Initiative

Over 40,000 users are now participating in the beta testing of new features for Wikipedia, and other Wikimedia projects. These users have been helping the Wikipedia Usability Initiative to find bugs, of which we are doing our best to squash quickly.

If you are a Firefox 3 user, your experience with the new features has most likely been without issue, but we have found some older browsers such as Internet Explorer 6 to be less stable, especially for projects which use a right-to-left language. After collecting information on browser compatibility and evaluating each browser’s capabilities against the technologies we are using to achieve a better editing experience, we’ve designed a map of which browsers support the new editing tools well enough to ensure a quality user experience, and which do not. Where users’ browsers do not support the new editing tools the old editing tools are provided instead.

While we hope that we can extend support to some of the currently unsupported browsers, we are focusing our efforts on developing a richer browsing and editing experience for users of more modern browsers. Thank you to everyone who has been participated so far in our beta testing process!

– Trevor Parscal (trevor @ wikimedia.org)
Software Developer, Wikimedia Foundation