Onboarding path for new code owners

[djaglowski]

Describe the issue you're reporting

Code owners are subject to changing priorities and have variable capacity to allocate to this repo. In practice we see that they often have sufficient experience and bandwidth to triage and address critical issues responsively even if feature requests and low priority bugs.

We have had many conversations about whether and when to reduce scope by designating components as unmaintained and ultimately removing them. However, I believe very few components are maintained so poorly that they are a net negative to this project. I think it may be more worthwhile to focus on bringing in more code owners.

One of the easiest ways to bring in more code owners is to increase clarity about what is needed and expected. Importantly, we should not define code ownership is such a way that low-bandwidth contributors are excluded. It should be enough that maintainers and existing code owners are confident that their influence and that their contributions are a net positive.

To that end, I propose the following:

1. Clarify the meaning of code ownership in a more inclusive manner. Requirements and expectations should be enough to ensure quality but flexible towards velocity and bandwidth.
2. Provide a simple mechanism for indicating that a component is in need of additional code owners.
3. Regularly broadcast the need for additional code owners on specific components.

I will open a PR for item 1.

Item 2 could be addressed by adding a flag to mdatagen and a corresponding note in autogenerated documentation:

  codeowners:
    active: [...]
    seeking_new: true

Item 3 could be addressed by updating the weekly report to call out components seeking new owners.

[crobert-1]

Some minor qualifications, but I agree with the general direction you've proposed. The goal in my mind is to have the best user experience we can, so to me this results in a balance between total functionality breadth, and supporting that functionality (in the overall product, not just code owner related).

However, I believe very few components are maintained so poorly that they are a net negative to this project. I think it may be more worthwhile to focus on bringing in more code owners.

Good point. The challenge is really the amount of ongoing work necessary for a given component (issue triage, enhancements, bug fixes, etc) relative to the amount of time the existing code owners have to address it. So in theory, more code owners means each would have a lower burden, so it definitely helps from that perspective. I do think we may have to consider the opposite extreme of too many code owners as well. I could see there being challenges in communication and understanding long term direction in a component if there are a lot of code owners. However, existing code owners are the responsible parties to allow more to join, and in general I don't think this is currently a noteworthy concern, just something to keep in mind.

Importantly, we should not define code ownership is such a way that low-bandwidth contributors are excluded. It should be enough that maintainers and existing code owners are confident that their influence and that their contributions are a net positive.

I think this comes down to a balance again. I want to include as many people as we can, but there's also responsibility in being a code owner. If a very specific enhancement request comes up, or a p1 bug has been filed, we really rely on code owners to step in and provide the highest quality response.

Now, is getting no response (using the worst case scenario for the sake of an example) from 7 users worse than 3? No, you'd still theoretically have a higher chance of response, but I just want to point out that this is still a commitment to some extent.

Item 3 could be addressed by updating the weekly report to call out components seeking new owners.

I like the idea of adding this to the weekly report. A regularly updated status for this kind of thing is really helpful, especially if a contributor is interested in helping out more, it's a good way to see where help is needed/wanted.

[djaglowski]

@crobert-1, since you have been managing the weekly report, do you want to add the new section once #31167 and/or open-telemetry/opentelemetry-collector#9552 are merged?

[crobert-1]

@crobert-1, since you have been managing the weekly report, do you want to add the new section once #31167 and/or open-telemetry/opentelemetry-collector#9552 are merged?

Sorry for the delay, I'd be happy to add this when I get a chance. 👍 I've filed #31419 to track this.

[djaglowski]

Thanks @crobert-1. I believe all other work captured in this issue has been completed so I'll close it in favor of #31419