DMB: proposal for adjustment to quorum rule

Dan Streetman ddstreet at canonical.com
Fri Oct 22 17:23:47 UTC 2021


On Fri, Oct 22, 2021 at 1:15 PM Dan Streetman <ddstreet at canonical.com> wrote:
>
> On Fri, Oct 22, 2021 at 4:39 AM Lukasz Zemczak
> <lukasz.zemczak at canonical.com> wrote:
> >
> > Thank you for starting the poll and sorry to only reply to this now.
>
> For public reference to non-members reading this, I'll paste the poll
> description and choices, since I just realized that only the board
> members are able to see the specific poll info (since it's a private
> poll):
>
> Description:
> Voting on proposal from this ML thread:
> https://lists.ubuntu.com/archives/devel-permissions/2021-August/001728.html
> Definitions:
> "Quorum": > 50% of active board members as described here:
> https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Quorum
> "Quorum votes are required": means that the net vote (after -1, +0,
> and +1 votes are summed) must be higher than the number of board
> members not present, as described in the KB link above.
> "Majority present votes are required" means that the net vote must be
> higher than 0.
> "Unanimous present votes are required" means that all board members
> present must vote +1.
>
> Choices:
> Quorum votes are required, however if quorum is not reached at first
> meeting, at the next meeting majority present votes are required.
> Quorum votes are required. (This is current policy).
> Quorum votes are required AND unanimous present votes are required.
> Majority present votes are required.
> Unianimous present votes are required.
> More discussion is needed.
>
>
> >
> > I think we'll decide on something from the proposed solutions for
> > sure. There's one somewhat related problem I'd like to discuss while
> > at it. Apologies if this feels like hijacking the thread. Since we're
> > now talking about the quorum required to start reviewing an
> > application at a DMB meeting, right? Meaning, because we sometimes had
> > to postpone applicants due to missing DMB members on the meeting, we
> > want to make the situation better for people not having to be
> > postponed into infinity. And for this it makes sense.
>
> we don't require quorum to hold meetings, we only require 'quorum'
> during voting; specifically that any net vote must be higher than the
> number of absent board members.
>
> However, if we don't 'have quorum', we don't usually bother holding a
> meeting, since even if we voted unanimously, we couldn't pass any
> motion or approve any applicant. Which this proposal seeks to change.
>
> >
> > But a similar related problem is what if we have quorum, but then
> > during the meeting the vote is on hold, because of still depending on
> > the votes of DMB members not present (with their votes potentially
> > having the chance of changing the outcome). This might feel the same
> > situation, but I think it needs to be handled separately. Right now
> > what we do is move to the ML and request votes from others until a
> > result is reached that cannot be overturned anymore. But the problem
> > is that this can take a while. We could think of adjusting some of the
> > propositions for this purpose, although I don't feel that any of them
> > is particularly good for this situation.
>
> I don't think that situation is different at all, in fact that
> happened with a recent applicant, halves; we started the meeting with
> enough board members for quorum but when voting, we only got 3 votes.
> As I said at the time, that simply means we didn't reach quorum.
>
> The options after not reaching 'quorum' number of votes are either to
> take the vote to the ML or for the applicant to re-apply at a later
> meeting. I don't know if we need to necessarily think of any other
> option, and I think this is entirely handled by this poll.
>
> Maybe we can just vote on this proposal, and if you feel there's still
> an issue later you can open a new proposal for the board to vote on?
>
> >
> > I think we'd need to adjust our voting rules and, for such a hanging
> > vote situation, simply set a time limit for non-present DMB members -
> > let's say "till the next DMB meeting", to cast their vote either via
> > e-mail or on the next DMB meeting itself, and if a member does not act
> > on time, his vote will default to +0. What do you think?
>
> I think this poll presents the option to do that, specifically my
> original proposal is exactly what you're proposing here.
>
> For clarification, in the poll, my original proposal is this line:
> Quorum votes are required, however if quorum is not reached at first
> meeting, at the next meeting majority present votes are required.
>
> My original proposal obviously included much more text for
> clarification, but for the poll I didn't want to have paragraphs for
> each choice so I tried to narrow down the text to as concise as
> possible while still trying to convey the meaning. So this line means:
>
> "Quorum votes are required" - I stated a short definition in the poll
> description, and the linked KB has more detail, but maybe I can try to
> give a clearer meaning. "Quorum votes" simply means we have enough
> votes so that the board members absent could not possibly affect the
> outcome of the vote, which requires an 'absolute majority', meaning
> the 'net' vote (after all -1, +0, or +1 votes are summed) must be
> greater than 0. Since we don't know how absent members might vote, we
> have to consider 2 situations to get the 'minimum' and 'maximum'
> possible vote outcomes; for the 'minimum' vote we assume all absent
> members will vote -1, and for the 'maximum' we assume all absent
> members will vote +1. We add the actual vote of present members to get
> the range, from 'minimum' to 'maximum', and if the 'minimum' vote is
> greater than 0, the vote passes - similarly, if the 'maximum' is less
> than 0, the vote fails. The middle situation - where the 'minimum' is
> <= 0 and 'maximum' is >= 0 - is the situation where we 'do not have
> quorum'.
>
> Maybe it's easier as python:
> def do_vote(*votes, total_members=7):
>      absent = total_members - len(votes)
>      net_vote = sum(votes)
>      min = net_vote - absent
>      max = net_vote + absent
>      if min > 0:
>              print(f'Vote minimum {min} > 0, vote passes')
>      elif max < 0:
>              print(f'Vote maximum {max} < 0, vote fails')

