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!