Meeting minutes?

[baentsch]

Any chance there's going to be meeting minutes posted about the (IMO somewhat "tumultuous") 1st TSC meeting?

For example, I do not recall agreeing on retaining which projects at which maintenance level and by whom -- something that @ryjones has apparently documented (decided without review/feedback?) in 7837a04 -- or what's the purpose of this file/commit?

But then again, I didn't understand many things at that meeting; maybe you can comment, @dstebila ? Or are these things that have been discussed and agreed within LinuxFoundation-registration-only fora (that I do not subscribe to until LF agrees to retain them open for everyone)? If so, at least some notice about those LF decisions , e.g. within the issue meant to host the open discussion about this, would have been courteous by the LinuxFoundation team, so everyone knows what they're up to.

More strange things: I thought @thomwiggers doesn't have the bandwidth any more for Rust while @Martyrshot agreed to look into this. I also don't understand why core is listed as maintainer for some projects: This doesn't make any sense to me ("if everybody is responsible, no-one is"). @claucece as listed with write permissions for boringssl also is somewhat surprising to me. In turn, I am (admittedly more and more disillusioned by the LF actions) maintainer of oqs-provider -- which is not documented. See https://github.com/open-quantum-safe/tsc/blob/main/config.yaml for reference.

[dstebila]

I am unlikely to be able to complete minutes before the end of March due to other commitments. I will try to respond to that and your post https://github.com/orgs/open-quantum-safe/discussions/1731 then.

[claucece]

Not sure about the rest but regarding this point: "@claucece as listed with write permissions for boringssl also is somewhat surprising to me" -> I don't remember asking write permissions, but happy to be removed. Thank you! ;)

[ryjones]

@claucece please file a PR here

[ryjones]

@baentsch that PR was a one-for-one copy of the existing permissions in OQS, nothing more.

[baentsch]

@baentsch that PR was a one-for-one copy of the existing permissions in OQS, nothing more.

All right -- I only checked a single project and here's what it looks like:

Your config:

 - name: oqs-provider
  collaborators:
    oqs-bot: write
    thb-sb: write
  teams:
    core: write
  visibility: public

Github permissions:

--> Doesn't quite look like a one-to-one copy to me, does it?

What's the purpose of this file, anyway?

[baentsch]

I am unlikely to be able to complete minutes before the end of March due to other commitments.

Sorry, @dstebila, I didn't mean to put this burden on you: I honestly was of the opinion that @ryjones or anyone else of the LF guys would do this: They seemed to have run the TSC meeting, so I assumed they'd also do minutes (or not): The style of the meeting was so much more controversial than you ever conducted a meeting that I didn't come to another conclusion than this being an LF meeting (and their meeting style). Take any time you need. I'd be thrilled to see OQS continue the way it was before IBM/LF (really only apparently?) took control.

[baentsch]

Not sure about the rest but regarding this point: "@claucece as listed with write permissions for boringssl also is somewhat surprising to me" -> I don't remember asking write permissions, but happy to be removed. Thank you! ;)

Thanks for this explanation, @claucece . This looks like an internal bookkeeping exercise now and depending on why this file was created, we'll handle internally. Sorry for the traffic in your Inbox. Should you ever feel like (having time to re-start) contributing to OQS, we'd be very happy.

[bhess]

I think that changes to the repo should come with an issue/PR to explain and solicit feedback before they are applied (following the same process as always in OQS). In this case it would help to clarify the purpose of the CODEOWNERS file (is it to publicly document current access rights? is it a new way to do access control? does it document any decision taken?). It would also help to avoid potential side-effects such as documented in #8.

[dstebila]

Fixed by #14