Roles of maintainers & contributors

[baentsch]

The core sub projects, liboqs and oqs-provider had well-defined roles, responsibilities and expectations as documented in their respective GOVERNANCE.md files.

As part of their take-over, the LF/PQCA team has chosen to disregard and invalidate those files and rules: Maintainers for example don't have administrative GH rights any more, leading to all kinds of new discussions and complications, e.g., when doing releases.

Thereby (?) and at least in my mind there does not seem to exist a well-defined understanding as to which responsibilities and obligations PQCA assigns to contributors and maintainers and how these map to GH rights.

This issue is to propose a discussion as to what tasks, responsibilities and rights are to be assigned to contributors and maintainers. This should serve to let any present and future contributors and maintainers see what are the project's expectations towards them and also inform the (automated) setting of GH rights. If no discussion is wanted, this issue is to request the LF/PQCA team to post a documentation as to what they want maintainers and contributors do so present contributors and maintainers can adjust their expectations or contribution level accordingly.

For example, are maintainers in the PQCA sense

• still expected to know the code of a specific project inside-out (i.e., be active contributors) or not, i.e., have more of a "management" function?
• expected to do releases or should that be done by different people?
• expected to review & fix security vulnerabilities or is that to be delegated to people specializing in such task but not necessarily knowing the code?
• expected to review PRs and discussion entries or is that to be delegated to yet other team(s)?
• still to be attributed with the GH "maintainer" label (AFAIK externally understood as carried by people who know the code) or does that need to be reconsidered (IMO on a per-sub project basis)?

As usual, any input, e.g., pointers to existing documentation on these roles very welcome.

[anvega]

As a newcomer to the project, I've noticed the following about CODEOWNERS in the OQS repositories:

1. liboqs: The CODEOWNERS file (liboqs/.github/CODEOWNERS) outlines ownership as follows:

   * @dstebila
   /.circleci @baentsch
   /scripts/copy_from_upstream @baentsch @bhess
   /src/common @dstebila
   /src/kem/bike @crockeea
   /src/kem/frodokem @dstebila
   /src/kem/kyber @jschanck @bhess
   /src/sig/dilithium @bhess

2. oqs-provider: The CODEOWNERS file (oqs-provider/.github/CODEOWNERS) simply lists:

   * @baentsch 

Obviously, CODEOWNERS don't necessarily have admin rights; those are managed separately in the repo settings and org-level permissions. This approach differs from other LF projects, where CODEOWNERS are often defined in settings.yml and config.yaml files, and tools like CLOWarden For example:

• OQS TSC: https://github.com/open-quantum-safe/tsc/blob/923acd7cf661e08e9a40031aa1a879d0d6fe8ff1/config.yaml
• PQCA: https://github.com/PQCA/governance/blob/main/config.yaml

In my experience, the LF always advocates for open governance, which means they dictate guidelines but every project organizes its own.

The release friction sounds like a significant concern that needs attention. Tagging PQCA staff @hartm, @mkdolan, @ryjones, and @tbenzies for resolution.

[baentsch]

Thanks for your fresh opinions, @anvega ! Dare I ask how extensive your LF experience is as

In my experience, the LF always advocates for open governance, which means they dictate guidelines but every project organizes its own.

this is not what I've witnessed so far: I experienced LF (staff) enforcing mechanisms that projects then have to cope with. GOVERNANCE.md and CODEOWNERS files are disregarded and community members, incl. maintainers have to beg for permissions -- provided they know which ones are needed and justifiable (i.e., might get granted).

oqs-provider: The CODEOWNERS file (oqs-provider/.github/CODEOWNERS) simply lists:

• @baentsch

That's indeed a problem I'm trying (probably failing) to get across to the LF staff: oqsprovider indeed is "special" in that it is a project I created and still "own" (last edited/have to review) about 80% of all running code and 95% of all generator code thus leaving me with 100% of (what I understand to be as) maintenance obligations. Removing all GH admin privileges under such conditions does create lots of friction (and frustration and de-motivation).

