Wikimedia Production/Service Catalog/FAQ

Preamble

Some software is primarily developed by Wikimedia Foundation staff, and the WMF is responsible for continuing to take care of that software.

Other software is primarily developed by the volunteer community, but runs in WMF production systems. In that case, the WMF doesn’t handle feature development, but takes a contingency responsibility for time-sensitive work (like handling production emergencies, security vulnerabilities, and codebase-wide initiatives) in the event volunteers aren't able to complete it.

The WMF is already committed to doing this work, but we need to make sure we know which staff members will do it. Given that, for volunteer-developed services, “ownership” here doesn’t mean that the Wikimedia Foundation plans to take away control from current developers. It also doesn’t mean that the Foundation is committing to feature development of those repositories.

Please skim / read the Ownership Roles and Responsibilities doc as well since that is referenced below.

FAQ

Here are a few questions we have encountered in our conversations and discussion over the two years of operation of the code ownership working group. Questions specific to a particular artefact (service catalog, ownership roles and responsibilities) are part of that document itself and aren’t included here. We have split the questions into two sections based on who might be more interested in that question and its answer.

Volunteer-centric questions

1. Who is part of the Code Ownership Working Group?
   • This group's membership has changed in the course of its work and in April 2026 (when this document was first published), the working group included:
     • Kavitha Appakayala, Director of Site Reliability Engineering
     • Kirsten Stoller, Senior Product Manager
     • Ilan Berker, Director of Engineering, MediaWiki
     • Mark Bergsma, Vice President, Site Reliability Engineering
     • Marzanne Collins, Director, Program Management
     • Max Binder, Lead Technical Program Manager
     • Reuven Lazarus, Staff Site Reliability Engineer
     • Scott Bassett, Staff Application Security Engineer
     • Subbu Sastry, Principal Software Engineer, MediaWiki
2. What impacts does this work have on volunteer developers - specifically, will this lead to a loss of agency for them?
   • We don’t expect it to. Most of the work done here largely pertains to the internal operations and accountabilities of WMF and this should not have any major implications on what volunteers can or cannot do.
   • That said, the primary sticking point might be around the idea that service owners are WMF teams, not individuals, and not volunteers. A number of code repositories in production are either volunteer-initiated or led, but this isn’t about taking over development. This is about supporting volunteers’ work if they are unable to deal with an issue which has arisen, to keep the service working.
   • The goal of this work is primarily around production infrastructure accountabilities. Volunteers make important contributions, even time-critical ones in production incidents, but we cannot expect volunteers to have specific time commitments or be always available when needed. The aim of establishing WMF team ownership for even volunteer-initiated and volunteer-led services is to ensure someone within WMF can respond to production incidents. Ideally, such a team would maintain a working relationship with the associated volunteers to be able to enlist their help as needed to respond to such incidents. So, this is not so much an attempt to remove agency from volunteers as it is to build internal organizational clarity around incident responses (contact team X who can either address the issue OR work with volunteer V to do so).
   • This dynamic is recognized in the Roles & Responsibilities doc where the WMF team can only be a contingency development owner for volunteer owned repositories.
3. As a volunteer, I have maintained this service for a decade. How am I not the owner?
   • Note that the Ownership Roles & Responsibilities framework does not assign a WMF team as a development owner. It only assigns a contingency development owner within the Wikimedia Foundation to step in when needed. This is in recognition of both
     • this is a volunteer maintained service.
     • the volunteer cannot be expected to be available and responsible to deal with incidents which need to be dealt with urgently.
   • The Wikimedia Foundation does not take over any responsibility for feature development. This is merely to make sure that if the Foundation needs to step in to keep an important service functional, we know which team will do so.
