Today the Ada Initiative announced the appointment of Sue Gardner, ED of the Wikimedia Foundation, to its first advisory board. The Ada Initiative launched just a few weeks ago, and has the aim of promoting the visibility and participation of women in open-source culture. The group, founded by Valerie Aurora and Mary Gardiner, will undertake unique research in the field of women in open-source culture, provide consultative services to organizations and businesses, and develop training and education services.

The Initiative‘s namesake, Countess Ada Lovelace (10 December 1815 – 27 November 1852), was considered one of the world’s first computer programmers, and was almost certainly the first woman in computer programming. She collaborated with Charles Babbage, the creator of one of the first mechanical computers, the analytical engine, writing what is generally considered the first code instructions for a computer.

From Wikipedia,

She was the only legitimate child of the poet Lord Byron (with Anne Isabella Milbanke), but had no relationship with her father, who died when she was nine. As a young adult she took an interest in mathematics, and in particular Babbage’s work on the analytical engine. Between 1842 and 1843 she translated an article by Italian mathematician Luigi Menabrea on the engine, which she supplemented with a set of notes of her own. These notes contain what is considered the first computer program—that is, an algorithm encoded for processing by a machine. Though Babbage’s engine was never built, Lovelace’s notes are important in the early history of computers. She also foresaw the capability of computers to go beyond mere calculating or number-crunching while others, including Babbage himself, focused only on these capabilities. [1]

Wikipedia has been in the news recently following a New York Times story highlighting the lack of women participating in the project, based on researched gathered by the United Nations University Study.  Interest in the topic has brought new thinkers to the Wikimedia community, which also recently resulted in the creation of a Wikimedia gender gap mailing list, which is open to the public.

Congratulations, Sue, and good luck to everyone involved in the Ada Initiative!

Jay Walsh, Communications

[1] Ada Lovelace. (2011, February 24). In Wikipedia, The Free Encyclopedia. Retrieved 18:03, February 24, 2011, from http://en.wikipedia.org/w/index.php?title=Ada_Lovelace&oldid=415671634

Wikimédia France recently announced a new partnership with the Palace of Versailles.

This partnership will be the third “Wikimedian residency” and the second time that a Wikimedian will work closely with a cultural institution of world-wide renown. French Wikipedian Benoît Evellin follows in the footsteps of Liam Wyatt who was the first Wikipedian in residence at the British Museum.  Benoît will spend six months at the Palace of Versailles to help produce and include cultural and scientific data on the Wikimedia projects.

The partnership originated at the GLAM-Wiki Paris event in early December 2010 where Adrienne Alix, president of Wikimédia France, met Laurent Gaveau, Deputy Director of Information and Communication of Versailles and started talking about possible ways to bring Versailles cultural riches to the Wikimedia Projects.

Benoît’s residency will focus on:

• Facilitating the exchange of best practice between the Wikimedia contributors and the teams of the Palace of Versailles, including researchers and scientists;
• Developing effective communication and distribution channels to broaden access to cultural and scientific content of the Palace of Versailles through Wikipédia in French, but also in all other languages, as well as through Wikimedia Commons with images and multimedia content;

Laurent Gaveau explains that, “Wikipedia is the second source of information in France on the Palace of Versailles, after the official website, it might even be the first abroad.”

This partnership follows other partnerships secured by Wikimédia France with similar institutions, including partnerships with the City of Toulouse, and the Bibliothèque Nationale de France, which have brought a wealth of high-quality material to Wikimedia Commons and Wikisource, but also a growing number of initiatives around the world with institutions working to make their information available to the general public through the Wikimedia Projects.

As Adrienne Alix puts it:

“This partnership with the Palace of Versailles confirms that something has changed between cultural institutions worldwide and Wikimedia: The World of Culture is starting to understand that criticizing by saying “Wikipedia is not complete” is not as constructive as working with Wikipedia to make it better. This is the result of tireless work from Wikimedians, and I am happy to see that the Wikimedia Projects are now seen by professionals as an essential conduit to the dissemination of culture.”

Delphine Ménard
Member, Wikimédia France

We have been running MediaWiki 1.17 on all Wikimedia wikis for almost a day now, and things seem to be in pretty good shape.  We still have a lot of issues to fix, including a problem with disabling the enhanced toolbar in prefs and some issues with categories (see below).  Many of the problems are around Javascript and replacing code that isn’t compatible with ResourceLoader. We have a migration guide for developers of gadgets and other MediaWiki customizations, which we encourage anyone who is having problems with gadgets to refer to.  Our developers are continuing to find and fix problems.

Based on early reports (albeit very subjective) ResourceLoader is already paying dividends, as navigating around the site seems much zippier in many cases.  We hope this is your experience as well.

