Re: WMF Production Services Ownership Framework & Service Catalog

Few thoughts:

- How does "Active community development -> In particular, even
community-developed features are subject to discussion and review
(collaboratively, but with the PM owner responsible for a final decision)
on whether they take the product in the right direction,....." in the
Service Ownership Roles and Responsibility page square with "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."  mentioned in the FAQ. Both statements
seem at odds with each other, with the first explicitly motivating a loss
of agency for a volunteer developer (who I assume cannot override the
Product Manager Owner's decision on direction). To give a hypothetical: if
I (as a volunteer "owner" of some portion of the ProofreadPage codebase)
decide to add a community feature, could an arbitrary team that has
previously not worked on the codebase (for context, ProofreadPage on the
tech side is currently unowned outside of a few folks on the Community Tech
teams && the more recently the Parser team fixing some issues in parser
land) block such improvements or take a descision to sunset the extension?

-  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
the deployment of new volunteer extensions without having WMF owners
associated with them?  -- While I'm personally okay with the rationale, I
think it might be useful to engage with this criticism and potentially
propose a process through which an extension/feature can enter into WMF
stewardship/deployment on production wikis.

- "The escalation path can include active volunteers with knowledge of the
service, but must also include staff teams." -- Is the use of "can" v/s
"must" (cc RFC 2119) for looping in a volunteer maintainer intentional in
this sentence? Why so? Maybe it can be upgraded to a "should"?

- The maintenance category comes with very limited product manager, owner,
or engineering manager involvement, with no obligations to review patches
from volunteer developers. Assuming there is interest from volunteer
developers to work on a particular extension (cc SecurePoll extension or
similar), what is the process of transitioning to a community-maintained
extension/soliciting reviews to patches?


Regards,
Sohom Datta
---
Open-source contributor @Wikimedia


On Tue, Apr 7, 2026 at 3:19 PM Subramanya Sastry via Wikitech-l <
[email protected]> wrote:

> Greetings everyone!
>
> On behalf of the Code Ownership Working Group, I am sharing an update on
> how the Wikimedia Foundation (WMF) is approaching Service[1] Ownership to,
> among other things, ensure clear accountability for responding to incidents
> in Wikimedia production services.
>
> Wikimedia production runs a large and diverse set of software – built by
> WMF teams, affiliates, Wikimedia volunteer developers, and third parties.
> Regardless of origin, all production services need clear accountability for
> handling production failures like UBNs (UnBreak Nows arising from
> production incidents, such as security, deployment, availability, bugs,
> etc.), migrating infrastructure, and software upgrades. When accountability
> is unclear for production services, incident handling defaults to first
> responders or whomever is available, which isn’t a reliable model and can
> increase risks or delays.
>
> We’ve therefore begun a focused effort to systematically reduce instances
> where production software lacks contingencies and clearly defined WMF team
> responsibilities. This work involves finding team assignments for all
> production services and is primarily about improving clarity and
> accountability within the WMF. We don’t expect assignments for all
> production services right away, but expect to gradually narrow the set of
> unowned services prioritized by risk.
>
> Some software in the Wikimedia production environment is primarily
> developed by the Wikimedia volunteer community. Wikimedia volunteers make
> essential contributions, including during time-sensitive incidents, but the
> WMF can’t expect guaranteed availability or formal time commitments from
> volunteers. For these services, WMF teams are expected to step in for
> urgent operational needs if volunteers aren’t available. This is about
> being clear as to who should respond when production services need
> time-sensitive work (like UBNs).
>
> We’ve published two documents on wiki (a) Service Ownership Roles and
> Responsibilities
> <https://www.mediawiki.org/wiki/Wikimedia_Production/Service_Catalog/Ownership_Roles_and_Responsibilities>
> (b) FAQ
> <https://www.mediawiki.org/wiki/Wikimedia_Production/Service_Catalog/FAQ>.
> As part of this work, we will borrow heavily from the existing Maintainers
> page to build a Service Catalog. We will publish this on wiki with an
> intent to gradually deprecate and retire the existing Maintainers page.
>
> Please reach out on the Talk pages of the wiki pages above if you want any
> additional clarification not addressed here or in those links.
>
> Subbu, on behalf of the Code Ownership Working Group @ WMF.
>
> [1] Service represents a unit of ownership: microservice, extension,
> library, MW core component, etc.
>
> _______________________________________________
> Wikitech-l mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

_______________________________________________
Wikitech-l mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/