4. Why are we creating a Service Catalog instead of using / adapting the Maintainers wiki page?
   • The proposed Service Catalog schema aims to capture information according to the framework proposed in the Ownership Rights & Responsibilities doc (services can be in different lifecycle stages; ownership roles vary by service lifecycle stage; service ownership involves multiple teams meeting these different roles) which doesn’t currently match how Maintainers page is maintained. So, at the very least, if we want to (re)use the Maintainers page for this purpose, that page will need to be significantly updated. But, it might be simpler to just keep the two separate since they each have different sets of information on them.
   • For the service catalog to be useful and authoritative, updates to it will have to be part of organizational (planning and management) processes. Given the negotiations and conversations involved in some of these processes before they are finalized which cannot always be internet-public, there may be transition periods where WMF may work off of an internal copy of the catalog.
   • While the service catalog wiki page will be publicly editable, given that the Service Catalog is primarily about recording internal WMF accountabilities, edits to the page by non-staff is likely going to be more limited - much in the same way that edits to team pages (documenting membership, roles, and management) are going to be limited. These edits are going to be limited to volunteer-maintained services and to fields recording individual volunteer maintainers, where such information might be useful.
   • All that said, given that the Maintainers page has a lot of useful information today, we aim to leverage as much of that information as possible in creating the first version of the service catalog. But, once it is established and finalized, we expect the Maintainers page might be eventually archived.
5. The WMF cannot keep its own ownership straight and has a bunch of production code that has no real owners. So, why be hypocritical and block deployment of new volunteer extensions without having WMF owners associated with them?
   • See this comment & Bryan’s response after. Bryan’s response covers it well. The work we are also doing as part of this ownership group is to address some of these long-standing issues and that is precisely the reason not to make the problem worse by adding more unowned code to the pile.

Staff-centric questions

1. We’ve tried this before, why do we think it’s going to work this time?
   • Here are a few reasons:
     • There is management support for this in the form of being part of Annual Planning. We have a decision brief that has been signed off by the CPTO.
     • This work is tied to other outcomes and goals that we are invested in (ex: SLOs).
     • There is a cross-team, cross-discipline group of people engaged in this work (core + extended) consistently with gradual progress.
     • This work is structured, has a framework, and is detailed - the very existence of this FAQ should hopefully be an indicator of the thought and work that has gone into providing clarity to ensure we can collectively make this work.
     • We also think some of the ideas we're baking into the foundations of the model (that everything has more than one kind of owner; that ownership persists through the software lifecycle and through changes in the org) make it more sustainable in the real world.
2. Will this all be public?
   • YES. Most of the work done so far largely pertains to the internal operations and accountabilities of WMF and as such, all our early efforts focused on working through the details and getting alignment internally on these. But, the intention has always been to publish these on wiki and incorporate relevant volunteer feedback as appropriate.
3. Will this lead to a lot of bureaucracy/paperwork/overhead?
   • We definitely hope not. Most work should continue as before without unnecessary paperwork. The only additional bookkeeping we anticipate is ensuring service catalog entries continue to be updated as part of planning processes (ex: change in service status) and reorgs (ex: change in service ownership roles).
4. How are we assigning owners?
   • Assigning ownership for unowned services is explicitly out of scope for the working group. But, it is our goal to provide a framework for addressing this problem with:
     1. some core ideas around ownership (ex: teams own code, not individuals),
     2. different ownership roles (ex: development, contingency),
     3. different service types (ex: active, maintenance),
     4. documentation of what it means for a team to own a service.
   • Separately, the framework also recommends doing an inventory and creating a service ownership catalog, risk analysis of unowned services, and processes for prioritizing identifying owners of high-risk unowned services.
   • It is also our belief and maybe hope that once there is greater clarity, there might be greater voluntary adoption of unowned services by teams. But, that doesn’t take away the need to have processes for working through the harder situations when owners don’t materialize.
   • We are working on updating existing organizational processes for establishing owners for unowned services, and owners will be found as part of those processes.
5. How do we get coverage without burnout? Does the process of ownership also come with empowerment to shut things down?
   • There are at least a couple ways this can happen.
     • The proposed service ownership model includes different ownership states. We expect the majority of owned services to be in maintenance state where there is very little day to day work. Ownership responsibilities kick in for these services only when there are migrations or incidents involving the service. We believe this is one way ownership doesn’t equate to excessive burdens.
     • Owners of services that are in maintenance mode could make proposals to decommission them and work with all involved parties to shut them off. This is another way that ownership lets the organization reduce its collective responsibility.
