Feature request: CODEOWNERS without write permissions #23042
{{title}}
|
The way our project (https://github.com/OP-TEE) is setup is that we have a set of core maintainers (read/write access) and a set of platform maintainers (read only). So for example when a pull request touches a piece of code belonging to a platform maintainers area the core maintainers asks the platform maintainers for their feedback to decide whether a pull request should be merged or not. When we first heard about the CODEOWNERS features we were pretty excited, since that could automate adding correct reviewers etc, but because of the requirement saying: “The people you choose as code owners must have write permissions for the repository.”, we couldn’t enable the CODEOWNERS feature. What about enabling this so that anyone (with a GitHub account) can be added to the CODEOWNERS file, regardless if they have write permissions or not? // Regards Joakim |
{{title}}
|
Hi @jbech-linaro, Thanks for this feedback! We’re always working to improve GitHub and the GitHub Community Forum, and we consider every suggestion we receive. I’ve logged your feature request in our internal feature request list. Though I can’t guarantee anything or share a timeline for this, I can tell you that it’s been shared with the appropriate teams for consideration. Cheers! |
{{title}}
{{editor}}'s edit
{{editor}}'s edit
|
@BelHFL Could we get an update on this please? Yes, this is definitely a feature that we would like in our organization as well. There is a pretty big difference between "trusted to commit to the whole repo" and "Is the person/team who is responsible for this particular piece of code and knows it the best, to the point where we want to ensure that they always approve things that touch it before they get committed." |
{{title}}
|
Would also like this |
{{title}}
|
+1 |
{{title}}
|
+1 |
{{title}}
|
The workaround that I'm using now is this: https://github.com/multimediallc/codeowners-plus |
{{title}}
|
+1 for this. Code owners without write access to repo makes a lot of sense when you can't give write permission to a contributor but need their feedback for reviews. |
{{title}}
|
Is there some reason this can't be done? Especially in the case of large monorepos which house multiple components of different ownership (otel-js-contrib for example) requiring write access for CODEOWNERS presents a challenge. As @Bhupesh-V says:
|
{{title}}
{{title}}
|
Rahmankazemi |
{{title}}
|
♾️♎⚛️☮️♒☣️🏧 |
{{title}}
{{editor}}'s edit
{{editor}}'s edit
|
I hope this gets resolved someday. As an opensource project, we have a multiple collaborators outside of the core team who can help us to maintain code they have contributed. But we can't trust with write access to everyone. Maybe CODEOWNERS for everyone would be hard to implement. But I can see we can now request reviews from any organization team, triage or without any permissions, so maybe changing the requirement from "write permissions" to "be part of an organization" should be more feasible? |
{{title}}
{{editor}}'s edit
{{editor}}'s edit
|
@volas At OpenFeature, we've been using https://github.com/dyladan/component-owners, which is also used by a few OpenTelemetry monorepos. |
{{title}}
|
+1 on this. |
{{title}}
|
Access to review code is very different than access to write code. This request would honor that difference. |
{{title}}
|
We would love to have this functionality. There are plenty of sections of our repositories that have people who do not have repository write access who are nonetheless functional owners. As we grow bigger, it would be great to have the ability to encode this instead of just relying on people to know it, as that is rather limiting and makes it hard to grow smoothly. |
{{title}}
{{editor}}'s edit
{{editor}}'s edit
|
Definitely looking forward to this functionality! |
{{title}}
{{editor}}'s edit
{{editor}}'s edit
|
+1 this is something I have only just come to realize can't be done and would be far simpler than the alternative. |
{{title}}
{{editor}}'s edit
{{editor}}'s edit
|
Bump. Ran into this today with a public project. In sharkdp/bat#2755, I added a custom syntax mapping definition system, which is a reasonably significant amount of code. Obviously I understand how it works better than anyone else, so I would like to get notified when relevant files are changed to give my feedback. But for some reason this is predicated on me being a maintainer, which I find rather odd. I do not wish to obtain maintainer access, nor do I have expertise regarding all other bits of code. So I am very much in favour of this feature being implemented. That being said, I did notice a security implication of allowing non-maintainers to be notified via CODEOWNERS while writing this. A bad actor would be able to create a repository and add any or all GitHub users to its CODEOWNERS file, and using this as some sort of mass spam bot. This obviously should not be allowed to happen. Therefore maybe it's best to only allow notifying users who have interacted and/or written to the repository. |
{{title}}
|
I requested the same thing in 2022, prior to realizing this Feature Request discussion here was opened back in 2019... |
{{title}}
|
After all this time it would be nice to get a statement of intent from the github team, be it positive or negative, a timeline or somesuch so we know what we can expect or not. |
{{title}}
|
They will just write 59 words to say they saw it. It's actually better to have no feedback at all than meaningless fluff. |
{{title}}
|
Considering they officially responded and said it's been passed on to their internal team for consideration back in 2019, same day it was posted, in fact, and then hasn't been touched since... Odds are not good. |
{{title}}
|
Welcome to github |
{{title}}
|
+1. That would be great! Maybe now with AI they can cut through the backlog? 😅 |
Hi @jbech-linaro,
Thanks for this feedback! We’re always working to improve GitHub and the GitHub Community Forum, and we consider every suggestion we receive. I’ve logged your feature request in our internal feature request list. Though I can’t guarantee anything or share a timeline for this, I can tell you that it’s been shared with the appropriate teams for consideration.
Cheers!