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

List:       fedora-devel-list
Subject:    Re: Proposal: Revise FESCo voting policy
From:       Aleksandra Fedorova <alpha () bookwar ! info>
Date:       2020-05-13 13:21:56
Message-ID: CAJ2r3Z1mdCGnGLzs8+B_xg5Xqb3YeYzSjF4LpX_5N54k22mQOw () mail ! gmail ! com
[Download RAW message or body]

On Wed, May 13, 2020 at 2:46 PM Vít Ondruch <vondruch@redhat.com> wrote:
>
>
> 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?

I think you are taking it a bit too far.

We were talking about highly theoretical case here, when:
1) majority FESCo members had no convincing reasons to reject the
change, but couldn't approve it,
2) they asked explicitly community to help in resolution,
3) community also haven't found reasons to reject the change,
4) and majority of FESCo members are still not convinced to approve
it, but not convinced to reject it either.

It kind of can happen only in a mathematical sense of a word "can". So
I probably shouldn't have argued about it.

So how about - if we ever see this happening in real life, we don't
follow any policy, but come back to this conversation and rethink the
role of FESCo?

> 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



-- 
-- 
Aleksandra Fedorova
bookwar
_______________________________________________
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]