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 are experienced in MediaWiki administration and hacking, and want to keep the release process smooth for other third-party users.

Qualifications

 * 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.
 * All of our work is done in the open, under various open source licenses, and can be seen at:, , , , , ,
 * We are familiar with development practices using Git.
 * We have experience collaborating and communicating across multiple cultures and languages
 * Our team is diverse and comes from different backgrounds and geographic regions

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, 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.

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)

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.