Feature Request: Allow users with Triage (and potentially Read) Permissions to be supported by CODEOWNERS

[ScriptAutomate]

This is being created in response to a documentation error that has since been corrected, leading to realization that GitHub is missing a feature that would be very valuable:

• CODEOWNERS documentation claims that a user needs at least read access, but GitHub's built in linter claims the user needs write access github/docs#18984

I work with projects where we have community members added to certain repositories, as Outside Collaborators, with Triage and Read permissions so that they can help with PR reviews and Issue triage.

CODEOWNERS only supports users with Write permissions to a repository:

The people you choose as code owners must have write permissions for the repository. When the code owner is a team, that team must be visible and it must have write permissions, even if all the individual members of the team already have write permissions directly, through organization membership, or through another team membership.

Initially, we thought it was a GitHub bug, since it made sense that Read/Triage users would be supported for reviewing PRs. It turns out the documentation had an error (it originally said, "The people you choose as code owners must have read permissions for the repository." and has since been corrected to state write permissions).

Supporting users with Read and Triage permissions would be incredibly ideal, and would open the door to better repository management practices that lean toward least privilege when possible.

• Read: Recommended for non-code contributors who want to view or discuss your project
• Triage: Recommended for contributors who need to proactively manage issues and pull requests without write access

Triage seems to be made explicitly for this purpose.

For more information on what repository role permissions mean (Read,Triage,Write,Maintain,Admin):

• Repository roles for an organization

[damon-atkins]

Write access gives access to Merge. Their needs to be a way to allow people to be included as part of the review process in CODEOWNERS without giving them write access. PR -> CODEOWNERS Reviewers (with and without Write/Merge Access) -> Approval conditions met -> Merge

[Zitchas]

I would like to second this request. Within our organization we have teams of reviewers who are focused on particular sections of the code, and their input is almost required for PRs that touch those areas. However, they do not have write permissions. It would be great if we could set up a "codeowners" like thing that automatically requests a review from these teams and individuals when PRs touching their areas of specialization happen, but that will work with people who have triage or read level access.

Thank you!

[c-ehrlich]

This would be a great feature to have.

We want to set up everyone who has contributed to a translation of our docs as a codeowner of that language so they can get pinged for reviews on future changes to this language. However we don't necessarily want everyone who has ever made a docs contribution to have write access and access to repo secrets.

[cartucciam]

This would help a lot with the increase adoption of GitOps and platform self servicing, many organisation would benefit from having reviewers without write access. Worth pointing out that having write access also means being able to modify and run GHA workflows off a branch.

[RUBenGAMArrarodRiguEZ-ToMtOm]

REgarding the option for reviewing prs I understand that allowing users who don't have write permissions would conflict with some GitHub setups that have automation, if the automation allows a pr to be merged when:

• All the required pr check have passed
• Users who don't have Triage or Read approve any type of changes, resulting in a CODEOWNERS pr approval

This would effectively cause users configured with Triage or Read to acquire Write permissions on demand to put content in the default branch. Which I found unexpected for the users with Triage or Read .

[Zitchas]

That is good to be aware of, but that also sounds like "working as intended." If an organization has automation to merge after all required approvals are complete, and one of those required is the codeowner, then it shouldn't matter what privileges the code owner has. In fact, this sounds like a very clever way for an organization to allow the most knowledgeable person for a specific file or folder to trigger commits to that specific area without giving them any privileges for anywhere else. Sounds like a win for security and compartmentalization.

In fact, in my very limited experience, one of the reasons done organizations use automations to reduce the number of people doing commits directly. As such, allowing codeowner to be people without write permissions is one more tool to increase safety.

Of course, this potential interaction should be documented, but if someone is being appointed codeowner, which is effectively granting something of a veto or "must approve" status over a portion of the code, then I think it is reasonable to expect that they are sufficiently trusted to trigger the activation of a commit on that same code in the case where the organization has set up that automation.

[damon-atkins]

CODEOWNER is who you want to add to the approve list, that does not need to be the same as the person approved to merge. Their is no MERGEOWNER In terms of open source, companies want to notified people who do not belong to the company, however have a strong interest in reviewing the code, however should not be allow to merge the code.