New Access Control criteria - second-party code review #123
Conversation
Signed-off-by: Evan Anderson <[email protected]>
baseline.yaml
Outdated
| 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...)
Co-authored-by: David A. Wheeler <[email protected]> Signed-off-by: Evan Anderson <[email protected]>
| @@ -192,6 +192,34 @@ criteria: | |||
| scorecard_probe: | |||
| - # TODO | |||
|
|
|||
| - id: OSPS-AC-08 | |||
| maturity_level: 1 | |||
There was a problem hiding this comment.
| maturity_level: 1 | |
| maturity_level: 3 |
There was a problem hiding this comment.
@david-a-wheeler Can we split the difference and say lv2?
I've been on a couple 2-3 person projects including one right now where we enforce this and—yeah— it slows things down, but it dramatically reduces the defects we introduce.
|
This criterion cannot be met by 1-person projects. The vast majority of OSS projects are 1-person projects (per TAC issue 101), and this is not under the control of maintainers. Maintainers can take steps to make it easier to join a project, and they should, but maintainers don't decide how others spend their time. For projects with 2-3 developers who are not doing this as part of their daytime work, requiring second review can greatly slow development. You're waiting for the other guy to be available, which may be next month or maybe the month after that. Maybe. Don't get me wrong, I'm a huge fan of the advantages of review before merging. I wrote a book on Software Inspection (a form of multi-person review). But while describing it is easy, and enforcing this is relatively easy, that doesn't make extra people available for the vast majority of OSS projects. If the intent is that this baseline cannot be applied by the vast majority of OSS projects, then that needs to be made clearer, e.g., "this baseline is only intended for larger projects with multiple funded developers" or whatever is the intent. We should make that clearer if that's the intent. |
I totally agree! There are a number of other level-1 criteria that seemed biased towards multi-maintainer projects, for example OSPS-DO-01 (public discussions about proposed changes), OSPS-AC-02 (lowest available permissions), and OSPS-AC-03 (require pull requests). |
As discussed today. This ties in with e.g. OSPS-DO-11 that contributors (and reviewers?) need to be vetted. (Also #119)