Community: Request for a triage role

[chadbrad]

Request for a triage role, using github's triage permissions:
https://help.github.com/en/articles/repository-permission-levels-for-an-organization

Reason for request: To allow for non-coding collaborators to assist with issue management in the various repositories. Recently there was a request for this kind of assistance by @SergeyKanzhelev and @tedsuo

Proposed below:
A role would need to be defined here, labelled "Triage" (Triager is like..totally bad grammar).
https://github.com/open-telemetry/community/blob/master/community-membership.md

• Role name: Triage
• Responsibilities: Manage issues and pull requests (labels and milestones).
• Requirements: sponsored by 2 owners.
• Defined by: ?

Detailed requirements could be something like this:
Requirements

• Enabled two-factor authentication on their GitHub account
• Have made contributions to the project or community. Contributions may include, but is not limited to:
  
  
  
  • Authoring or reviewing PRs on GitHub
  
  
  • Filing or commenting on issues on GitHub
  
  
  • Contributing to SIGs, subprojects, or community discussions (e.g. meetings, chat, email, and discussion forums)
  
  
• Joined the gitter channel
• Have read the contributor guide
• Sponsored by 2 approvers. Note the following requirements for sponsors:
  
  
  
  • Sponsors must have close interactions with the prospective member - e.g. code/design/proposal review, coordinating on issues, etc.
  
  
  • Sponsors must be approvers or maintainers in at least 1 CODEOWNERS file either in any repo in the OpenTelemetry org.
  
  
  • Sponsors must be from multiple member companies to demonstrate integration across community.
  
  
• Open an issue against the OpenTelemetry/community repo
  
  
  
  • Ensure your sponsors are @mentioned on the issue
  
  
  • Complete every item on the checklist (preview the current version of the template)
  
  
  • Make sure that the list of contributions included is representative of your work on the project.
  
  
• Have your sponsoring reviewers reply confirmation of sponsorship: +1
• Once your sponsors have responded, your request will be reviewed by the Governance Committee. Any GC member can review the requirements and add Members to the GitHub org.

Responsibilities and privileges

• Work with maintainers, SIGS and community members to manage and organize issues.
• Responsive to issues and PRs assigned to them
• Request reviews on pull requests
• Mark issues and pull requests as duplicates
• Add or remove milestones on issues and pull requests
• Create new milestones, as defined by each SIG

[tedsuo]

Thanks @chadbrad!

I would really appreciate having this. The current membership roles are defined as code contributors. But I've often been in a position where I could help out a SIG in which I have no intention of contributing code. As the project advances, there will be more new contributors, and we will be relying on having a clean backlog more than ever. So, a role for TPMs and community managers who would like to assist with these non-code activities would be very welcome.

I suggest this be implemented as an org-wide team of triagers. To explain why:

• The access rights given to this role are low, so the risk is low.
• TPMs and community managers work across languages, as they are not code contributors. So the most common approach will be to give the same triager access to many repos.
• Given that there are already 16 repos, with more coming as we continue to add components, the combinatorial explosion of access rights is going to be a bureaucratic burden. Likewise, when a TPM or community manager moves on, it will be much easier to say goodbye, and not accidentally leave dangling access rights.

If we add this role, I could also start a low-frequency TPM/Triager SIG, where we can discuss community management and backlog gardening, to help share best practices as they are developed in the individual SIGs.

[tedsuo]

And if triager is bad grammar, how about gardener? I might be a triager, but I'm definitely not a "triage." :)

[austinlparker]

I'd also suggest that gardening roles aren't gated on existing contributions to the project, to make it easier to onboard TPMs/CMs. I understand the need for approvers/maintainers to have some 'skin in the game' but given that this is (largely) a project supported by employees of large companies, we should make some concessions to business practices.

[bhs]

FWIW, I am very positive about this proposal... we just need to find someone who can help!

PS: Unfortunately, I don't think the GH "triage" permissions make this possible, but it could also be good to have a TPM or similar act as a delegate of the governance committee and handle org and SIG membership requests.

[chadbrad]

@austinlparker - I concur re: the gating. I realize this goes counter to what I suggested above, but did not have a good sense of how stringent we needed to be there. Let me ask this: Is there anything we would want in place of the contributions listed above? Or shall I slice that out of what I've proposed above?

@tedsuo - what about "coordinator" vs "gardener" ? I

[tedsuo]

