DMB nominations, size and quorum

Robie Basak robie.basak at ubuntu.com
Mon Jul 17 13:51:24 UTC 2017


At the meeting of 2017-06-19[1] I said I'd put together my argument for
why I think reducing quorum is better than reducing DMB size. Here it
is.

Problem: we frequently don't reach quorum in IRC meetings, causing
delays in processing applications and in making other decisions.

Summary: assuming that attendance rate will not change if we reduce the
DMB's size, our inability to get quorum will not change, so our current
problem will continue.

The current problem may be with certain members clashing on timing for
the meetings, so in theory if they left the DMB, the attendance rate
would go up. But I think that's only a short term matter that relates to
the current board membership. If we are to change DMB size and quorum
rules, I think we should be thinking in the long term including the
inevitable case where the board has turned over completely.

Instead, what I propose is that we reduce quorum, and the +1s required
to get an action approved[2].

Currently, by requiring N/2 +1 votes, we ensure that absent members
would not be able to change the outcome of any vote even if they were
present[3]. This comes at a cost: we cannot act if we cannot find N/2
members to agree, and this seems to be most of the time recently.

Instead I propose that we drop this requirement, and focus on the
opinions of those who _are_ able to attend. Absent members might have
been able to change the outcome had they been present, but they weren't
present, so we resolve to make progress over having to chase them.

For example: we could require that if a majority (≥50%) of those present
at a normally scheduled meeting agree, then the motion passes, subject
to a quorum of a third of the full board membership being present at
that meeting. We will no longer consult absent members. I'm also saying
that this means that when voting on an application, those board members
present (if over a third) decide on whether that application succeeds or
is declined and closed, also without reference to those absent.

Then we'd be able to pass or fail motions immediately providing that
attendance is greater than a third, instead of having to fall back to
chasing people up afterwards. This would be better than the half
attendance requirement that we have right now.

The exact fraction (a third in my example) could be debated now and/or
changed over time without changing the essense my proposal here; the
point is that this change would allow us to go below half attendance but
we could still remain effective.

For completeness, in the case that quorum isn't reached at a meeting but
board members attempt to vote anyway to then take it to the mailing list
for further votes, then the original situation should still stand: a
third of votes later wouldn't be enough; we'd still need enough votes
such that remaining board members cannot change the outcome. IOW, my
proposal to reduce the requirement in the case of non-attenance only
applies to voting that happens entirely within real time IRC meetings.

I don't think that ignoring absent members would pose too much of a
problem in practice, as generally I think we agree unanimously on
everything except on applications that we all agree are marginal anyway.

Then we could agree to keep the DMB size the same, but permit
temporarily absent seats (if there aren't enough nominations) and
consider N reduced accordingly if this is the case.

Thoughts?

Robie

[1] http://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-06-19-19.06.log.html

[2] I suspect this change might need TB approval, but I don't see that
they would object as it would restore our ability to act.

[3] I exclude the case of split votes that do end up requiring more than
N/2 votes; this is rare and I don't think it is directly a problem that
needs resolving.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/devel-permissions/attachments/20170717/2dbe0394/attachment.pgp>


More information about the Devel-permissions mailing list