No doubt, the project could benefit from refactoring (see https://github.com/open-quantum-safe/oqs-provider/issues/375), e.g., to split out hybrid KEM and composite SIG code sections (the main non-@baentsch code pieces), also to make CODEOWNERS more granular (and create a wider base of support). Grateful to @thb-sb to be willing to take a stab at that.

liboqs: The CODEOWNERS file

This file also needs an update as it doesn't reflect current contribution levels and recent additions. Thanks for highlighting it! Created https://github.com/open-quantum-safe/liboqs/issues/1843 to fix/track.

The release friction sounds like a significant concern that needs attention

I don't think so: a) I documented how contributors can do releases and b) @ryjones pointed to examples as to how I might request required permissions to do things more easily. However, I don't know which those would be as I don't know what are all the things expected of me. And I'm too old (i.e., consider my time is too short :) to keep coming back begging for permissions every time I receive another statement (from LF staff) "we expect maintainers to xyz".

So this is what this issue is all about: Have one place where contributors and maintainers can understand what in this LF-controlled project they are expected (and in consequence will be permitted) to do.

If you'd know of such "maintainer & contributor obligations" (that are used/accepted in the "LF-verse"), please by all means, share them here @anvega : It surely would help me.

[dstebila]

Does CODEOWNERS actually enforce permissions? My understanding was that CODEOWNERS was used to trigger automatic review requests, but these were advisory, in the sense that any sufficient number of reviews was enough to permit merging.

[anvega]

While CODEOWNERS is primarily a review tool, I've seen it used by LF Staff as part of reviewing preexisting structures to inform and model access rights during project transitions.

I don't have enough context or privy to conversations of what ultimately you want to have in place but it seems to me what you had in place before worked, and there's a desire to mirror that effectiveness while accommodating for growth. Maintainers are the lifeline of a project, so it's crucial to ensure predictable release velocity. The current release process appears onerous, with multiple PRs required, adding unnecessary time and toil.

Given that you and Douglas have successfully carried out releases before and wish to onboard others, there should be a streamlined way to do so. The current setup also introduces key person risk. Ideally, you want a diverse group of maintainers capable of cutting releases in case someone is unavailable. It's still fine if there's a designated "release" team per cycle; projects like Kubernetes have a rotation for this.

Perhaps a release policy authored by you in the TSC could define what the project needs to operate sustainably for the project staffers to accommodate. This could help balance efficiency with necessary oversight and ensure the project's ongoing success.

[baentsch]

The documented (currently only in oqsprovider) release procedure exactly did away with "key person risk". Everyone with Commit rights can now do releases.

But I wonder whether this is the real problem ( @ryjones now seems to be a "key person" everyone has to request for help or permission): As you correctly point out, things worked well before LF took over OQS. What has changed since is that the 2 "key persons", coincidentally also the maintainers and responsible for more than 50% of all code, have practically ceased to technically contribute. For Douglas I can only speculate, but I guess all the LF overhead meetings have siphoned off the time for actual technical work that he could contribute to OQS next to his main/day job. I had fortunately decided from the start to not be involved in any of the PQCA management entities but the lack of help received from the LF team (just one tiny point in case: their feedback on this issue) stopped me from working effectively in the limited environment they created. About a year ago, when IBM and LF approached us I very probably made a mistake: I told them that I will not cough up the LF membership fee from my personal savings such as to be allowed to continue working on this software (in the case of oqsprovider, something that I created from scratch). Ever since, the words and the actions of LF staff towards my person diverged (e.g., "we also help non-LF participants") -- and admittedly, also my willingness shrank to work around their possible time- or resource constraints wrt "OQS matters".

So my question to you @anvega : Are you aware of any other LF project where someone not affiliated with an LF member is a maintainer? Maybe such people could help resolve this issue?

[anvega]

I want to acknowledge that PQCA might have specific bylaws that I may not be aware that I want to be mindful of, but I still believe we can advocate for positive changes in the collective interest.

From my understanding, LF owns the trademark, but governance of the project is left to the project's community leadership. Even some LF Community Management tools are designed to provide maintainers with admin rights if necessary: LF Community Management FAQ.

For example, the SPIFFE project that I have visibility over the setup has six owners at an org level. One of these is the Linux Foundation account, and the rest are five members of the steering committee. Additionally, there are 26 people with varying levels of access, including seven enterprise owners who have complete control over the CNCF GitHub organization. Other members have admin permissions specific to certain repositories. There are seven members spread across five teams: two core projects with maintainers, one team responsible for documentation, and another for a collection of smaller projects.

You can also see how another project approached reducing their "bus factor": https://github.com/cloud-custodian/cloud-custodian/issues/7149

The CNI project has governance guidelines stating, "Maintainers will be added to the containernetworking GitHub organization and the GitHub cni-maintainers team, and made a GitHub maintainer of that team. After 6 months, a maintainer will be made an 'owner' of the GitHub organization" https://github.com/containernetworking/cni/blob/main/GOVERNANCE.md

Similarly, Envoy Proxy outlines different levels of maintainer access for individuals from various organizations: https://github.com/envoyproxy/envoy/blob/main/GOVERNANCE.md

These examples from well known projects show that sharing responsibilities with trusted maintainers, who started the project, can help mitigate risks. You clearly care about the project's best interests. No one is more concerned about the risks and security rsiks than those directly involved over the years.

[baentsch]

All very good pointers, Thanks @anvega ! Just yesterday, in the course of a "little access permissions lapse", an(other) interesting and simple to implement new proposal has been made by @SWilson4 (see https://github.com/open-quantum-safe/tsc/pull/62#issuecomment-2299723447):

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.)

Feasible/sensible (&generally acceptable to LF admin) in your eyes, @anvega ? I'm not enough of a GH&LF access permissions expert to judge this (and am frankly overwhelmed by the amount of options).

You clearly care about the project's best interests. No one is more concerned about the risks and security rsiks than those directly involved over the years.

That is a statement I (unsurprisingly :) fully support. It'd be nice if the IBM/LF team now controlling PQCA&OQS could come around and embrace this view, too. In my impression, though, they are completely driven by "big project" thinking/experiences and applying those (often not really suitable, IMO overly heavy-handed) processes and procedures indiscriminately on OQS, making things so convoluted that this arguably leads to violations of governance security like the least privilege violation in https://github.com/open-quantum-safe/tsc/pull/62:

I honestly think that the (still) very few people effectively contributing and maintaining are simply overwhelmed with LF process and procedure (and/or are getting too little help and/or have too little time to understand/work around it) to always make correct judgement calls.

Yes, I agree, things need to change if there is more diversity and size (e.g., in knowledge, interest and viewpoints) within the contributor and maintainer base -- but I do not see this having been changed substantially enough since the LF take-over to warrant applying all LF "big project" rules to OQS already now. A quandary, I know, but hence this issue....