docs
docs copied to clipboard
CODEOWNERS doesn't talk about forks
Code of Conduct
- [X] I have read and agree to the GitHub Docs project's Code of Conduct
What article on docs.github.com is affected?
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
What part(s) of the article would you like to see updated?
There should be text that talks about how CODEOWNERS
interacts w/ forks.
Additional information
I have a forked repository, and I'm pulling in an upstream commit that includes CODEOWNERS
, and it isn't remotely clear what will happen if I do this.
[maintainer edit] Content plan here
@jsoref Thanks so much for opening an issue! I'll triage this for the team to take a look :eyes:
Did anyone figure this out? Wondering the same thing
@dylanjha Thanks for checking in! This issue is up on the board and waiting for review. Someone will take a look at it soon 👀
Code of Conduct
- [X] I have read and agree to the GitHub Docs project's Code of Conduct
What article on docs.github.com is affected?
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
What part(s) of the article would you like to see updated?
There should be text that talks about how
CODEOWNERS
interacts w/ forks.Additional information
I have a forked repository, and I'm pulling in an upstream commit that includes
CODEOWNERS
, and it isn't remotely clear what will happen if I do this.
Code of Conduct
- [X] I have read and agree to the GitHub Docs project's Code of Conduct
What article on docs.github.com is affected?
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
What part(s) of the article would you like to see updated?
There should be text that talks about how
CODEOWNERS
interacts w/ forks.Additional information
I have a forked repository, and I'm pulling in an upstream commit that includes
CODEOWNERS
, and it isn't remotely clear what will happen if I do this.
Thanks for this suggestion! Below are some details about how CODEOWNERs interacts with forks. You or anyone else is welcome to open a pull request to document this info.
CODEOWNERS has two primary uses:
- It is used for triggering review requests for a pull request that modifies an owned file.
- It is used to see at a glance who is responsible for a given file.
Pull requests use the version of CODEOWNERS from the base branch of the pull request. (The base branch is the branch that the PR will modify if the PR is merged.) If the repo that you forked from is the base of your PR, then the PR will use the CODEOWNERS file from the repo that you forked from. If your PR is targeting a branch within your forked repo, then the PR will use the CODEOWNERS on that base branch in your forked repo.
When seeing who responsible for a file, the CODEOWNERS for whatever branch you're looking at on whatever repo you're looking at is used:

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.
It feels like it's worth noting something like: "in a fork, the accounts referenced in the upstream file which is the current version in the fork are unlikely to have these permissions, and thus are unlikely to be assigned, but if they have these permissions, then they would be."
A stale label has been added to this issue becuase it has been open for 60 days with no activity. To keep this issue open, add a comment within 3 days.
Maybe I'll look into picking this up in part...
A stale label has been added to this issue becuase it has been open for 60 days with no activity. To keep this issue open, add a comment within 3 days.
Sigh, there's an active PR
A stale label has been added to this issue becuase it has been open for 60 days with no activity. To keep this issue open, add a comment within 3 days.
Is it bad that I only now noticed that because
is misspelled in the note?
I wouldn't have noticed, either, if you hadn't pointed it out. 😆