[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Proposal: Revise FESCo voting policy
From:       Vít_Ondruch <vondruch () redhat ! com>
Date:       2020-05-13 12:45:52
Message-ID: 1b1b3bb0-bec4-4f53-3244-bb8a6940bb9e () redhat ! com
[Download RAW message or body]


Dne 12. 05. 20 v 14:22 Aleksandra Fedorova napsal(a):
> Hi,
>
> On Tue, May 12, 2020 at 10:19 AM Vít Ondruch <vondruch@redhat.com> wrote:
>>
>> Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a):
>>> Hi,
>>>
>>> On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher <sgallagh@redhat.com> 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.
>>
>> 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.
> The proposal has at least support of its owners, who stepped in and
> spent some time describing the idea.
>
> If there are no convincing reasons against this proposal, then it is
> their opinion, which matters. They have an idea, and they are willing
> to do the job and take the responsibility.
> I don't see the reason to block it then.


When the change process was established, I always proposed that the
change should be always pre-approved by default. The changes would be
judged by the amount of feedback received on ML after their
announcement. If somebody had strong concerns, it would be possible to
bring this change to be judged by FESCo.

But then everybody felt strong that it is not possible, because if there
was not official body approving this, that could be end of the world. So
now, when we have that body, it gives blank approvals, because the
members of the body cannot get themselves educated about the
problematic? Can somebody explain me what is the reason for the process
then?

My proposal is that FESCo should put their stuff together and provide
reasonable ruling or it should completely dissolve, because it proves
itself useless. There are no reasons for the committee to gather
together just to provide rubber stamps to changes.


Vít


>
> Given that "change is out of scope of Fedora" and "support is very
> limited and the risk is too high" still can be a convincing reason to
> reject the change in some cases. But then it must be stated
> explicitly.
>
>> Vít
>>
>> _______________________________________________
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave@lists.fedoraproject.org
>> 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@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic