Create a voting procedure for the OQS TSC

[dstebila]

An action item from our March 2024 TSC meeting was to create a voting procedure for the TSC.

The voting procedure we come up with will need to respect the OQS Technical Charter as well as the ideas reflected in the liboqs and oqs-provider governance documents; those two documents currently disagree on a few matters (e.g., what constitutes quorum for electronic votes), in which case the Charter would prevail unless we amend it. Additionally, the TSC operates according to Robert's Rules of Order, which provides several mechanisms for voting.

As I see it, we will have two types of things to vote on: general matters, and matters involving people (elections, additions/removals from TSC). I make this distinction as Robert's Rules provides the option for elections to be done using either public or secret ballot.

For voting on general matters, my proposal would be:

• Motions can be proposed either at a meeting or electronically on Github by opening a clearly labeled issue/pull request in the TSC repository.
• Motions can be voted on either at a meeting or electronically on Github. The Charter lays out the quorum/passing requirements for such votes (at a meeting: quorum is ≥50% of TSC voting members, passed by a majority vote of those in attendance; electronically: passed by a majority vote of TSC voting members). We can use built-in Github mechanisms for voting (thumbs up/thumbs down), or there are dedicated Github-based voting mechanisms like gitvote.

For voting on matters involving people (e.g., elections), the TSC should decide whether we want those types of votes to be done using public or secret ballot. If public ballot, then we could just use the same procedure as for normal matters. If secret ballot, then we should identify an online voting mechanism we want to use, such as Helios voting which the IACR uses for its electronic elections.

As we will have the option of voting on things both in meetings and electronically, we'll have to figure out which we actually prefer to do. I think this will depend on how our TSC meeting culture develops -- do most people show up, do we have enough time in advance to think and enough time in meetings to discuss and make a well-informed vote during the meeting, or do we want the extra time that comes from being able to reflect and vote afterwards, albeit at the cost of potentially moving slower. I think I'd wait a few months to see how our meetings develop.

@open-quantum-safe/tsc and others, please feel free to discuss here in advance of our next meeting.

[baentsch]

My personal experience in the first TSC meeting was one of "being rolled over" (as documented here and here). This may have to do with my lack of mastery of spoken English or knowledge of "Roberts Rules" or the meeting happening late in my day (I'm an "early bird").

On this experience alone, but also based on my beliefs in "openness" I'd suggest to avoid "decisions on the spot" or "attendance-focused decision making" and do decision-preparation and -taking openly and online such as in this case (thanks @dstebila for bringing this up in this way!).

To the concrete topics above, my opinion is that

• Secret Ballots should never happen in an Open Source project
• Decisions in a global OSS project should never only be taken by (a majority of) the people having the money to attend physical meetings or the "good fortune" to be wide awake or have a higher mastery of the language while the meeting takes place -- particularly as all of this can be gamed by the meeting set-up.

It is obvious that this may

• slow down decision-making
• require more effort (to consider and respond to other's opinions voiced outside of meetings)

In turn, though, decisions and their implications thus should be

• more well thought-through/be of higher quality
• more well documented for posterity (and/or easier to reconsider when key decision facts --that are then openly documented-- change) allowing faster action then

This therefore proposes to change the LF-provided charter to

• not permit voting at meetings but require online voting (open for sufficient time)
• ban secret voting to enable personal responsibility-taking for decisions
• use meetings only to exchange opinions, possibly introducing and explaining motions but always document in minutes those motions and opinions openly for non-attendees (or people asleep during the meeting :) to ponder before making their decision

I firmly believe there is time in an OSS project to come to generally accepted/acceptable decisions: We're not talking about life-or-death decisions that need to be taken in an instant.

[christianpaquin]

As we will have the option of voting on things both in meetings and electronically, we'll have to figure out which we actually prefer to do. I think this will depend on how our TSC meeting culture develops. [...] I think I'd wait a few months to see how our meetings develop.

That sounds reasonable to me; it feels a bit early to lock down things until we have a chance to (practically) understand the nature of the decisions to make in the TSC vs. the ones that will continue to happen in the technical OQS meetings.

[baentsch]

it feels a bit early to lock down things

Well, LF has locked down things in the TSC charta they prescribed to prevail and they, particularly IBM if memory serves, used this to drive the first TSC meeting in the way it was done.

until we have a chance to (practically) understand the nature of the decisions to make in the TSC vs. the ones that will continue to happen in the technical OQS meetings

I'd actually be fine with this: Completely sideline the TSC as an LF entity and continue to discuss all topics that LF doesn't want to hide (security and budgeting) in the original meeting format driven by technology and contributions and not by politics.

[christianpaquin]

I'm actually ok if administrative votes use close ballots, as long as they can be verified (using e.g. helios). I strongly support conducting all technical decisions openly, given all stakeholders proper review time.

[baentsch]

I'm actually ok if administrative votes use close ballots

What do you term "administrative votes" and what are "close ballots"? How does this work?

as long as they can be verified

Absolutely agree: This (un-verifiability of voting) was the biggest "turn-off" to me personally in the first TSC meeting: Some LF person announcing a ballot result putting exactly that LF company in (co-)chair position that initiated the LF take over of OQS: It felt like the completion of a hostile take-over. With this, I completely lost trust in the openness of LF, the sincerity of the people voting and in the open and mutually respectful cooperation that existed in OQS before.

@hartm, fyi: @christianpaquin with the addition of this single word ("verified") straightened out what the LF charter terms you quoted here couldn't:

Your charter states:

The output of all Project discussions, proposals, timelines, decisions,
including voting results and status should be made open and easily visible to all.

If it stated instead

All Project discussions, proposals, timelines, decisions,
including verified voting results and status will be made open and easily visible to all without limitation.

I trust you see the differences, @hartm: This way, LF no longer can
a) decide which voices/opinions to redact out (by publishing only the "output")
b) create voting results it likes (by publishing only the "results" it likes as done here)
c) delete discussions in the future (by removing access to archives)