I should add there is also the possibility of a 'tie' if all board
members vote, and the net vote is 0, which would result in min == max
== net_vote == 0. I don't think we have an explicit policy to handle a
tie vote, but I don't think we really need one, as it effectively just
means the vote failed.

An example of a tie vote would be if the vote was:

do_vote(-1, -1, -1, 1, 1, 1, 0)

or

do_vote(0, 0, 0, 0, 0, -1, 1)

>      else:
>              print(f'Vote is between {min} and {max}, outcome unknown
> as quorum was not reached')
> >>> do_vote(1, 1, 1)
> Vote is between -1 and 7, outcome unknown as quorum was not reached
> >>> do_vote(1, 1, 1, 1)
> Vote minimum 1 > 0, vote passes
> >>> do_vote(-1, -1, 0, 1)
> Vote is between -4 and 2, outcome unknown as quorum was not reached
> >>> do_vote(-1, -1, -1)
> Vote is between -7 and 1, outcome unknown as quorum was not reached
> >>> do_vote(-1, -1, -1, -1)
> Vote maximum -1 < 0, vote fails
>
> "if quorum is not reached at first meeting" - if we can't reach
> 'quorum' number of votes, either during the meeting or in the ML after
> the meeting
>
> "at the next meeting majority present votes are required" - when the
> applicant re-applies we no longer care about how any absent members
> might vote, meaning 'minimum' == 'maximum' == 'net_vote', and as usual
> 'net_vote' must be > 0.
>
> >>> do_vote(1, 1, 0, total_members=3)
> Vote minimum 2 > 0, vote passes
>
> That is what my proposal is and has always been.
>
>
> >
> > Cheers,
> >
> > On Thu, 21 Oct 2021 at 14:46, Dan Streetman <ddstreet at canonical.com> wrote:
> > >
> > > On Mon, Oct 4, 2021 at 4:28 PM Dan Streetman <ddstreet at canonical.com> wrote:
> > > >
> > > > On Fri, Sep 24, 2021 at 9:42 AM Robie Basak <robie.basak at ubuntu.com> wrote:
> > > > >
> > > > > On Tue, Aug 31, 2021 at 05:46:52PM -0400, Dan Streetman wrote:
> > > > > > > D: A unanimous vote of members present is required.
> > > > > >
> > > > > > I think this is really a separate discussion, if applications need a
> > > > > > unanimous vote or not. Against this as a solution to this problem, but
> > > > > > I'm not necessarily against it as a separate motion.
> > > > >
> > > > > Sorry, I worded this one badly. Let me try again:
> > > > >
> > > > > D2: if an absolute majority is not possible because the number of voters
> > > > > required are not present at a meeting, then a unanimous vote of members
> > > > > who are present is sufficient to pass a motion that grants upload access
> > > > > to an applicant.
> > > >
> > > > ah ok, thanks.
> > > >
> > > > Since we're coming up to the holiday season, and meeting attendance
> > > > probably will be too sparse to vote on the proposals, I'd like to
> > > > suggest we vote on this proposal (and my previous proposal) over
> > > > email, as well as finishing any further discussion that's needed.
> > > >
> > > > For this proposal, since we have multiple options, should we set up a
> > > > condorcet vote? That may help the DMB members to proceed to voting.
> > >
> > > I've set up a poll to vote on these options, and sent a private email
> > > to board members. I tried to reduce the poll options down to the
> > > shortest accurate description of each option, and there is also 'needs
> > > more discussion' if anyone thinks we do need to continue discussing
> > > this. Please try to vote before the next scheduled board meeting on
> > > Nov 1.
> > >
> > > --
> > > Devel-permissions mailing list
> > > Devel-permissions at lists.ubuntu.com
> > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/devel-permissions
> >
> >
> >
> > --
> > Ɓukasz 'sil2100' Zemczak
> >  Foundations Team
> >  lukasz.zemczak at canonical.com
> >  www.canonical.com



More information about the Devel-permissions mailing list