Dne 12. 05. 20 v 10:18 Vít Ondruch napsal(a): > Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a): >> Hi, >> >> On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: >>> During today's FESCo meeting, we encountered an unusual voting >>> situation for the first time: Four FESCo members voted in favor (+1) >>> of a measure and five FESCo members opted to abstain (0) for various >>> reasons. However, the FESCo voting policy currently reads: "A majority >>> of the committee (that is, five out of nine) is required to pass a >>> proposal in a meeting." As a result, we were actually at an impasse >>> until two of the FESCo members opted to change their votes to +1 to >>> resolve the confusion. >>> >>> It was subsequently suggested that we revise the policy to avoid this >>> pitfall in the future. I volunteered to put together a proposal for >>> how this could work and send it to the Fedora Development list for >>> discussion. I propose the following changes to the FESCo voting >>> policy: >>> >>> * To pass any measure, a majority — defined as the greater of half the >>> eligible votes (rounded up) — must vote in favor of the measure. The >>> standard set of eligible votes is one vote per FESCo member. No >>> measure may pass without at least one vote in favor. >>> >>> * Abstaining from a vote (aka "voting 0") is considered to have >>> removed that FESCo member's vote from the set of eligible votes. This >>> must be done explicitly and is never to be assumed from lack of >>> communication. >>> >>> A practical effect of the new abstention rule is that if two FESCo >>> members abstain, the measure would then require only a +4 vote to >>> pass. (A single abstention would still require a +5 vote). >> I don't like this idea. >> >> I think if FESCo members don't have enough data or understanding to >> vote on the topic, this means that FESCo needs to put more effort in >> it. >> >> Find some subject matter experts in the community, make additional >> steps to learn the subject. >> Or, when topic has no technical foundation but more of the personal >> preference, bring it for a full community vote. >> >> In the end FESCo supposed to channel the community voice. >> If FESCo can not make a decision, it means delegation of the decision >> to FESCo by community failed. So let's go back to community? >> >> So how about the alternative: >> if FESCo can't come up with the decision, it announces the stalled >> decision to fedora-announce and requests help. Actually, it should be also useful if position of each abstaining FESCo member was explained. Because for myself, I can interpret 5 people abstaining just as a lack of understanding of the issue and nothing else. Vít >> Better summary, more >> arguments, etc.. >> >> This would encourage people who are against the change to participate. > > I agree with Aleksandra up until here. > > >> And if there are no such people to provide convincing arguments >> against the change in a reasonable time frame, than FESCo decides in >> favor of the submitter. > > I disagree here. If such proposal does not have enough support, then it > should not be accepted and should be revisited/abandoned/rejected. I > cannot imagine any even hypothetical situation where the opposite was > beneficial. > > > Vít > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