We still have some deployment work left to do around this release.  In addition to the bugfixes, we also want to reintroduce the category improvements that Aryeh Gregor made last summer.  We had to temporarily remove these because they required schema changes that would make it difficult to do the type of deployment that we did.  Now that we’re confident we’re staying with MediaWiki 1.17, we should be able to deploy these improvements soon.  Some bugs with categories you see now may actually be related to this plan, so the good news is that those problems may be fixed by this coming update.  We also plan to update ArticleFeedback now that we’re on the newer codebase, and we’ll probably also update some other extensions, too.

If you are interested in the deployment, there’s much more below…

You may remember that last year, to close the Wikimedia annual fundraiser, Foundation staff and volunteers worked together to create the Wikipedia Contribution Campaign– a two-week long initiative to encourage people all over the world to become new editors.  Throughout the past few months, volunteers have continued to work together, creating the Wikipedia Contribution Team, to continue to drive the good work being done. Since January 2011, the Contribution Team has grown from 10 participants to 40, recently taking on projects such as the Backlog Drive – a project focused, six-week project to reduce the backlogs on Wikipedia, as well as in-person outreach to help encourage people to become new editors.

Supported by the Wikimedia UK chapter, the Wikipedia Contribution Team has planned a number of great events throughout the UK to support outreach and encourage people to join the Wikimedia movement. Throughout the next few months, the Team will support Wikipedia education and editor recruitment at several UK colleges and universities, including the Imperial College of London, University of Sheffield and University of Leeds.

No matter where you are in the world or how you like to work (online or IRL) there are a number of ways you can get involved to help educate people everywhere about the importance of working as a Wikimedia volunteer and how to encourage others to join!

If you’d like to join the Contribution Team, it’s as simple as signing up.

Good luck to everyone involved; we look forward to hearing more about
your successes!

Moka Pantages, Communications

Continuing with the work started last week, we plan to deploy 1.17 to more wikis in a couple hours (Wednesday, February 16 at 6:00 UTC for 6 hours).  We had hoped we would be able to figure out the performance issues in the past week, but unfortunately, the only practical way we have to see the load problems we witnessed last week is to put the software into production.  We have put a lot of instrumentation in place to help us diagnose our load issues.  We plan to start the upcoming deployment by rolling out to nl.wikipedia.org, and do some debugging (rolling back if necessary).  If we’re able to diagnose and fix the problems quickly, we then plan to roll out 1.17 more widely.  If we’re still stumped, we may still roll out to a few more low-traffic wikis, but leave the high-traffic sites until we figure this out.

We plan to have more updates and detailed information on the deployment page on mediawiki.org.  Thanks for your patience!

Update (2011-02-16 6:45 UTC): We’ve started the deploy, and it’s going better than we hoped.  We’ve deployed to several wikis now, including nl.wikipedia.org, de.wikipedia.org, fr.wikipedia.org, and ja.wikipedia.org.  More detailed updates will happen on the deployment page on mediawiki.org.

Update  (2011-02-16 12:39 UTC) – We have now pushed 1.17 to all wikis, and the deployment window is closed. Please see deployment page on mediawiki.org for the best way to report any problems you might encounter.

Jorge Sierra ([[User:Lucien leGrey]]), Chapter President, Wikimedia España.

As covered on this blog this week, we had a few problems with our initial deployment of 1.17 to the Wikimedia cluster of servers.  We’ve investigated the problems, and believe we have fixed many of the issues.  Some of the unsolved issues are complicated enough that the only timely and reasonable way to investigate them is to deploy and react, so we’ve come up with a plan that lets us do it in a safe way by deploying on just a few wikis at a time (as opposed to all at once, as we tried earlier).

We’re scheduling two deployment windows:

• First window – This wave will be deployed between Friday, February 11, 6:00 UTC – 12:00 UTC (10pm PST Thursday, February 10 in San Francisco).  This first wave will be to a limited set of wikis (see below).
• Second window – Wednesday February 16 (between 6:00 UTC – 12:00 UTC) – full deployment (tentative)

Repeating what is new about 1.17:  There are many, many little fixes and improvements (see the draft release notes for an exhaustive list), as well as one larger improvement: Resource Loader.  Read more in the previous 1.17 deployment announcement.

Update (2011-02-11, 8:00 UTC) – we’ve deployed to a few of the wikis now (see below for updates on which ones).  We uncovered a couple issues we were able to fix, and plan to keep going.

Update (2011-02-11, 9:07 UTC) – we added he.wikisource.org to the list due to community member request, and so we’d have a right-to-left language wiki in the mix.  Thank you he.wikisource community!  We’ve now deployed 1.17 to meta.wikimedia.org and he.wikisource.org.

