Re: WMF Production Services Ownership Framework & Service Catalog

Hi Sohom,

Thanks for reading through all the documents and for engaging with this 
at a detailed level -- makes all the time we put into it worth it. :-)

Inline responses below.

On 4/8/26 05:42, Sohom Datta wrote:
> 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?

We are aware of this tension you flagged - specifically that while the 
intention is to have all this be about WMF-internal operations and 
accountabilities, it is possible that some of this will spill over into 
volunteer developer work. That is why we didn't say "no implications" 
and instead chose to say "any major implications" because some of these 
implications will show up as we operationalize this framework. And, we 
need to operationalize and iterate because, among other things, there 
has been a lot of stress and pressure on SRE teams in today's internet 
ecosystem and this work has taken on an added urgency to bring some 
semblance of repeatable process and order.

Getting more specific about the hypothetical you raise, as a working 
group, we'll take this feedback and see what we can do to tweak the 
language and/or address this concern in a FAQ. But, some initial 
comments from me as an individual (not as a response of the working 
group): (a) a lot of volunteer developers do have +2 rights and this 
framework doesn't impinge on that (b) the hypothetical concern you raise 
has always existed in some form, but this framework makes it a bit more 
explicit. (c) ownership from WMF teams will not be arbitrary (your 
concern) - there has to be some rationale for why some team might be 
suitable to adopt it. The problem right now is lack of ownership, and it 
is unlikely that an arbitrary team will jump in to take on additional 
responsibilities, especially for something they are entirely unfamiliar 
with.

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

This criticism came from a previous extension deployment checklist 
process where a WMF team steward was a prerequisite, and this framework 
doesn't change that, and that FAQ question & response exists to clarify 
why that prerequisite continues to make sense despite the perception of 
hypocrisy. So, to make sure I am understanding you right, when you ask 
for a proposed process, I think you are asking: "how does a new service 
go about finding a WMF team owner if it is a prerequisite for 
deployment?".  If that is correct, I'll put this up for discussion for 
the working group.

> - "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"?

should or must is stronger language than can in this particular case 
that I am not sure is useful. When there is an incident response, a 
volunteer maintainer may not always be readily reachable neither can we 
make it a requirement for a volunteer maintainer to be available to help 
with production incidents. In reality, the owning team will likely reach 
out to volunteers to help with an incident, but if they are not 
available, the escalation path will have to exclude them.  We could say: 
"The escalation path should attempt to include ... " which might satisfy 
the intent of what you are looking for without promising that it is 
always feasible to include volunteers in an escalation path. Would that 
work?

> - 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?

Good question. I don't think we've discussed this scenario at this level 
of detail previously. The idea was that we'll develop processes as we 
find a need for them as we institute this framework and gain experience 
with it and find gaps.

Thanks for engaging!

Subbu.

>
>
> 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 withinthe
>     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/