> On 5 Oct 2021, at 08:45, Nicholas Bennett <[email protected]> wrote: > > Lars, > Couple of questions: > Who is eligible to vote?
This is defined in QUIP-2 [0] (the governance model) and depends on what the vote is about. My understanding is that matters that are about maintainer(s)/maintainership can only be proposed by and voted over by maintainers. Maintainers are also expected to vote on matters that relate to changes in the governance model itself. Matters about approvers can be proposed and voted over by both approvers and maintainers. Finally, matters that are not contigent upon such elevated “status” can be proposed and voted over by any contributor in the community. > Is it mandatory? No. The result is based on the outcome of the votes cast. In other words, if three people decide to vote on a given matter, there’s going to be at least a two third majority in favor of either option. In any case, decision based on lazy consensus is still the defined preference, so as far as I understand it, this procedure is only for matters of some delicacy or where the project needs a decision but lazy consensus is difficult to achieve. //! Paul [0] - http://quips-qt-io.herokuapp.com/quip-0002.html > Cheers, > Nick > > -----Original Message----- > From: Development <[email protected]> On Behalf Of Lars Knoll > Sent: Friday, 1 October 2021 8:44 PM > To: Qt development mailing list <[email protected]> > 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 > [email protected] > https://lists.qt-project.org/listinfo/development > _______________________________________________ > Development mailing list > [email protected] > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
