New teams #62
New teams #62
Conversation
Signed-off-by: Ry Jones <ry@linux.com>
Validation succeeded✅ The proposed configuration changes are valid!Configuration changesDirectory
Github
🔸 Please review the changes detected as they will be applied immediately once this PR is merged 🔸 |
|
@baentsch please review |
There was a problem hiding this comment.
As far as oqsprovider is concerned, this seems to go from too few permissions for too few people to too many permissions for too many people. Is there no way to model exactly what's documented in GOVERNANCE.md (unless answers to #45 contradict that)?
Reconciliation completed✅ The reconciliation completed successfully and all changes have been applied across the services!Changes appliedGithub
|
|
@dstebila Can you please explain why you think it's a good idea to give admin rights to oqs-provider to everyone with a "code-owner" designation? If I'm not wrong, you now approved all contributors to have even more privileges than normal GH maintainer(s): This is IMO the exact opposite of the least privilege concept and also a direct contradiction to GOVERNANCE.md. The latter irks me even more than the security downgrade: Why did I write this in the first place if not to provide some "guard rails" protecting the code? |
You're right. What level of access should the codeowners team have? |
Codeowners in my eyes are Contributors and should have the same rights. But I already don't understand the separation of "codeowners" and "contributors" to begin with. This only exists in oqsprovider, no-where else: Why? In general, I think the whole file is a big mess, completely un-structured, not orthogonal across projects and not in line with GOVERNANCE.md files where present. Yes, it did become better recently with the introduction of teams (though not consistently, see e.g., boringssl), but still, I don't understand why there's not a simple, orthogonal/per-project "maintainers", "committers", and "triage" category with admin (or maintain, if no sufficient trust exists), write, and triage rights, respectively as per our governance rules? Related question: Why is there a need to sometime have "admin" and sometime "maintainer" and sometime both teams per sub-project? Then: Why is there absolutely no documentation (e.g., as to exceptions to the "orthogonality" rule)?
OK, the latter is probably just my problem since the don't-trust-@baentsch principle started in April when all my permissions were withdrawn, so probably unrealistic/unacceptable to LF. Nevertheless I think it would be a logical principle if the community and not LF admins should control the project('s access rights). Conceptually, what about an OQS-maintainers team listed as maintainer for all sub-project's maintainer team lists? In my "ideal" world, every person would be listed in as few teams as possible, ideally just one -- every additional use of a specific person's ID should be accompanied by a comment. This way, it becomes obvious when specific persons become "risky" (in terms of "key person risk") and the community aware of the need to do something about it. As usual, sorry for the long text & disregard as you see fit. |
I actually created the "oqs-provider-codeowners" team here so as not to override the |
|
Perhaps our Committers ought in fact to have "maintain" privileges, Maintainers ought to have "admin" privileges, and Contributors (incl. people in the codeowners file) ought to have "write" privileges? (See here for documentation on perms.) |
Creating teams for repos