Hmmm, the only reason I don't like "coordinator" is that it sounds kind of bossy. I'm open to ideas though!

[tedsuo]

@yurishkuro @sarahnovotny @bogdandrutu any thoughts? We have a couple people who could get started, if we can figure the permissions issue out.

[chadbrad]

No strong objections to gardener :)

[SergeyKanzhelev]

We discussed it and it felt that approver is a sufficient role. Bar for entrance and responsibilities are quite similar. Please check these links out. And comment what's the reason for a separate role.

Here: https://github.com/open-telemetry/community/issues/86

https://github.com/open-telemetry/community/blob/master/community-membership.md#approver

Approver status can be scoped to a part of the codebase. For example, critical core components may have higher bar of becoming an approver. Some approvers may only be doing issues triage and have no approval rights.

[SergeyKanzhelev]

my previous comment answers the initial proposal.

For the gardener proposal - the biggest risk I see is how to decide who can be a gardener. Managing labels and milestones as well as triaging issues, while helpful, may be perceived as an attempt to manage or "boss" maintainers. So we need to ensure there is a process of building a trust with maintainers. Becoming an approver is a way to build this trust. However without code contributions building this trust is hard as it creates a chick-egg problem. Maybe the rules of becoming an approver can be simplified and maintainers will have more freedom of accepting help by "appointing" approvers.

If we only talking about creating milestones as requested in https://github.com/open-telemetry/community/issues/201 - this probably can be handled as one-of task without changing the process drastically.

[tedsuo]

@SergeyKanzhelev it's more about being able to assist with background tasks. Right now, the Approver requirements are too high - that role is for active code contributors. This role is for people trusted to do TPM work, not contribute code:

• Basic traige work - following up on stale issues, and ensuring they are addressed.
• Adding labels and milestones as appropriate.
• Ensuing issues are Assigned when someone is working on them.
• Marking issues and PRs as duplicates.
• Tooling/reporting for project-wide backlog visibility.

Right now, performing these triage tasks involves poking developers for one or two of the minor aspects - this is like sand in the gears. It is slowing project velocity by preventing TPMs and community managers from taking a more active role. I don't think anyone wants to "boss" maintainers around - a triager/gardener role is for providing cleanup and assistance.

I agree that triagers/gardeners must be vouched for by community members, and if the role is abused that person should have their access revoked. But I don't see it as the same as an approver role, unless we are willing to change the rules which allow non-code contributors to be approvers.

In fact, I am frustrated about the approver role as well - right now I am am having trouble even getting active contributors to be made approvers - and these rejections are coming from "admins" who are not even connected to these SIGs (https://github.com/open-telemetry/community/pull/197). So there needs to be a pretty big change in direction here, for me to believe that it would be possible for a TPM to get Approver access.

[SergeyKanzhelev]

My biggest advocacy is to empower maintainers of SIGs to run the project the way they like and suitable for their needs. Whole structure of project governance is to represent contributors interests. So maintainers may decide which issues are important and fit the milestone and which are not. When to ship a hotfix and when just wait for the next release, etc.

While in theory the tasks you listed is a big help for maintainers when done right, any of this help CAN lead to the conflicting situation. And it may be a visible conflict or just an annoyance that can make maintainer feel unwelcome.

I agree, however, that approvers bar may be lowered to give more power to the maintainers. Especially for limited code level rights approvers. The only push back on adding approvers was that there are formal rules and breaking them once will raise a question next time.

So if there is lower bar for becoming and approver/triager that still assumes that maintainers are making this decision - I believe it will be the best way to introduce "gardeners" into the repositories.

[tedsuo]

Thanks @SergeyKanzhelev. If we can change the approver requirements to be less about specific contributions, and more about maintainers' discretion, I think that would be an improvement. But I would need the role to be clearly defined to be able to add engineering managers, not just contributors.

I do understand your concerns regarding maintainers wanting to feel welcome. But we need to make sure that we have a path forwards to avoid some of the pain we are currently feeling. I will bring this up at the community meeting, and post the results here.

[lizthegrey]

Governance committee has discussed this issue and believe at this time that reducing the cooloff period to 1 month should help get more active contributors authorized as approvers, and we'll evaluate whether we need a triage role after seeing the effects of having more approvers.

[lizthegrey]

This hasn't surfaced as a concern since we opened the approver floodgates so I'm going to close this for now. Reopen if it becomes a significant concern.