[Development] Formal voting procedure for Qt Project

[Nicholas Bennett]

Lars, 
Couple of questions: 
Who is eligible to vote?
Is it mandatory?
Cheers,
Nick

-----Original Message-----
From: Development <development-bounces at qt-project.org> On Behalf Of Lars Knoll
Sent: Friday, 1 October 2021 8:44 PM
To: Qt development mailing list <development at qt-project.org>
Subject: [Development] Formal voting procedure for Qt Project

Hi all,

As you might have seen, we had a request for a formal vote of no confidence on an Approver status according to the last paragraph in QUIP-2/How to become an Approver(*) in the recent QBS thread(**).

This is the first time we will need such a formal vote, which also means that we so far have not implemented a detailed process on how to do that. So before we proceed with such a vote, we will need to solve the problem of how to vote. This doesn’t require changes our governance model, we simply need to define a process on how to implement it.

Our governance model makes it clear that most decisions are reached through lazy consensus. However, I do not want such sensitive matters as a vote of no confidence to be handled by public vote. Therefore, I think we ought to find a different solution - which, fortunately, can be decided on with lazy consensus.

I’ve been talking to a few people for ideas, and this basically turned up three proposals. Here they are together with my thoughts on them:

1. Use the mailing list. 

I do not like this idea, when it touches sensitive matters such as a no-confidence vote. These kind of votes should in my opinion never be public. So this is something I do not consider to be a good option. See also https://lists.debian.org/debian-vote/2021/04/msg00032.html for a recent similar discussion in the Debian community.

2. Approvers vote by sending me a private mail.

This would be possible, but is in my opinion far from ideal. I would need to manually keep track of things running some risk of miscounting. In addition, all individual votes would still be visible to me, with the risk of the voter not participating due to the perceived social cost of doing so. People might for example refrain from voting if they believe their opinion is not in line with my thoughts.

3. We have some automated system (a voting bot).

This sounds like the best option to me. Daniel Smith came up with the idea and implemented a first version based on top of the cherry-pick bot that we already use. You can find the implementation at https://codereview.qt-project.org/c/qt/qtqa/+/373742 and a test instance at https://qt-cherry-pick-bot-staging.herokuapp.com/voting/. It’s for now still work in progress (you should e.g. not see the result before the end of the voting period), but this is something we should be able to fix before we go live.

The solution would have the following advantages:

* We can easily wipe the individual data some time after the vote is finished and only keep the final result to comply with data privacy regulations and keep the vote secret
* The allowed group for voting (Approvers or Maintainers) can be defined and is connected to our gerrit Approver and Maintainer groups.
* It automatically counts the results
* It can be made anonymous (Current implementation allows gerrit admins to manually look into the database, so we need to govern access or improve that part of the implementation)

I’d like to propose that we implement a voting procedure using this voting bot. We need it for this one case, but would also benefit from having such a tool in other cases, where the lazy consensus model might not be the best solution.

We wouldn’t be the first ones to do that, there are other open source communities out there that have secret voting procedures in place.

Please let me know what you think.

Cheers,
Lars
_______________________________________________
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development