Re: WMF Production Services Ownership Framework & Service Catalog

Great! Glad to hear.  We'll land a bunch of edits to the published pages 
once we get around to meeting and discussing this feedback.  Thanks!  
-Subbu.

On 4/8/26 20:33, Sohom Datta wrote:
> 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 thatit 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 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/