chore: put collective ownership on most CODEOWNERS #2788
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2788 +/- ##
==========================================
- Coverage 60.83% 60.82% -0.02%
==========================================
Files 563 563
Lines 75169 75169
==========================================
- Hits 45730 45720 -10
- Misses 26072 26077 +5
- Partials 3367 3372 +5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
Just to set expectations upfront: @gnolang/devrels are not codeowners of the docs since some time back - check out this comment. However, I don't mind providing inputs. |
|
I would suggest adding |
| # - Directories and files which are owned by one specific user X are to be | ||
| # interpreted as "primarily maintained by X". Any significant changes to | ||
| # that given code should be reviewed by X; as if it were another repository | ||
| # where X is the primary developer. However, ownership here can be ignored if |
There was a problem hiding this comment.
Should we suggest to the individual code owner to unassign themselves if the change is small enough?
There was a problem hiding this comment.
They can, but it's labour, and I'm not sure github won't reassign them anyway.
…/gno into dev/morgan/codeowners-but-simple
This PR comes following a discussion in today's "review meeting", where we talked about our current approach to ownership.
One aspect which was talked about was that the current set-up for CODEOWNERS is very "noisy". Opening up a PR often entails tagging many people and teams for review. To try to overcome this, I removed most rules which tried to find "exact people" to own a piece of the code, in favour of collective ownership on the
tech-staff,security,devrelsanddevopsteams, depending on which part of the code is interested.I wrote a few lines explaining the differences between assigning a directory to a team, a person, or a team + person, and how the CODEOWNERS file should be interpreted. I wrote them trying to match the practical implications of the CODEOWNERS file (= who gets picked in the requested reviewers) with the "social" / organizational implications.