Code Stewards are ultimately responsible for the development policies, support, and overall health of the code in question. Despite this responsibility, Code Stewards are not expected to do all the work themselves, instead they should engage with staff and volunteer technical contributors in the collaborative effort. As MediaWiki and its supporting services continue to grow and become further depended on by millions of users, it has become increasingly important that the holistic code-base remains healthy and enables the continued evolution of its capabilities.
As a Free and open source code base, MediaWiki and all its extensions, skins, services, and apps have many potential contributors including both paid (e.g., staff members of Wikimedia Foundation or Wikimedia Deutschland) and volunteer contributors. Code Stewardship provides the direction and guidance necessary to ensure all disparate projects have a similar level of code health.
Code Stewardship is a layer on top of the Developer/Maintainers list which defines some of the expectations associated with being a Code Steward. The Code Stewardship model was reviewed and ratified by the Wikimedia Foundation's Chief Product Officer (CPO) and Chief Technology Officer (CTO) in early 2018.
Code stewardship covers several different areas, included are:
Technical Community Engagement
Although much of what is included in Code Stewardship is focused on technical topics, a Code Steward is also in a great position to help foster a strong technical community for the code in question. A vibrant and engaged technical community is a key success factor for just about any component, extension, or service. To a large extent, areas such as code reviews and code health are directly related to building and supporting technical community engagement.
Reviews are a critical part of the development process, but can be one of the most challenging due to the dependence on others. It is not uncommon to find many patches waiting to be deployed that are being delayed due to a review bottleneck. This can be not only detrimental to the health of the code, but also frustrating for those trying to contribute.
Bugs (aka Defects), especially a lengthy backlog, can be seemingly insurmountable. Managing that backlog, ensuring timely resolutions, and applying lessons learned to future development are challenging at best without strong code stewardship.
Code Stewards are responsible for promoting established bug management policies (see Phabricator/Project management) as well as defining bug responsiveness SLOs.
Whether creating development policies, removing technical debt, or simply ensuring that a code base is easy to work with, it can be challenging to maintain high code health without Code Stewardship. Code Stewards play a critical role in ensuring that those that are contributing to the code are enabled to do so in ways that improve overall code health. Included here are coding standards, testing guidelines, and design patterns.
In order to be considered a Code Steward for a component, the person or group needs to commit to meet or exceed the Base Service Level Objectives and agree to be responsible for its overall code health.
Please refer to the Developers/Maintainers page for a listing of existing Code Stewards in addition to component level SLOs.
Base Service Level Objectives (SLO)
The definition of SLO help establish targets to measure progress. Although these are not intended to establish "contracts", they are intended to help drive an improvement in areas that are deemed as important by users and contributors of the Wikimedia Foundation projects.
The following SLOs are a starting point and may not be adopted by each component/extension/service. In those circumstances where the following SLOs are not adopted, the code steward for that component/extension/service is responsible for defining a more fitting set of SLOs and the rational for the departure.
|Code Review||1 day||3 days||7 days||14 days||14 days|
|Bug Fixed||7 days||14 days||30 days||NONE||NONE|
|Code Review||7 days||14 days||21 days||30 days||30 days|
|Bug Fixed||14 days||30 days||60 days||NONE||NONE|
Production vs Non-Production
Those components, extensions, and services that are deployed into the Wikimedia Foundation's production environment fall into the "Production" category. Whereas those that are used primarily in third party deployments are considered to be "Non-Production".