New Access Control criteria - second-party code review #123
Conversation
Signed-off-by: Evan Anderson <evan@stacklok.com>
| Ensure that changes to the project's codebase have | ||
| been reviewed and approved by two distinct | ||
| individuals before being merged. This separation | ||
| of duties raises the difficulty of malicious commits | ||
| being merged into the project's codebase. |
There was a problem hiding this comment.
Do you mean that two reviewers are required, or does the "two distinct individuals" include the person who wrote the change? I think you intended the latter. Not quite sure what I'd suggest to clarify yet, but I'll think about it more.
There was a problem hiding this comment.
Oh, if I'd looked at the implementation, I'd see that you say "at least one approval" :-)
There was a problem hiding this comment.
I'm assuming the person(s) who authored the change implicitly approve of it.
Interestingly, when working in pair authoring setups with co-authored-by, you can sometimes end up needing more than two approvals with the default GitHub approval mechanism. That's really just a "you need other tooling than GitHub" situation (for which things like Prow exist).
I'm happy to accept suggestions on verbiage; I'm not as familiar with what the standard language may be for these types of controls. (I care about the implementation of the control, but almost zero about the naming and standardization...)
As discussed today. This ties in with e.g. OSPS-DO-11 that contributors (and reviewers?) need to be vetted. (Also #119)