Ensure community roles represent the current practices

[mx-psi]

Currently we recognize four active role levels that are applicable to all repositories and SIGs: member, triager, approver and maintainer. I think this hierachy is useful but it fails to recognize some practices/realities in some SIGs:

• Some SIGs such as the Collector SIG and the Go SIG also have codeowners: members that own a specific component and are expected to review this component specifically.
• We tie time investment to the project with expertise on the project. While the two are related, there are folks that have a lot of expertise on a topic but can't have a lot of time investment. This means we have to choose between giving people a role they can't fully fulfill or failing to recognize their expertise and having them recognized as valuable contributors.

I would like to have this as a meta issue for anything related to the community roles, but for working on it we can split it per specific problem.

[svrnm]

Good call out, thanks!

Re: codeowners, we can and should add them to the community membership document, especially outlining what their responsibilites and privileges are, and maybe have a group for them like @open-telemetry/collector-component-owners etc, this group may have no immediate use beyond them being part of it.

[mx-psi]

Here is the guide we currently have on the Collector about code owners and how they work: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/CONTRIBUTING.md#becoming-a-code-owner

[mx-psi]

For the second bullet point, there are two groups that may be slightly different:

• People who used to have time but don't have as much time anymore. Some concrete problems:
  • Taking these people into account in voting mechanisms or other processes that assume all people to be active can be challenging
  • Lack of visibility of health of a sub-project (you can't easily tell from the amount of approvers/maintainers what the actual level of participation actually is)
• Solutions architects type of folks that have the expertise but may not have the time/interest to very actively participate.The concrete problem here is getting them to participate a bit more is difficult and we may not be getting their feedback as much as we would want to.

[mx-psi]

We discussed this on the 2025-02-17 Contributor Experience SIG meeting, and wrote down a list of open questions that need to be discussed in relation to this:

• What is the best name for this?
  • Advisor/fellow/ambassador/champion?
• What are the qualifications for this role?
  • We have to protect them and protect SIG maintainers
• Who are the personas we want to capture with this?
  • End-users
  • People with relevant roles in other projects (K8s SIG Instrumentation leads, NodeJS maintainers…). That may be different from an end-user advisor
  • People that do a lot of public speaking related to OTel
• Why would this someone be put in this specific role vs triager/approver/maintainer?
  • Provide feedback, come to SIG meetings from time to time
  • Time commitment should be a criteria here, if you can't invest enough time on the other roles but can do so for discussing specific topics in an ad-hoc basis
• Should this be at the SIG level, project level or both?
  • Both sounds reasonable
  • It could be that having the role at the SIG level you could have it at the project level
    • That could be too many advisors, we could do this via nominations
  • We could limit it via SIG type, but this raises the question of why some SIGs are 'allowed' to do this/not?
• Should there be a limit of the total number of advisors per SIG? (1/2)
• What are they supposed to do/bring to the table?
• What is the difference between a 'usual' community member and an advisor/ambassador/champion?