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.
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 < wikitech-l@lists.wikimedia.org> 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 -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
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 wikitech-l@lists.wikimedia.org 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 -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
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 ssastry@wikimedia.org 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 < wikitech-l@lists.wikimedia.org> 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 -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
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 ssastry@wikimedia.org 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 <wikitech-l@lists.wikimedia.org> 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 -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
wikitech-l@lists.wikimedia.org