As this task is short without all of the context, I am going to paste here my answer to someone who already asked the most important (unanswered as of yet) question:

What does it mean for code to be owned in this context?

I actually don't want to use the word "owned" or any variations from now on in this work. It gives the wrong impressive and caused a lot of consternation in the retrospective. It will again for almost anyone who reads anything about this work without all of the context and knowing the things that were said but not written down in the retro. Oh imprecise English :).

For now I'm going with "responsible parties" but "first responders" is in fact closer to the intended purpose. Another proposal was "Fixers".

The intended purpose is basically "who should RelEng assign a task that is blocking deployment and/or causing problems in production that needs to be resolved quickly whether or not they are the people who do the actual fixing or instead coordinate with the right people who do."

At some big website companies the RelEng team (or comparable) have a list of first responders for all things (again, even here I'm unsure of "all") that they can ping for these issues. That position is normally a rotating one within the team to alleviate the burden. I see this work as somehow making our own version of that but within the limitations that we have (ie: A, some things could have volunteers in that position who we can't expect a very short SLA for response time and B, boy does no one want to own MW Core).

Scare quoting "components" as well just to call it out that defining what is and isn't included here is also a part of it.

My initial take is: MW extensions, services (eg: parsoid or rcstream), and some dissection of MW Core itself.

Comments for the record :)

The pro-activeness of Reading team to create their page is awesome and I greatly appreciate it and wanted to extend it to other teams when I first saw it.

Editing/VisualEditor did the same with that spreadsheet and is/was greatly appreciated as well.

See also: https://www.mediawiki.org/wiki/Talk:Writing_an_extension_for_deployment#Support and https://www.mediawiki.org/wiki/Talk:Writing_an_extension_for_deployment#Post-deploy_support_plan (two sections that ask essentially the same thing on that same Talk: page)

And https://www.mediawiki.org/wiki/Talk:Developers/Maintainers#Kill_extensions.27_.22Maintainers.22_data points out that for MW Extensions some of this information is maintained on the relevant Extension: page. I note, however, in some cases "Author(s)" and "First Responder" will not be the same.

Removing that subtask as it is already part of a chain of work that overlaps with this but I don't want to disturb things already in progress.

I'll need to sync with Quim after he is back from Vacation.

My personal next step is to talk with Technology Management on Tuesday (7/26) about this generally. Not necessarily this task, but the work it represents (I don't care which task is it, though I do wish we'd get away from the word "owners" in those other tasks (see above)).

I'm still taking this proposal in, but a few preliminary notes:

"First responders" or "fixers" confuses me a little bit. A few of us -including all of ops- are de facto first responders on a 24x7 basis.

Is what we're looking for the second-tier/subsystem maintainer, the one that has deeper domain knowledge and to whom the first responders will route a more serious issue? Or perhaps a replacement for first responders? If it's the latter (and let me say upfront that I wouldn't object to that), we'd need to make some serious organizational adjustments to maintain 24x7x365 availability and to make sure there are no silos and someone owns the overall investigation when multiple components are involved.

@ori mentioned that in a recent serious site issue he observed what was basically the "bystander effect" — several people that knew there was an issue but not taking care of it because they thought someone else must be (but noone did). If that's the problem we're trying to solve, then I don't believe "fixers" is the right way to.

I think we need to at some point open up the "ownership" discussion. No component in production should be orphaned, and noone should feel obligated to respond or deploy a short-term fix when there is noone that is going to look in the larger, long-term picture. In my view, this short/long-term split of responsibilities would eventually just add-up to technical debt, rise frustrations and prolong the life of otherwise buggy products or subsystems (e.g. OCG) where noone is incentivized to own them and the "fixers" aren't empowered to either properly fix/rearchitect them or kill them. It also won't incentivize teams to build good products, knowing they might just get reassigned to something else and not be responsibile after they're, say, done working on them for 6 months. (see also T122825 about a "service ownership and maintenance" discussion)

In any case and whichever way we go, I don't believe that this discussion should at any point include specific individuals rather than teams. Individuals come and go, travel, go on vacation, get sick, change roles (and should thus be free to let go of their past commitments). That's why the Foundation exists in many ways and that's why we operate in structured teams.

In T141066#2496346, @faidon wrote:

In any case and whichever way we go, I don't believe that this discussion should at any point include specific individuals rather than teams. Individuals come and go, travel, go on vacation, get sick, change roles (and should thus be free to let go of their past commitments). That's why the Foundation exists in many ways and that's why we operate in structured teams.

This seems to echo a point that @Dzahn made last year on T115852:

In T115852#1796988, @Dzahn wrote:

I think we should aim at replacing individual names in that wiki tables with direct links to tags/projects in phab. This encourages people to use tickets rather than pinging individuals on IRC and is more effective. People interested in an area tend to subscribe to that specfic tag. There are usually multiple people who would reply to a ticket rather than just one owner. Information on the wiki page will also be regularly outdated (look at it right before JohnLewis just made an update:). Trying to find a single owner to everything can be counter-productive, adds unnecessary SPOFs and encourages working in private messages or emails rather than having group input. We should encourage people to just assing tickets to general teams/projects/tags. It usually works better.

I agree with this. @Legoktm has T128370 assigned to him (which calls for updating [[mw:Developers/Maintainers]]. Lego, should Greg postpone any work he plans on this task until you are done with your planned update to that page?

In T141066#2496346, @faidon wrote:

I'm still taking this proposal in, but a few preliminary notes:

"First responders" or "fixers" confuses me a little bit. A few of us -including all of ops- are de facto first responders on a 24x7 basis.

Yeah, "First responders other than ops unless it's an ops owned thing" is just too long ;) Another name welcome.

Is what we're looking for the second-tier/subsystem maintainer, the one that has deeper domain knowledge and to whom the first responders will route a more serious issue? Or perhaps a replacement for first responders? If it's the latter (and let me say upfront that I wouldn't object to that), we'd need to make some serious organizational adjustments to maintain 24x7x365 availability and to make sure there are no silos and someone owns the overall investigation when multiple components are involved.

Based on the retrospective that this came out of: the former. The later would be very interesting and a great goal as well, but... we'd need to at least identify the former first :)

@ori mentioned that in a recent serious site issue he observed what was basically the "bystander effect" — several people that knew there was an issue but not taking care of it because they thought someone else must be (but noone did). If that's the problem we're trying to solve, then I don't believe "fixers" is the right way to.

That's another outcome of that retrospective, but it is not this task exactly.

In any case and whichever way we go, I don't believe that this discussion should at any point include specific individuals rather than teams. Individuals come and go, travel, go on vacation, get sick, change roles (and should thus be free to let go of their past commitments). That's why the Foundation exists in many ways and that's why we operate in structured teams.

Agree about 99%, modulo the things which are deployed that are community owned. I don't know what the absolute number (or even relative percentage) is for those, however. That is another thing that will be identified during this process, is my guess. (see also a few links from the description)

In T141066#2513427, @greg wrote:

In T141066#2496346, @faidon wrote:

"First responders" or "fixers" confuses me a little bit. A few of us -including all of ops- are de facto first responders on a 24x7 basis.

Yeah, "First responders other than ops unless it's an ops owned thing" is just too long ;) Another name welcome.

A suggestion from IRC was "dev(eloper) first responders for all dev(eloper) components deployed"