[Proposal] OpenTelemetry Community Membership Hygiene & Growth #3295
Description
To maintain a healthy, vibrant, and secure ecosystem, OpenTelemetry needs a way to ensure that those with status are actively contributing. This proposal outlines an automated "Hygiene Script" to flag inactive members and a framework for sustainable promotion.
This proposal includes information already existing in other documentation, but gathered here for easy reading of the complete picture. If this proposal is accepted, any new information added here will be updated to the correspondent documentation.
Inactivity Thresholds by Role
The following table defines the required "activity" level for each role.
| Role | Responsibility | Required activity level |
|---|---|---|
| Triager | Assist with project management and backlog organization | Add comments, issue labels, or Pull Requests interactions |
| Approver | Approve incoming contributions | Reviews submitted on Pull Requests |
| Maintainer | Set direction and priorities for a subproject | Authored and added reviews to Pull Requests |
| Code Owner | Set direction and provide review for a particular area of the code (e.g. package, plugin, component) | Reviews submitted on Pull Requests and answering to issues created about the owned area |
| Technical Committee (TC) | Responsible for all technical development | Assignments to projects or TC-level design docs. Leading/guiding SIG status. Attendance in meetings. More details here and here |
| Governance Committee (GC) | Governing body of the OpenTelemetry project, providing decision-making and oversight pertaining to the project | Activity on GC-specific tasks (e.g. liaison, proposals, CoC). More details here |
Note: Members can be inactive and no action will be done to remove them from the github org
Offboarding Process
Triager/Approver/Maintainer
Bringing up the topic of inactivity with contributors, especially those with whom a positive working relationship and community bond have been established, is inherently difficult and emotionally taxing for existing leadership. Relying on an automated "Hygiene Script" removes this personal barrier. The script acts as an objective, neutral party, generating data that initiates the conversation without placing the burden of confrontation on any individual Maintainer. This mechanism ensures consistency and fairness across the project, allowing the discussion to focus on the data and the member's current capacity to work on the project rather than potential personal discomfort.
The "Hygiene Script" is a tool for visibility, not immediate execution, and a human still needs to interact to confirm the changes. The steps will be as follows:
- The script is executed and generates a "Hygiene Report" PR, which moves inactive members to the Emeritus section
- Existing active members must review the flagged list. If a member is inactive due to a known sabbatical or temporary life event, the PR can be closed with no further actions
- If no objection is raised within 14 days of the report, the member is moved to "Emeritus" status, and their permissions are revoked.
The script will be executed monthly, and the data will be from a rolling 4 months window.
Code Owner
A code owner is an individual who has technical authority and responsibility over a particular subset of the codebase (e.g. component, package, library). They must review and approve all PRs targeting their area of ownership before those changes can be merged, ensuring that new code aligns with the OpenTelemetry specification and the specific architectural patterns of that repository.
The automated "Hygiene Script" for checking Code Owner activity must account for the reactive nature of their role, linking their expected activity to contributions targeting their specific area of code ownership, unlike the continuous contribution expected from Maintainers. Consequently, a Code Owner should only be flagged as inactive if, within the standard four-month inactivity period, new Issues or Pull Requests were created that target their code area, and they failed to provide any response, review, or comment on those specific contributions; if no new Issues or PRs were created, the Code Owner is considered not applicable for inactivity flagging, ensuring those responsible for stable components are not penalized for low activity volume, but if flagged, the standard offboarding process for Triagers/Approvers/Maintainers will apply.
If the removal of an inactive Code Owner leaves an area of the codebase without any assigned ownership, the respective SIG is empowered to determine the immediate course of action. For a transition period of at least three months, the SIG's core maintainers will assume direct responsibility for reviewing and addressing all incoming Issues and Pull Requests targeting that unowned code area. During this temporary period, maintainers have the discretion to decide whether to accept new feature contributions or to strictly limit work to essential bug fixes, security patches, and maintenance-related PRs to manage the unexpected workload. Should the three-month period conclude without a suitable new Code Owner being identified, the maintainers have the option to recommend the complete removal of the unowned code area from the repository to mitigate long-term maintenance overhead. However, if after the removal a new active Code Owner is successfully recruited, the area of code can be formally reintroduced into the project.
Technical Committee Member
Due to the nature of their responsibilities, establishing a purely mechanical definition for the activity of a Technical Committee member is challenging. Unlike Triagers/Approvers/Maintainers whose actions are logged as measurable interactions (comments, reviews, PRs), the core contributions of a TC member often occur in meetings, design sessions, or documents that are not easily scraped by an automated script.
The "Hygiene Script" can provide a signal for a TC activity, by looking if any issues assigned to a TC member is getting updated, and should not be without any new comments in a period of a month. The script can provide the list of “stale” items.
Since that signal might not be enough, the offboarding of an inactive TC member must remain a deliberate, manual process: active TC members are responsible for monitoring and raising concerns about their peers, sharing findings with the Governance Committee, which can then initiate a private conversation with the individual about voluntarily stepping down.
Governance Committee Member
Due to the nature of their responsibilities, establishing a purely mechanical definition for the activity of a Governance Committee member is similarly challenging to that of a Technical Committee member. GC contributions often occur in private discussions, internal documents, or non-GitHub community venues that are difficult to track with an automated script. Therefore, the monitoring and offboarding process must remain primarily manual.
The "Hygiene Script" can provide a signal for a GC activity, by looking if any issues assigned to a GC member is getting updated, and should not be without any new comments in a period of a month.
Besides that, active GC members are responsible for monitoring their peers and raising concerns about inactivity. The wider community can raise concerns to active GC members, particularly if a GC member assigned a public-facing role, such as a SIG liaison, is consistently unresponsive.
If a member steps down before completing their term, the resulting vacancy can be filled in the following election, subject to maintaining the required balance of elected seats. An extra spot should only be added to the election if the addition maintains the current 4:5 or 5:4 split of existing vs new members. If adding the vacant seat would result in an imbalance (e.g., creating a 6:3 split), the spot should not be added to the ballot for that election cycle.
Voluntary Stepping Down
Members are encouraged to proactively move to "Emeritus" status if they realize they can no longer commit the necessary time. Changes in jobs or shifts in life priorities can easily affect a member's capability to contribute to this project, making the decision to step down a completely normal and healthy one for both the individual and the project. This is a badge of honor, not a sign of failure.
Promoting Existing Members
A project dies if it depends on the same few people forever and doesn't scale. We must treat contributor growth as a core metric of project success. The amount of contributions keep increasing, and the code is more complex, so the amount of people required to handle the workload will naturally also increase.
There is no "maximum" number of maintainers, approvers or triagers a SIG can have. If someone meets the criteria, they should be promoted. This will also help share the responsibilities, so we don't have scenarios where bigger projects only get accepted if approved by the same individual.
Every month, existing maintainers should do a check if there are any members that should be promoted. Existing approvers/triagers are also welcome to provide recommendations. It's the responsibility of the SIG to add new members, but the GC liaison for that SIG can also check if this is being done and members are getting properly recognized and promoted.
The implementation of the automated "Hygiene Script" will also serve as a vital signal for necessary growth. By objectively identifying and flagging inactive members, the script may expose areas of the project that rely heavily on a small number of contributors. Once inactive members transition to Emeritus status, the resulting vacancies will underscore potential resource deficits. Therefore, a deliberate and continuous focus on promoting and recruiting new contributors is not just a mechanism for growth, but a necessary measure to maintain the overall health and workload capacity of the project, ensuring that vital areas remain actively staffed and reviewed.
Next steps
If this proposal is approved, the “Hygiene script” will be added and executed in all repos, and it will be maintained by the GC. To be clear, the script is owned by the GC, but the approval of the PR is owned by the respective SIG.
Any additional information added here that does not yet exist on other parts of the documentation, will be added to their section respectively.
For the promotion, it's expected that SIGs will pay more attention to this topic and GC will monitor its progress.