This is the last in my series of introductory posts about Wikimedia Platform Engineering, focusing on the MediaWiki Core group. This group is responsible for our sites’ stability, security, performance and architectural cleanliness. This ends up translating into a lot of code review, along with infrastructure projects like disk-backed object cache, heterogeneous deployment, continuous integration, and performance-related work. While it’s not a prerequisite, everyone on this team started off as a volunteer developer. The whole engineering organization has some level of responsibility for our code review process, but this group has more of a primary responsibility for it than most groups. We have an open position in this group.
The Wikimedia websites are the fifth most-visited set of websites on the Internet, and certainly the most-visited site that welcomes volunteer developers to write source code for. We have hundreds of paid and volunteer developers who have access to create and modify the code that Wikipedia and other Wikimedia websites run on. In addition to very liberal write access to the code, we are unique among open source projects in that we allow post-commit review, not pre-commit review; instead of checking people’s source code before they commit, we review their code after it’s entered our source control repository.
That creates a huge tension: while it’s obviously Wikipedia’s raison d’être that anyone can edit the content, how can we responsibly let volunteers edit the source code without reviewing it? Isn’t vandalism much harder to revert in code? Well, for starters, Wikipedia wouldn’t exist if “we” hadn’t embraced volunteer development, since the code was largely a volunteer effort for a very long time (and “we” is in quotes since that predates me and pretty much everyone at the Wikimedia Foundation). But we’re not entirely reckless. We generally review all code before we push it to the website.
Now that we have such a heavily-visited website, we have a responsibility to make sure that the site stays running while also making sure that volunteer (and paid) developers stay motivated by seeing their code deployed reasonably quickly after developing it. So, the whole engineering department chips in on code review, with the MediaWiki Core team being responsible for making sure that the job gets done in a timely fashion.
One way we hope to accelerate that work is by hiring a Software Security Engineer. We want whoever we hire to (almost) immediately dive in and start reviewing code. Security reviews are often quite scary, as the consequences of a mistake can be immediate and bad. We want this new engineer to be someone who naturally sees these things, and catch security flaws before they make it into production. We also want someone who can be a great teacher, and will help others understand the importance of writing secure code, and how to do it.
While code review is a really important function, it’s not the only function. This is first and foremost a development position. The majority of this developer’s time should be spent designing and developing new features and enhancing existing features of Wikimedia systems, with a particular focus on features requiring expertise in security (such as improved HTTPS support, better/different authentication features, and other handling of sensitive data). We want someone who can hold his or her own with the rest of the development staff in terms of coding productivity. We also want someone who is comfortable deploying their own code (as many of our developers do), and can help others perform that function.
As for the rest of the team, we have a great group this person will be working with. Tim Starling is the Lead Platform Architect, who is responsible for spearheading major performance initiatives, security investigation and repair, handling the thorniest code reviews, and generally providing technical leadership for the team. Sam Reed is responsible for managing issues with our web API, and handling requests for application tweaks on the live site (“shell bugs”). He also helps out with releases (for example, leading the 1.18 release) and code review. Chad Horohoe has been a part-time member of the team who has worked on release management and code review, and is now leading the migration from Subversion to Git. Aaron Schulz, who has been working on MediaWiki since 2007 as a volunteer developer and contract developer, joined us this year as a full time employee. Aaron’s first big project was finishing our Heterogeneous Deployment project and is now working with our Operations department on revamping our media storage infrastructure (see SwiftMedia). Antoine Musso is our “newest” team member, who actually has been involved in MediaWiki development since 2004, but recently started as a paid member of the team building out our continuous integration infrastructure.
If you’d like to join this team, please apply. If you know someone who would enjoy this work, please send them our way. Thanks!
Can you help us translate this article?
In order for this article to reach as many people as possible we would like your help. Can you translate this article to get the message out?
Start translation