DMB: proposal for adjustment to quorum rule

Dan Streetman ddstreet at canonical.com
Fri Oct 22 17:15:00 UTC 2021


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')
     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