Open baentsch opened 4 months ago
@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.!
Then I think @thomwiggers no longer maintains liboqs-rust, right?
Yep. I'm currently basically just holding the fort.
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.
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.
@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)?
@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.
@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:
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:
The rationale for all this is to
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.
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).