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. Better summary, more arguments, etc.. This would encourage people who are against the change to participate. 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'd also like to propose an additional policy modification that > occurred to me while writing this message: > > * A FESCo member may grant their proxy vote to another member of the > Fedora community if they cannot be in attendance for a vote. If they > do so, that vote is counted equivalently to any other. Proxy votes > MUST be limited to predetermined topics and time period. (e.g. I can > say "bookwar has my proxy vote on any topic directly related to ELN" > while I am on vacation from MMDD until MMDD, but I cannot give my > FESCo seat to a person of my choosing.) I think this might be ok-ish in the example of ELN conversations as we both are owners of the change and work on it. But in a slightly different situation, on a generic topic, I would prefer if people announce their vacation, and then FESCo will wait for a vote from the person if it can change the outcome. If someone goes on PTO for more than three weeks, that's a different story, but your approach won't work in this case either, as you won't be able to learn in advance which exact topics you need to delegate. So -1 here as well. > _______________________________________________ > 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 -- Aleksandra Fedorova bookwar _______________________________________________ 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