I strongly support conducting all technical decisions openly, given all stakeholders proper review time.

Thanks!

[pi-314159]

I support

1. all matters should be publicly disclosed for a period of time (such as one month) before the vote,
2. the voting window should be sufficiently long (such as one week), and
3. disclose voting results.

Additionally, currently only Committers can vote. I think it could be extended to Contributors (perhaps with the voting power reduced to 50%).

[hartm]

Absolutely agree: This (un-verifiability of voting) was the biggest "turn-off" to me personally in the first TSC meeting: Some LF person announcing a ballot result putting exactly that LF company in (co-)chair position that initiated the LF take over of OQS: It felt like the completion of a hostile take-over. With this, I completely lost trust in the openness of LF, the sincerity of the people voting and in the open and mutually respectful cooperation that existed in OQS before.

@hartm, fyi: @christianpaquin with the addition of this single word ("verified") straightened out what the LF charter terms you quoted here couldn't:

Your charter states:

The output of all Project discussions, proposals, timelines, decisions,
including voting results and status should be made open and easily visible to all.

If it stated instead

All Project discussions, proposals, timelines, decisions,
including verified voting results and status will be made open and easily visible to all without limitation.

I trust you see the differences, @hartm: This way, LF no longer can
a) decide which voices/opinions to redact out (by publishing only the "output")
b) create voting results it likes (by publishing only the "results" it likes as done here)
c) delete discussions in the future (by removing access to archives)