Update (2011-02-11, 10:26 UTC) – we deployed to our last six wikis, and then backed off of nl.wikipedia.org and eo.wikipedia.org once we saw some issues with ParserFunctions.  We’re investigating those, and will probably try again before this window is complete.

Final update (2011-02-11, 12:28 UTC) – we found and fixed some localization problems that triggered ParserFunction bugs on both nl.wikipedia.org and eo.wikipedia.org.  However, the traffic from nl.wikipedia.org was enough to cause a very noticeable spike in the CPU usage on the web servers, as well as timeout errors in our logs.  We have profiling turned on for the list of wikis we’ve deployed to, and will use the time between now and our next deployment window to find and fix problems.

(more…)

Earlier today we announced our selection of Watchmouse website monitoring to assist both the Foundation and anyone around the world in keeping an eye on our server uptime and status.  With Watchmouse’s help, the Foundation now has a public status page, which is maintained offsite on servers independent from Wikimedia, that reports our uptime and accessibility levels from over 50 locations around the world. The service breaks out each of the primary server systems of the Foundation, because it definitely takes more than one computer to keep us up and running.

This is the first time Wikimedia has offered a publicly visible, externally hosted website monitoring service. Uptime is of course critical for reaching all of Wikimedia’s users, but also for ensuring that our wikis are open and editable to everyone, all the time.

With a rapidly growing, and global, audience of hundreds of millions of readers and contributors, Wikimedia’s properties have become an integral part of how the world accesses and shares knowledge.  This new service is particularly important as the Foundation establishes its permanent data center infrastructure, and looks beyond the US and Europe to establish more data centers (more regular updates from our engineering team can be found on the Wikimedia tech blog). Publicly sharing where downtime (and uptime, of course) is being experienced also helps us maintain our mission focus on transparency and accessibility.

Thanks for joining us as mission supporters, Watchmouse!

Jay Walsh, Communications

We’ve received many complaints about strange behavior on various wikis we host starting last night. These problems were directly related to an attempted deployment.

A bit of background about the 1.17 release:

• In Oct 2010 we committed to more frequent releases in response to community requests.
• Simultaneously, we committed to cutting through the backlog of code review requests from the community. As of this writing, the Code Review Team we formed has reduced the backlog of over 1400 un-reviewed core revisions down to zero in the 1.17 branch, as well as dispatching roughly 4000 other revisions in extensions (figuring out which ones we needed to review, and reviewing the important revisions there, too).
• 1.17 was an omnibus collection of fixes, including a large number of patches which had been waiting for review for a long time. The Foundation’s big contribution to the release was the ResourceLoader, a piece of MediaWiki infrastructure that allows for on-demand loading of JavaScript. Many other incremental improvements were made in how MediaWiki parses and caches pages and page fragments.

As is our usual practice, we review all code before trying to deploy it This practice has generally been good enough in the past that we have been able to quickly address anything we don’t catch in review within the first few minutes of deployment. The 1.17 release process has been longer than we would have liked, which has meant more code to review, and more likelihood for accumulating a critical mass of problems that would cause us to abort a deployment.

Our preparation for deployment uncovered a few issues, including a schema change, an update to the latest version of the diff utility and various other small issues which were discovered during the initial deployment to test.wikipedia.org. Pushing to test.wikipedia.org turns out to have been hugely useful, and in future we will take it as a lesson learned that any large deployment must successfully deploy to test.wikipedia.org at least 24 hours prior to general deployment.

When we finally deployed last night, our Apaches started complaining pretty much immediately. We rolled back to the previous version, worked on debugging and thought we had a suitable fix. We attempted deployment again but found the same issue very quickly. What we discovered was that our cache miss rate went from roughly 22% with the old version of the software (1.16) to about 45% with 1.17. The higher miss rate increased the load on our Apaches to the point where they couldn’t keep up, at which point they start behaving unpredictably. This can cause cascading failures (for example, caching bad data served by overloaded Apaches), and can result in strange layout problems and other issues that many people witnessed today.

By the way, whenever we do a large deployment, a number of WMF staff and community developers meet online to work through any issues that might arise. We schedule deployments late at night in the US to take advantage of lulls in request traffic, so everybody is working late. By the second failure, these people had been awake for many hours and we started to be concerned about their ability to work efficiently on little sleep, so I vetoed further attempts at deployment today.

We are currently combing the logs for further clues about how to mitigate risks of a similar outcome when we next attempt to deploy 1.17, which most likely won’t happen until later this week (at the earliest). We’re are also closely investigating the check-ins related to parsing and caching, and evaluating our profiling data. We plan to regroup tomorrow, decide how confident we are in the fixes we are able to implement in the past 24 hours, and make a decision as to when we should target to deploy.