There hasn’t been too much feedback on the proposal or the implementation so far. I’ll give it until the weekend, and unless further comments or issues come up, I’ll assume a lazy consensus on the proposal and start looking into taking the system into use next week.
There are two additional items that I propose to add: * voting will be open for 7 days to give everybody enough time to react * The voting database will be deleted 2 weeks after voting ended Cheers, Lars > On 1 Oct 2021, at 19:43, Lars Knoll <[email protected]> wrote: > > 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
