Use CODEOWNERS in all repositories #192
Conversation
snim2
force-pushed
the
rfc/use-codeowners-in-all-repos
branch
from
a76a276
to
07833b9
Compare
|
Thanks Sarah! I really like the idea in principle, I have some practical questions:
|
I think client projects will probably be different to shared repos here, but we do need something more granular than the current structure. For things like the Playbook we probably want to form a new team of people from across the company. GitHub teams can be nested, for example the GovPress team is really the If you look at the settings for the playbook repo and this repo you'll get a good idea of how we're using this feature now.
Not easily. You can see this information from within repositories, but there isn't a simple way to see an overview (I guess because the information is stored inside a file under version control, and not set via the GitHub UI). However, you should get a notification when you are added to a team, and you can set this in
No, but we can see all of our teams. So for some repos this should be simple (for example if there's a |
|
Great idea! To respond to @jdudley1123's questions with my own thoughts...
Perhaps a bit of code somewhere to generate and maintain a list of codeowners across all our repos could cover both of these (and also make sure there are no gaps). |
|
Just to say, the memberless teams may well be for setting up scheduled reminders and are intentionally memberless. Feel free to revisit that. |
| 1. within the `dxw` organisation on GitHub or the equivalent on GitLab, | ||
| 1. not a fork of a repository from outside the organisation; and | ||
| 1. not archived. |
There was a problem hiding this comment.
I suggest this list also has 1. not wholly relating to a client. Client projects MAY use codeowners, but they're also self-managing. This might complicate things with GovPress, though.
There was a problem hiding this comment.
OK, I think you mean something like: 1. where the maintenance of the repository is entirely within the control of dxw, and not (for example) a client.?
There was a problem hiding this comment.
No. I mean things that aren't client projects, because client projects are their own things that have different needs. That's a D+ need anyway.
There was a problem hiding this comment.
OK, that's a little more complex than I'd realised. Maybe it would be a good idea for repos who "should" conform to all of the maintenance RFCs to have a topic set, like dxw-maintenance, which would mean that any automated tools could skip things like D+ client projects?
There was a problem hiding this comment.
Probably easier to tag the non-dxw stuff, but yes.
Is this documented somewhere? |
| environment that | ||
| [assumes good faith](https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith). | ||
|
|
||
| Repositories SHOULD be configured to ensure that code owners review PRs before |
There was a problem hiding this comment.
I'm not sure this should be a SHOULD without a particular need for the owner(s) to agree to a change, particularly with repos where things like minor Dependabot PRs can be confidently approved by a range of people. A MAY is worthwhile to remind people that it's an option though.
There was a problem hiding this comment.
I might even go as far as removing it. The one time we had it enabled on a repo it was painful. Although its probably okay if its just the tech team as a code owner.
| - [ ] Ensure all repositories have | ||
| [topics](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/classifying-your-repository-with-topics) | ||
| set which identify the owner (e.g. `govpress`, `tech-ops`, etc.) | ||
| - [ ] Write a tool to generate PRs to add a default license, `CONTRIBUTING.md` |
There was a problem hiding this comment.
We've done this before. There was definitely interest in turning it into an internal platform which would let us quickly get an overview, which would also align with @Floppy's point about a central "who owns this code" view.
There was a problem hiding this comment.
Yes, I've been looking through that repo. I'm beginning to think we need two things: 1) a relatively regular "audit" of the repos that highlights places where maintenance is needed, and 2) to start using that tool, or something very similar, to automatically resolve maintenance issues, like missing files.
Co-authored-by: Nick Jackson <[email protected]>
|
A very, very brief summary of the above (apologies if anything missed / misunderstood)
There doesn't seem to be any suggestions against the substantive argument that CODEOWNERS is a useful thing? |
|
An interesting view on the topic, where it didn't work out for a company: |
This RFC would require that all active repos make use of GitHub's code owners feature to describe who is responsible for the maintenance of the repo. This is designed to ensure that issues and PRs in shared repos do not stall.