Update config.yaml

[baentsch]

That file represents the state of the access as configured in GitHub at the time I created it. If it does not represent the community, or the decisions made therein, please file an issue to document the changes required.

Originally posted by @ryjones in https://github.com/open-quantum-safe/tsc/issues/6#issuecomment-2027251771

As requested: Ensure all (sub-)project roles of contributor- and maintainership are properly represented.

At the least implement https://github.com/open-quantum-safe/tsc/issues/7#issuecomment-2013658258

Then I think @thomwiggers no longer maintains liboqs-rust, right? @vsoftco in turn should be maintainer of all language wrappers @baentsch is maintainer of oqs-provider and liboqs; @thb-sb: Would you want to commit being maintainer in either or just one project, too? @dstebila is no maintainer of oqs-provider but surely of liboqs. All other projects don't have maintainers, AFAIK (which is a problem and should be tackled -- as per https://github.com/open-quantum-safe/tsc/issues/2

Anyone else, please chime in if I forgot about you(r commitments).

[thb-sb]

@baentsch is maintainer of oqs-provider and liboqs; @thb-sb: Would you want to commit being maintainer in either or just one project, too?

I am definitely committed to being a maintainer of oqs-provider. Regarding liboqs, I feel like I haven't done enough work on it to be a maintainer, but I would want to be a committer for now, yes.

Thank you btw @baentsch for updating this file.!

[thomwiggers]

Then I think @thomwiggers no longer maintains liboqs-rust, right?

Yep. I'm currently basically just holding the fort.

[baentsch]

Thank you btw @baentsch for updating this file.!

I definitely will not update the file. This is an LF tool (I don't feel sufficiently motivated or paid to learn :-) and am looking at LF/@ryjones to implement updates as per discussions/decisions documented in this issue.

[dstebila]

That file represents the state of the access as configured in GitHub at the time I created it. If it does not represent the community, or the decisions made therein, please file an issue to document the changes required.

Originally posted by @ryjones in #6 (comment)

As requested: Ensure all (sub-)project roles of contributor- and maintainership are properly represented.

At the least implement #7 (comment)

Then I think @thomwiggers no longer maintains liboqs-rust, right? @vsoftco in turn should be maintainer of all language wrappers @baentsch is maintainer of oqs-provider and liboqs; @thb-sb: Would you want to commit being maintainer in either or just one project, too? @dstebila is no maintainer of oqs-provider but surely of liboqs. All other projects don't have maintainers, AFAIK (which is a problem and should be tackled -- as per #2

Anyone else, please chime in if I forgot about you(r commitments).

This list of changes looks correct to me.

[baentsch]

@ryjones are you willing to implement these changes as part of your contributions to OQS or do you expect someone else to do this? If the latter, whom and how (documentation)?

[ryjones]

@baentsch the way to do it would be to file a PR against the config to make it reflect what the community wants. Here is an example.

[baentsch]

@dstebila I know you have other priorities than this project particularly as the term starts and most likely don't (have time to) read my longish arguments, but in this case, please make an exception. I promise I (already started) to not tag you anymore on other or concrete technical matters if not really necessary.

This issue didn't make progress over the past few months and seems to be at the core of different problems. As much decision-making seems to have moved away from GH and on to meetings (which I still think is wrong, slows down the project substantially, leads to sub-optimal decisions and systematically disadvantages non-native speakers --maybe another topic of its own?) this is to request we put this on the agenda for the next meeting.

To be agreed should be things on two levels:

Basic principles:

This is to propose we agree that OQS project access rights control, i.e., config.yml maintenance, adheres to these principles:

• Two approvals by TSC members are required to merge a change to this file; one approval is sufficient for other changes to the TSC GH repo
• GOVERNANCE.md files' contents in sub projects (where present) shall never be overruled in config.yml
• The logic in config.yml shall be the same across sub projects (see next level) -- if not possible, exceptions should be documented in the file so everyone can understand the rationale later on
• LF admin overrules to these principles must be openly documented as to the reason of the overrule

Second, concrete implementation:

As per (slightly modified) original proposal by @SWilson4 this proposal is to agree that for every sub project the same rules apply:

• sub project maintainers have admin rights on the sub projects
• OQS and sub project release managers have maintainer rights on the sub projects
• sub project committers have write rights on all branches of the sub projects
• sub project contributors have write rights on all branches except main on those sub projects
• OQS and sub project triage actors have triage rights on all branches of the sub projects
• OQS maintainers and LF admins have admin rights on the organization (e.g., org-wide secret management) as well as maintenance rights on the team configurations

The rationale for all this is to

• enhance project security and accountability (e.g., less risk of further least privilege violations)
• improve openness & understanding (returns control to each sub project community)
• get clarity on roles and responsibilities
• reduce (also key person) risk
• support smooth releases
• ease maintenance

The only truly new concept this proposal introduces is the notion ("team") of release managers. IMO those should be the OQS maintainers (you and me) as well as 100% committed (e.g., employed) core team members (Spencer and Pravek). This would allow us to return to the more efficient method of doing releases without introducing undue risks, again, incl. key person risk.

Should anyone other on or off the @open-quantum-safe/tsc read this, please weigh in on this even before the meeting with comments/change suggestions, etc: I firmly believe that open discussion outside of meetings gets better results than snap decisions e.g., because one "has to run to the next meeting" or misunderstands a verbal cue.

Particularly also tagging @ryjones for input as you (unlike me) know the syntax and semantics underlying this file as well as the interaction with CODEOWNER files and piece-part access controls required, e.g., during releases.