Re: WMF Production Services Ownership Framework & Service Catalog

Hi Subramanya,

Thank you for the detailed clarifications!

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.


I think explicitly calling that out in the FAQ might be a good idea, I
didn't get that nuance when I read it :)

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


That does assuage my immediate concerns! :)

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.


Yep!

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?


That was exactly what I was going for!

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


On Tue, Apr 7, 2026 at 11:52 PM Subramanya Sastry <[email protected]>
wrote:

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