Release Management RFP/2013/EIJL

Introduction

Our team is composed of Benjamin Lees (User:Emufarmers), Jack Phoenix, Kim Schoonover (User:Isarra), and Kunal Mehta (User:Legoktm). We all are system administrators of third-party MediaWiki installations and hence we know the challenges and pain points that MediaWiki release process has and we have a clear focus on how to address those and improve the release process to make it even better for the end-users.

Introducing the Team

We are all familiar faces in the MediaWiki community, having provided core and extension patches, commented on mailing lists, and interacted in various IRC channels. Our core values include openness, transparency, reliability and responsiveness.

Benjamin Lees (Emufarmers)

Benjamin Lees is the maintainer of the technical infrastructure of various wiki sites, which include WikiIndex, among others.

He has helped various MediaWiki end users via the support desk on MediaWiki.org, the MediaWiki-l mailing list, the #MediaWiki IRC channel and the unofficial MWUsers.com support forum.

Benjamin is also the main author of the QuestyCaptcha extension, which has proved to be an effective way of combating spam on MediaWiki installations.

You can view his SVN commits or git (gerrit) commits.

Jack Phoenix

Jack Phoenix has been a MediaWiki developer since 2008 and he is currently the main developer of social tools. Jack has considerable experience with wiki hosting and administration with MediaWiki, as he's the co-founder and the Head of Customer Support Team at ShoutWiki and one of ShoutWiki's primary software developers.

One of his particular interests is making MediaWiki more friendly towards third-party users, such as Wikia, wikiHow and others, and getting these parties to contribute more of their creations back to MediaWiki. He has been instrumental in open-sourcing the codebase of ArmchairGM, which is where the social tools were originally developed, as well as getting wikiHow to publish more regular source code dumps and Wikia to publish the entirety of their codebase under a free and open source license.

Being a native of Finland, he has provided many Finnish translations to various MediaWiki extensions as well as the core software itself. He prefers licensing his original work into the public domain where possible for greater flexibility and possibilities for reusing.

Jack speaks fluent Finnish and English, some French and Swedish.

You can view Jack's SVN commits or learn more about the tools developed by Jack Phoenix.

Kim Schoonover (Isarra)

Kim Schoonover is experienced with User Experience (UX) development and delivering the best possible experience to the end-user. She participated in the Free and Open Source Outreach Program for Women (OPW) in spring 2013.

She is also an administrator on Uncyclopedia, the free humor encyclopedia, which moved to independency in early 2013. This was made possible by the MediaWikiAuth extension, to which Kim contributed significant code parts, as well as the set of free and open source wiki grabber scripts, which also heavily feature Kim's handiwork.

Learn more about her MediaWiki contributions here.

Kunal Mehta (Legoktm)

Kunal Mehta is an administrator on the English Wikipedia, Wikidata and an experienced Python developer and pywikipediabot contributor. He is also one of Uncyclopedia's system administrators.

He is experienced with assisting users with technical questions about templates, bots, MediaWiki, and anything in between; through IRC rooms like #wikipedia-en-help and #wikimedia-tech, OTRS tickets to the info-en queue, and on-wiki pages like w:WP:Village pump (technical) and d:WD:Project chat.

Learn more about Kunal's contributions to MediaWiki or his other FLOSS contributions on GitHub.

Questions

• Please describe your experience doing public software releases.

Our team members have maintained various MediaWiki extensions (MediaWikiAuth, QuestyCaptcha, and more); bot frameworks; and social tools, while ensuring that they remained up to date amidst core changes. Our team members are experienced in maintaining stable MediaWiki sites and understand the process to ensure that releases are stable.

• What, in your opinion, are the current bottlenecks/friction points in the MediaWiki release process? How would you address them?

The largest friction point in the MediaWiki release process is ensuring that extensions do not break due to core changes that the maintainer was not aware of. We would address this with clear communication with extension developers during the development process ensuring they have enough time to make the necessary changes, as well as encouraging unit testing and regular testing of extensions with the latest version of MediaWiki core.

• Please describe your general plan for how you would manage the release.

First, ensure that all critical/blocker bugs have been fixed and have backports if necessary. Then we would review the list of bugs in Bugzilla that were set to that milestone, and ensure that all the necessary patches were backported. At that point a release candidate would go out. If no regression failures are found, we would release it officially.

For security releases, we would ensure the patch can be backported to all supported versions, and then release them all together.

All releases would be composed of:

• a tarball release hosted on download.wikimedia.org
• A page on MediaWiki.org describing the major changes, including what users, administrators, and extension developers should expect with links to relevant Bugzilla bugs and gerrit changesets
• An email containing links to the above sent to all the major mailing lists (mediawiki-l, mediawiki-announce, mediawiki-distributors, mediawiki-enterprise and wikitech-l)

• Relatedly, the two releases per year cycle is expected and normal for our community. At the same time, there may be reasons you have to make it different; please explain.

We believe this system works well and will continue using it. Based on [1], we expect to release around 7 security releases per year.

• The Wikimedia Foundation anticipates providing support for this work for the foreseeable future. However, we can't guarantee that we will always be able to fund this. Additionally, the MediaWiki community would benefit from a more diverse set of benefactors for MediaWiki maintenance. What steps will you take to ensure this is a financially sustainable activity, even in the absence of support from the WMF?

For the first 3-4 months, our focus will be on releasing versions of MediaWiki per the schedule. After that time period we will have a better idea of the scope of the work as well as the requirements to function as an organization. Around 4-6 months timeframe we will fundraise, asking for grants and donations. In the unfortunate situation that we are unable to raise the required funding to function, we will notify the Wikimedia Foundation 60 days prior to the ending of the contract.

Dependencies on WMF

• Access to upload tarballs and other files to download.wikimedia.org
• Access to security bugs to be prepared for sending out security releases.
• Posting ability to mediawiki-announce for new releases

Finances

• Budget:
  • $2,000 up front for incorporation and other startup costs
  • A monthly fee of $4,000 which will be split amongst the four team members equally ($1,000)
  • Total: $50,000
• According to User:Greg (WMF), we will need to set up a corporation or other entity to handle payment processing since the WMF will pay one entity. If we win the bid, we will incorporate.
  • Or another option might be that you all have a contract between yourselves that stipulates that you will receive money via one person and that person will disseminate it equally. Just a thought. Greg (WMF) (talk) 16:34, 13 June 2013 (UTC)

Team member roles

These are the basic roles we've split up into:

• Communication, organization and business-related tasks
• Extension compatibility verification and testing-related tasks
• Release preparation and testing-related tasks
• Release distribution-related tasks

Endorsements

• I've interacted and worked together (as a volunteer) with some of the folks doing this proposal, and they are rather awesome/nice/competent people :) Yuvipanda (talk) 06:57, 13 June 2013 (UTC)
• Competent and helpful people, certainly experienced in running MediaWiki wikis and knowledgeable of the issues one encounters when running MW outside the WMF. Matma Rex (talk) 13:36, 14 June 2013 (UTC)
• I know from personal experience that skinning, general backend maintenance, and upgrade paths are all competencies of this team. This serves as a good core to start with as they build the ability to deal with the mess of extensions that are present. I perceive a slight lack of organization on the part of this team -- but I also believe they would be able to develop into a great approachable maintainer team. Mwalker (WMF) (talk) 01:41, 27 June 2013 (UTC) (not officially speaking as part of the WMF, but this is the account people know me under.)

Contact

• If you have any questions about our proposal, you can leave a note on the talk page. We're more than happy to discuss any questions or concerns you might have.