In the long run, it is the community doing the recording and making this information open to the public, not the LF. Additionally, in the OQS project, it will be the OQS TSC chair who handles voting, not the LF. The LF may help the PQCA TAC chair if the chair wishes (some projects do this, some don't), but the TAC chair can also handle things themselves if they like.

You all are also free to pick whatever voting process you like. I wouldn't suggest ruling out closed votes in your charter, but you can always run closed votes with something like Helios (or any other cryptographically secured online voting platform) if you like; Hyperledger, for instance, typically runs elections with Helios. That being said, I think you will find it very inefficient if you bind yourselves to run even extremely non-controversial votes in complicated ways.

As far as your charter suggestion goes, to my knowledge (and please correct me if I'm wrong and missing something), OQS isn't currently compliant even with the existing charter. For instance, I can't find meeting minutes or meeting recordings of the weekly technical OQS discussions, which would certainly be required by the text of this charter. We are going to work on fixing this (including hopefully setting up an automated zoom recording that posts meetings to youtube), but for now, I think there is a lot of work to be done.

I would worry that your charter change would place too much of a burden on the community. Typically it's hard to find folks who want to take meeting minutes anyway, and requiring every discussion or decision to have extremely detailed minutes will be a burden on small working groups, for instance. Remember, it is ultimately you all that will need to do this. The community will decide what to share and post and output, not the LF.

Thanks again for everyone's time!

[hartm]

all matters should be publicly disclosed for a period of time (such as one month) before the vote,

This will probably make it impossible to get much done. Something that captures the essence of this but wouldn't be so onerous would be to require the chair to send out an agenda X days (say, 3) before the meeting with all of the items up for a vote on it.

Douglas already sends out great agendas for the technical meeting, so hopefully this wouldn't be too much of an ask from a practical perspective.

[baentsch]

Remember, it is ultimately you all that will need to do this. The community will decide what to share and post and output, not the LF.

You all are also free to pick whatever voting process you like.

Wow -- this is all news -- but great news-- to me: So far, nearly each and every change I proposed to the TSC charter was nixed by LF with either of the statements "we never do it that way" or "we always do it that way". Had you made the statements above earlier, I'd have way fewer grey hairs than I grew due to LF's statements and actions so far.

In this case, let's bring the charter in line with what's documented in github and keep operating how we always did before LF appeared.

Let's also change the "openness" statement to the proposed

All Project discussions, proposals, timelines, decisions,
including verified voting results and status will be made open and easily visible to all without limitation.

This would immediately alleviate all my concerns.

[hartm]

Wow -- this is all news -- but great news-- to me: So far, nearly each and every change I proposed to the TSC charter was nixed by LF with either of the statements "we never do it that way" or "we always do it that way". Had you made the statements above earlier, I'd have way fewer grey hairs than I grew due to LF's statements and actions so far.

I'm glad we are finally getting things clarified. Some things are flexible (voting, documentation style, etc.) and some things are unfortunately not due to legal constraints (DCO, licensing, etc.).

In this case, let's bring the charter in line with what's documented in github and keep operating how we always did before LF appeared.

Our goal has never been to dramatically change how things operate. We just want to make sure there enough guardrails around the project so that users and contributors are protected legally, the community remains open and welcoming, and everyone can build secure production code.

You should also realize you can have governing documents outside the charter. You can pass a voting policy, for instance, that doesn't need a charter update. In general, I'd encourage you to document other policies like what you have in the github formally, but outside the charter. For legal reasons, it's good to keep the charters concise and compact.

Let's also change the "openness" statement to the proposed

All Project discussions, proposals, timelines, decisions,
including verified voting results and status will be made open and easily visible to all without limitation.

This would immediately alleviate all my concerns.

Changing the charter to this might make it difficult from the project to stay in compliance with the charter, as I mentioned in my previous comment, and this can cause issues. Instead, I'd suggest you think about what this concretely means (recording meetings and making them public, taking meeting minutes, etc.) and document that. Then you can pass that as a separate policy of the TSC. This would also make it clear exactly what folks should do and will remove any ambiguity about best practices. The charter is deliberately left a little bit ambiguous here, as it is up to projects to determine exactly what is meant.

Does this make sense? Thanks again for your time.

[baentsch]

Additionally, currently only Committers can vote.

This is how it is written, but actually not quite how it is: Currently, only TSC members can vote. This membership --IMO unfortunately-- is not aligned with actual technical activity, let alone the "Committer" designation as documented: We have dedicated Maintainers (@dstebila @baentsch @thb-sb), Committers (@bhess @christianpaquin @ashman-p ) as well as non-Contributors (@brian-jarvis-aws ) in the TSC. In turn, and as a significant omission, we do not have another maintainer (@vsoftco) in the TSC.

I think it could be extended to Contributors (perhaps with the voting power reduced to 50%).

This would make things pretty unwieldy: Why 50%? Should someone that just made a minor text contribution a long time ago have the same voting power as someone delivering a major feature and keeping on contributing? If the TSC should represent the technical community, I'd suggest having only Maintainers to have voting rights in the TSC: According to the definition those are people that consistently help the community with contributions as well as reviews and Q&A, i.e., consistently documented technical acumen. From that perspective, we could argue @pi-314159 should be on the TSC as maintainer of oqs-boringssl. I'd surely also invite @brian-jarvis-aws to commit being maintainer of oqs-opensshand @bhess as a representative of another integration company could commit to be maintainer of oqs-demos. This way, TSC representation and technical contribution activity would be much better aligned.

[pi-314159]

This would make things pretty unwieldy: Why 50%?

The main idea here is to allow more people to vote. Because Contributors haven't made much contribution, it's probably inappropriate for Contributors and Committers to have the same voting power. We can also restrict which Contributors are allowed to vote, for example, Contributors who have made contributions in the past 6 months. Contributors who make smaller contributions should be allowed to vote because likely they are users who familiar with the project; they can to some extent reflect user needs.

These are just some initial thoughts.

[hartm]

I'd suggest having only Maintainers to have voting rights in the TSC

This is how the vast majority of projects that I work with start out. Once there are so many maintainers that meetings become unwieldly, then usually some kind of elections are held (or there is some other more deterministic process to determine who is on the TSC; e.g. parts of the codebase or repos are guaranteed maintainers).

. From that perspective, we could argue @pi-314159 should be on the TSC as maintainer of oqs-boringssl. I'd surely also invite @brian-jarvis-aws to commit being maintainer of oqs-opensshand @bhess as a representative of another integration company could commit to be maintainer of oqs-demos. This way, TSC representation and technical contribution activity would be much better aligned.

Makes sense to me!

Thanks a lot for your time everyone!

[baentsch]

Once there are so many maintainers that meetings become unwieldly, then usually some kind of elections are held

Well, OQS has the opposite: Way too few maintainers and --"courtesy" the LF charter-- too many elections (one so far; the one that created a rift between TSC members voting openly and those executing a secret vote -- hence this discussion).

Contributors who make smaller contributions should be allowed to vote because likely they are users who familiar with the project;

Two thoughts speaking against this:

1. There's doubtlessly many people familiar with the project due to their (in-house) use of it; but they show up rarely if ever and don't contribute back. Those "leechers" should not have the right to vote/change the course of the project in a direction that suits them just because of tiny contributions.
2. I have seen many contributions crossing t's and dotting i's that don't document knowledge. Allowing such contributors to change the course of the project is against all principles of merit-based decision taking: We have reasonable GOVERNANCE.md files clarifying what it takes to use, contribute, commit and maintain, respectively. Those simply shall now overrule any LF formalities -- except the IP stuff protecting the profits of the companies paying your salary:

some things are unfortunately not due to legal constraints (DCO, licensing, etc.).

Please accept that people working for free on a project where profit-taking, err, "legal constraints", has become a major rule changer just can't stomach restrictions on freedom and openness while the entities introducing those restrictions don't substantially step up their contributions -- technical ones, not just procedural ones:

From that perspective, we could argue @pi-314159 should be on the TSC as maintainer of oqs-boringssl. I'd surely also invite @brian-jarvis-aws to commit being maintainer of oqs-opensshand @bhess as a representative of another integration company could commit to be maintainer of oqs-demos. This way, TSC representation and technical contribution activity would be much better aligned.

Makes sense to me!

Beware: Being maintainer in my eyes (and the core sub projects of OQS) means commitment; particularly for employees it means commitment by their employers to give the employees time to work on this: Very often I have seen statements like "I don't have agreement by my boss to work on this except in my free time" or "there's internal work I have to prioritize higher".

If you'd have LF wording for this problem, by all means, please contribute that, @hartm. Maybe something along the lines "voting members must be able to commit at least x% of their work time to the project": That way people can meaningfully contribute and drive the project forward by votes based on experience.

[hartm]

Please accept that people working for free on a project where profit-taking, err, "legal constraints", has become a major rule changer just can't stomach restrictions on freedom and openness while the entities introducing those restrictions don't substantially step up their contributions -- technical ones, not just procedural ones:

I want to reiterate that these are there to protect users and contributors to code. Some users are definitely going to be corporations, and yes, they will benefit from these. But these protections benefit anyone who wants to use the code in some kind of real world deployment, not just "profit-takers". If you look at any other large-scale production cryptography library, they will have some kind of license restrictions and some kind of CLA/DCO policy.

If you'd have LF wording for this problem, by all means, please contribute that, @hartm. Maybe something along the lines "voting members must be able to commit at least x% of their work time to the project": That way people can meaningfully contribute and drive the project forward by votes based on experience.

We have plenty of wording for this, in the form of what other projects have done! Different projects have taken many different approaches to this, so it would be much better if you all picked than if I wrote something. One thing: it's hard to verify that folks are actually committing a certain percent of their time, so this isn't typically used.

Here's the Besu maintainer policy. It's very explicit about what is required, and the Besu community really likes it.

On the other hand, here's the Fabric maintainer policy. It's a little less detailed, but it works for them too.

You can also look at other things, like the Kubernetes leadership organization, although that is much too complicated for what OQS needs at this point.

In general, there's probably no need to reinvent the wheel here. I'd recommend that you poke around, pick a maintainer policy that you generally like, and then tweak it to meet your needs.

Beware: Being maintainer in my eyes (and the core sub projects of OQS) means commitment; particularly for employees it means commitment by their employers to give the employees time to work on this: Very often I have seen statements like "I don't have agreement by my boss to work on this except in my free time" or "there's internal work I have to prioritize higher".

This is also the sentiment of the LF. If folks don't have time to respond to PRs and other things in a timely manner, they shouldn't be maintainers. It's not necessarily a bad reflection on these folks that don't have time, but we do ask that folks "gracefully step down" when they realize they don't have time to fulfill the responsibilities of being a maintainer. Most projects prominently list emeritus maintainers as a way of thanking them for all of the work they've done on a project!

[baentsch]

If you look at any other large-scale production cryptography library, they will have some kind of license restrictions and some kind of CLA/DCO policy.

I am well aware of this as a happy contributor to openssl, say: Simple CLA (on-file-check using github ID), no additional DCO (tooling) nonsense.

Apologies for the choice of word, but there's no other word I can think of for something

• prescribing the use of the -s option when committing: How many people know what this implies and don't just simply add it along with the -m option?
• not cryptographically secure;
• if forgotten, requiring a slew of commands to satisfy the tooling "controlling" its use.

Yes, I noticed your proposal for an "LFID" -- but as stated just adds another layer of IDs (most likely coming with their own additional legal handcuffs) without immediately visible benefit (to a github-ID-bound CLA).

[baentsch]

Here's the Besu maintainer policy. It's very explicit about what is required, and the Besu community really likes it.

This is a very good link, thanks, @hartm. Will go to work right away to add it to projects I currently still maintain.

[bhess]

Thanks @dstebila for starting this discussion. Your proposal makes sense to me. I also think it is important to leave sufficient time before or after a meeting to reflect before voting, and to give people unable to attend a meeting to the opportunity to vote online if they desire.

For voting on matters involving people (e.g., elections), the TSC should decide whether we want those types of votes to be done using public or secret ballot. If public ballot, then we could just use the same procedure as for normal matters. If secret ballot, then we should identify an online voting mechanism we want to use, such as Helios voting which the IACR uses for its electronic elections.

A verifiable voting mechanism like Helios seems most important to me. I am open to public ballots as well, but not sure if this adds an advantage over a verifiable mechanism.

For the votes in the first TSC meeting, I'd however propose that the votes are published. For myself, I don't have an issue to disclose my vote.

@bhess as a representative of another integration company could commit to be maintainer of oqs-demos.

Currently the build of the test server is part of oqs-demos. My proposal would be to promote this to a separate project (e.g., 'testserver'), and I would commit to be a maintainer of this project which includes operating the test server instance.

Other commitments I can currently give is to be a committer of liboqs and oqs-provider, as documented in their GOVERNANCE.md files.

Contributors who make smaller contributions should be allowed to vote

I'd suggest having only Maintainers to have voting rights in the TSC

There are some voting rules defined in the GOVERNANCE.md files for change of roles that sound quite reasonable to me:

Any Contributor can become a Committer by contributing sufficient code and displaying deep subject matter knowledge in discussions such that a majority of Committers vote for this change of role. A Maintainer can veto such a vote. Such a veto can be overruled by a 2/3 majority of Committers.

Would it be considerable to adopt the same voting rights for the TSC? This way not it's not only maintainers who can vote, making the body more inclusive. Still, the maintainer role is honored with veto rights.

[baentsch]

Other commitments I can currently give is to be a committer of liboqs and oqs-provider, as documented in their GOVERNANCE.md files.

Thanks!

Currently the build of the test server is part of oqs-demos. My proposal would be to promote this to a separate project (e.g., 'testserver'), and I would commit to be a maintainer of this project which includes operating the test server instance.

Can you please explain what you as well as the community would gain from such split?

From my personal experience creating and running the testserver this is a "running" commitment worth about 5-10 minutes a week -- if done in conjunction with helping the community with integrations, e.g., the nginx code underlying the testserver in oqs-demos.

Splitting out the test server seems pretty inefficient --and leaves the underlying nginx and other PQ integrations to the support of the community -- and it currently seems that means myself. This in turn doesn't feel right: With the OQS take-over initiated by IBM and executed via the corporate-driven LinuxFoundation I personally am not really motivated anymore to work more for (free) for for-profit companies, i.e., I'm trying to have my contribution levels not eclipse those by (paid) LF/corporate folks, most notably on integrations arguably benefiting large IT integrators. And going below the above time doesn't make a lot of sense, indeed to me indicates two choices:

1. I drop out as work for less than 5-10 minutes a week (and a meeting of course :) is not worth the effort of staying on top of technical development
2. Take back control of the test server: I'd move it off IBM cloud and into AWS: That'd reduce the effort substantially, possibly fully automating things.

But then again --and tongue-in-cheek-- I don't want your employer to think that people working for free do more (and obviously much cheaper) than what their employees do :-) More seriously, I'd consider this commitment level too low for a self-respecting co-chair of the OQS TSC: If your employer doesn't give you more time for a stronger commitment, please let us know so this project can take this into consideration.

[baentsch]

Would it be considerable to adopt the same voting rights for the TSC? This way not it's not only maintainers who can vote, making the body more inclusive. Still, the maintainer role is honored with veto rights.

May I take this as a supportive statement of

In this case, let's bring the charter in line with what's documented in github

?

[bhess]

Can you please explain what you as well as the community would gain from such split?

The benefit would be to have a dedicated project that is fully maintained, in a similar way as, e.g., 'profiling' is a dedicated project with a web service associated with it. And nginx would be a component of such a 'testserver' project.

But it doesn't need to be done this way. Another model for oqs-demos could be to label it being supported on a best-effort basis, with the community contributing/updating those components they are interested in.

Regarding the two choices you outline above @baentsch: by no means I want to take anything "away from you", you are the original author of the test server and nginx in oqs-demos. I deeply respect your dedication and contribution to the project. If you prefer to operate the server again, you are of course very welcome.
My motivation with my proposal is to help OQS to have this part continued to be maintained. I don't claim that this is the same contribution as maintaining bigger oqs-projects.

More seriously, I'd consider this commitment level too low for a self-respecting co-chair of the OQS TSC.

With my previous post I am transparent about the level of commitment I can currently offer to the project. Your rhetoric with self-respect is personal, so please let me state my recollection of the TSC formation and the co-chair/vice-chair election: Douglas invited me to join the TSC, among long-running contributors to OQS, independent from my employer's membership in the PQCA. During the first TSC meeting, three candidates were nominated for the TSC co-chair/vice-chair role by other members of the TSC. Nobody did nominate themself. Arguments presented in the (short) discussion were the term of their contribution and the size of the company they are affiliated with. I accepted my nomination based on my desire to help the project and taking this in my view more administrative role. I wouldn't accept any privileges that allow me to perform actions on my own rather than the TSC consensus. I further do not fight for this role, if there are other candidates willing to do it and are elected, they are very welcome.

[christianpaquin]

What do you term "administrative votes" and what are "close ballots"? How does this work?

Elections, for example. Close ballots = secret ballot, but verifiable. We could use helios<https://vote.heliosvoting.org/> (as proposed by Douglas); that's the system used by the International Association for Cryptographic Research (IACR) to conduct its elections. From: Michael Baentsch ***@***.***> Sent: Saturday, April 6, 2024 1:39 AM To: open-quantum-safe/tsc ***@***.***> Cc: Mention ***@***.***>; Comment ***@***.***> Subject: Re: [open-quantum-safe/tsc] Create a voting procedure for the OQS TSC (Issue #12) I'm actually ok if administrative votes use close ballots What do you term "administrative votes" and what are "close ballots"? How does this work? as long as they can be verified Absolutely agree: This (un-verifiability of voting) was the biggest "turn-off" to me personally in the first TSC meeting: Some LF person announcing a ballot result putting exactly that LF company in (co-)chair position that initiated the LF take over of OQS: It felt like the completion of a hostile take-over. With this, I completely lost trust in the openness of LF, the sincerity of the people voting and in the open and mutually respectful cooperation that existed in OQS before. @hartm<https://github.com/hartm>, fyi: @christianpaquin<https://github.com/christianpaquin> with the addition of this single word ("verified") straightened out what the LF charter terms you quoted here<open-quantum-safe/boringssl#114 (comment)> couldn't: Your charter states: The output of all Project discussions, proposals, timelines, decisions, including voting results and status should be made open and easily visible to all. If it stated instead All Project discussions, proposals, timelines, decisions, including verified voting results and status will be made open and easily visible to all without limitation. I trust you see the differences, @hartm<https://github.com/hartm>: This way, LF no longer can a) decide which voices/opinions to redact out (by publishing only the "output") b) create voting results it likes (by publishing only the "results" it likes as done here<7b4c74f>) c) delete discussions in the future (by removing access to archives<open-quantum-safe/boringssl#114 (comment)>) I strongly support conducting all technical decisions openly, given all stakeholders proper review time. Thanks! - Reply to this email directly, view it on GitHub<#12 (comment)> or unsubscribe<https://github.com/notifications/unsubscribe-auth/AD36T5OSPUK7HDAAVP3YIRDY36C6JBFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLLDTOVRGUZLDORPXI6LQMWWES43TOVSUG33NNVSW45FGORXXA2LDOOJIFJDUPFYGLKTSMVYG643JORXXE6NFOZQWY5LFVE3TINRZGA2DKOBUQKSHI6LQMWSWS43TOVS2K5TBNR2WLKRSGIZDMNZXGY3TKMVHORZGSZ3HMVZKMY3SMVQXIZI>. You are receiving this email because you were mentioned. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[baentsch]

@bhess, allow me to comment on and correct a possible misunderstanding behind

Your rhetoric with self-respect is personal,

It is, but surely was not meant to be insulting to you and I apologize sincerely if it got across that way: I meant to convey the notion that (indeed for me personally) a (co)chair's commitment to the project should be significant; I personally do not think my level of commitment would be high enough to warrant taking on any TSC position, for example.

What "triggered" me so much was the apparent position-grab of your company even before we decided on who chairs the TSC: An IBMer, who never contributed a single line of code to the project, self-nominated to be an OQS representative: This felt like a "power grab" prepared over the course of a year, ever since IBM approached OQS to join LF, to be completed. IBM (sorry, you're a member of it) taking co-chair position then felt like "second best" thing your company settled for after the first attempt failed because someone noticed the nominee isn't member of the TSC.

The latter triggered me a second time: It was not noted that the nominee never contributed, it was only noted he is no TSC member: This (omission) ran counter to what even LF stated as a guiding principle of FOSS projects, namely merit-based decision taking.

At this moment, IBM&LF lost any trustworthiness to me personally as guardians of the FOSS nature of OQS and I was about the quit the project immediately and leave you to this understanding of what OSS seems to be: The rule of the people with money. @dstebila had me reconsider and I wrote my ass off in the past few weeks trying to convey what I think this project should be and highlight the deficiencies in the model the LF seems to hold high.

Now to the second part:

by no means I want to take anything "away from you", you are the original author of the test server and nginx in oqs-demos. I deeply respect your dedication and contribution to the project.

Thanks -- but behind this seems to lurk another misunderstanding of my comments that I'd like to clarify: I want stuff to be taken away from me; I want to retire and hand over responsibility for code and users, but I want to do that knowing that there's sufficient (at least time) commitment by the people doing it.

Am I so wrong wondering whether the entities making money off this code shouldn't be doing at least as much as the people working for free??

With this in mind,

And nginx would be a component of such a 'testserver' project.

already is more of a commitment that I thought it was when you originally stated it, thanks! I don't think it amounts to more than maybe 10% of your time, though, would you agree? Does IBM allow you to state how much of your time you can contribute to OQS? If IBM had an aggregate (set of people) of say more than 1 person year (PY) actively contributing (being at least Contributors, better Committers) at this level, the sum of this may justify an OQS position (co)deciding the future of this project -- but then based on merit, not on money. Side note: UWaterloo alone has people not members of the TSC that do more right now and my feeling is that Cisco and SandboxAQ are also more committed; but to change this "feeling" into facts, what about this:

I will work on creating a merit-based metric for oqs-provider and we can discuss in that PR to see whether it may be a model for the wider project, too.

This of course only if we can agree this project should be run on technical merit and not corporate might.

[baentsch]

One more thing commenting to @bhess:

please let me state my recollection of the TSC formation and the co-chair/vice-chair election: Douglas invited me to join the TSC, among long-running contributors to OQS, independent from my employer's membership in the PQCA. During the first TSC meeting, three candidates were nominated for the TSC co-chair/vice-chair role by other members of the TSC. Nobody did nominate themself.

@dstebila confirmed that @ashman-p nominated your IBM colleague to represent OQS at the TAC; my understanding of the course of events at that moment of the meeting thus indeed were wrong as I understood that as a self-nomination. I duly apologize.

Avoiding this from happening again could be achieved by publishing proposals ahead-of-meeting, discussing them at the meeting and vote on them after the meeting to settle things after suitable deliberation (or the opportunity to ask questions).

[ashman-p]

One more thing commenting to @bhess:

please let me state my recollection of the TSC formation and the co-chair/vice-chair election: Douglas invited me to join the TSC, among long-running contributors to OQS, independent from my employer's membership in the PQCA. During the first TSC meeting, three candidates were nominated for the TSC co-chair/vice-chair role by other members of the TSC. Nobody did nominate themself.

@dstebila confirmed that @ashman-p nominated your IBM colleague to represent OQS at the TAC; my understanding of the course of events at that moment of the meeting thus indeed were wrong as I understood that as a self-nomination. I duly apologize.

Other duties and travel kept me busy over the last couple of weeks. So, at the risk of waking up a sleeping giant ... I see from the above that I unknowingly contributed to some of @baentsch's unease with how things went in that 1st meeting. For that I am truly sorry. I will add that there was/is no intent of any kind of take-over corporate or otherwise on my part. Perhaps being somewhat naive to this world with some amount of ignorance, ... here are the factors that played into my nomination of someone other than Douglas.

1. it would take some of the administrative load off Douglas.
2. I also really imagined that whomever chaired any of these groups would be more a facilitator and less of a driver. Which means giving room and weight to all of the participants.

However, I also do see now how this situation could be perceived, so, again my sincere apologies.

[baentsch]

at the risk of waking up a sleeping giant

There's no need to be worried of this, to the contrary, I've been put off (and indeed pretty much to sleep) by the politics and formalism's introduced with the arrival of LF.

I would accept a nomination for "elephant" (in porcelain shop), though :-)

That said, please decide whether you want to wake me up or not. I do have a thought or two but am pretty sure they'd be uncomfortable. I'll share them with you by DM and you decide.