6. How feasible is it to keep management accountable during reorgs and reprioritization to ensure service ownerships don’t degrade?
   • Given that reorgs and reprioritizations are part of all organizations, we intend to agree on guidelines for how to make those changes in a way that provides continuity.
   • We believe ownership is a long-term organizational (not individual team) commitment, and ownership should persist through reorgs, rescopes, etc. We expect that once this framework is adopted and a service ownership catalog is created, it is much easier to incorporate ownership continuity into management decision making around reorgs and reprioritization. Since this framework also explicitly recognizes a transition of services from active development to maintenance mode with associated reduction in responsibilities, we believe that provides a mechanism to ensure continued ownership by transitioning service status during reorgs and annual planning.
7. Does this now mean I need to get permission any time I want to touch a repository? How about a new repository?
   • As we clarified in the big ideas section of the ORR doc, ownership is established deliberately, not accidentally based on who last wrote code. The intention behind that is to encourage fearless contribution to code in the FLOSS ethos knowing that improving a codebase, fixing a bug, or addressing a migration issue won’t accidentally saddle you with ownership responsibilities you didn’t sign up for. So, we hope developers will continue contributing to services they don’t own. However, service ownership and associated responsibilities do mean that owning teams might have opinions on what code goes into it, and what shape any piece of code should be in before it goes in – this is not necessarily a change from how things work currently.
   • As for new repositories, if it’s a repo for your individual team tools, but it’s not going to touch production, you can probably do whatever you want. Unless it turns out to be critical to serving, or critical to managing/operating other software that’s critical to serving.
8. Some maintainers are responsible for certain code bases individually. Does this mean it is unowned?
   • As above, if it’s a repo for your individual or individual team tools, but it’s not going to touch production, you can probably do whatever you want and it doesn’t fall under the ownership framework now. But if it turns out to be critical to serving, or critical to managing/operating other software that’s critical to serving, it would likely come under the purview of this ownership framework. And, since only WMF teams can be owners, not individuals, maybe your team might have an interest in being an owner? If not, yes, it would be considered unowned.
   • As a rule of thumb, imagine you won the lottery and left the Foundation tomorrow. If you think your responsibilities on this software would probably be distributed among your team, your team is probably the owner; if you think it would probably be abandoned, the code is probably unowned.
9. Why can’t a service go from Owned to Unowned?
   • There is a kernel of insight behind this question. Reorgs, reprioritization, staff churn and turnover, documentation rot is to be expected in any org. So, the concern here is: how does an organization realistically maintain ownership of all the services it operates in maintenance mode (especially those that operate smoothly and rarely need attention)? How do you meaningfully onboard new staff to become acquainted with services in maintenance mode when there is no development activity? Even more so when there might be far more services in maintenance mode than there are staff devoted to maintaining them.
   • So, the question is really asking: with the passage of time, are WMF teams really signing up for on-paper ownership when real knowledge of the codebases is slowly lost over time? And, should we be honest and allow services to transition to an unowned state to reflect reality?
   • Here are a few ways how we can think and approach this:
     • At the very high level, ownership implies accountability. And, so when there is an incident, it provides the organization a repeatable (and decentralized) way of responding to them. First responders contact an owner who then figures out what to do. Even for on-paper-owned services, this is useful.
     • Individual teams can decide, at a per-service level, how they are going to maintain sufficient knowledge to ensure continuity - maybe by adapting hiring, onboarding, and working practices to ensure there is enough working knowledge for the critical services based on their understanding of criticality, risk, and priority.
     • At an organizational level, maybe this will require us to accumulate risk and priority information (metadata) about services. How complex is the service? How regularly does it need to be upgraded? What is its history of maintenance and incidents? How critical is this service to the operation and functioning of the sites? That can then inform the level of effort that goes into ownership. So, in some cases, we may decide to turn off a feature (or extension or gadget, etc.) instead of trying to keep it operational.
     • If our framework a priori allows for services to go from owned to unowned, we fear there is not much incentive for teams and the organization to do some of the hard work (as above) necessary to truly operate the services for a site that aspires to be a multi-generational endeavor. It gives us an easy way out of maintaining them by simply tagging them unowned and we go back to square one.
10. Do we no longer need “heroes” / “generalists” after this framework is adopted?
    • That need will never go away. As noted in the question above (“owned” -> “unowned” missing transition), there will always be coverage gaps and knowledge gaps and sometimes all that the accountable owners can do is do the facilitation work of identifying these heroes and generalists to help address a production issue. But, knowing that we cannot eliminate it, we hope to lower that burden with this work.