Create CODEOWNERS

[ryjones]

No description provided.

[baentsch]

Why are you requesting Review and then merge without one @ryjones ? What are you trying to achieve here? I follow projects to stay on top of things, but without explanations why things are happening this is a bit hard and I'm tempted to unfollow TSC now...

IMO the sequence that usually gets everyone on board (consensus) is Issue->PR->Review->Merge (by more than 1 person executing all steps :-). Looks like you guys at LF don't do it this way, so some explanation to help me adapt to how you run things (t)here would be appreciated.

[ghost]

I have to say that I'm also surprised.

[ryjones]

if you look here you will see no changes were applied to the org.

[baentsch]

if you look here you will see no changes were applied to the org.

It's probably obvious to you what is shown there -- I don't understand it. Are you saying some tool is auto-generating PRs, Review requests and merges now, @ryjones ?

[ryjones]

I said none of that. The merged PR resulted in no changes to the org.

[baentsch]

Why then did you request a Review of us?

[bhess]

Hi @ryjones, there were some questions raised about this PR in yesterday's OQS developers call. Could you please provide an explanation about the purpose of the CODEOWNERS file? For example, is it to publicly reflect the current access rights in the org? Or is it a new way to do access control in OQS?
Please also be aware of the review and approval process we have in OQS before merging PRs. It would be much appreciated. Thanks.

[baentsch]

@ryjones Going forward, please document your explanations publicly and not only in mailing lists that LinuxFoundation does not commit to retain for public consumption.

To do it for this issue, copying your mail here:

With regard to your questions on [PR6](https://github.com/open-quantum-safe/tsc/pull/6):

    Could you please provide an explanation about the purpose of the CODEOWNERS file?

 
The [CODEOWNERS](https://github.com/open-quantum-safe/tsc/blob/main/CODEOWNERS) file limits access to editing that one file to me and members of the TSC.
The [function of the file is outlined here](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners). It also means that the people in that list will be pinged on 
 

    For example, is it to publicly reflect the current access rights in the org? Or is it a new way to do access control in OQS?


Neither. It reflects access to that one file in that one repo. It is a GitHub feature.

[CLOWarden](https://github.com/cncf/clowarden) is a service provided by CNCF for managing org and repo access.
The [config.yaml](https://github.com/open-quantum-safe/tsc/blob/main/config.yaml) file CLOWarden uses is the file covered by the CODEOWNERS file.
CLOWarden provides a way to manage permissions to orgs and repos, and provides a public audit of changes. [Here is an example](https://clowarden.io/audit/?organization=hyperledger-labs&page=1).

    Please also be aware of the review and approval process we have in OQS before merging PRs. It would be much appreciated.


Mea culpa.

Ry Jones
Senior Community Architect
[Book a meeting](https://fantastical.app/rjones/hyperledger) [Chat on Discord](https://discord.com/servers/hyperledger-foundation-905194001349627914)

I appreciate you're employed by LinuxFoundation and accordingly, follow the orders of those companies; I also guess you have to juggle more projects than just OQS; nevertheless, it would be very much appreciated if you could explain rationale and mechanics of what you're doing also to the non-LF OSS community so we can follow and not spend hours wondering, barking up the wrong tree or just despairing. Thanks in advance!

[baentsch]

Oh, and I still don't understand the contents of the config file that @ryjones added completely without PR: Its contents IMO do not reflect decisions of the TSC (that I recall) nor are representative of OQS' current maintenance and contributor state. I think this file could be used to implement whatever the TSC decides on #2, but I'm not sure: Allow me to reiterate the request for #7 @dstebila which might explain all of this (maybe this did get discussed/agreed and I just "didn't get it" -- along the same vain as the OQS-wide activation of DCO: I understand OQS no longer is an OSS project but an LF one, so they slap on their procedures -- but informing the community about it ahead of time would be courteous).

[ryjones]

Oh, and I still don't understand the contents of the config file that @ryjones added completely without PR: Its contents IMO do not reflect decisions of the TSC (that I recall) nor are representative of OQS' current maintenance and contributor state. I think this file could be used to implement whatever the TSC decides on #2, but I'm not sure: Allow me to reiterate the request for #7 @dstebila which might explain all of this (maybe this did get discussed/agreed and I just "didn't get it" -- along the same vain as the OQS-wide activation of DCO: I understand OQS no longer is an OSS project but an LF one, so they slap on their procedures -- but informing the community about it ahead of time would be courteous).

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.