Re: Council quorum rules clarification (was: Re: Kubuntu Policies (for council consideration))

[Matthew]

Sent from my HTC

----- Reply message -----
From: "Philip Muskovac" <yofel at gmx.net>
To: <kubuntu-devel at lists.ubuntu.com>
Cc: "Harald Sitter" <apachelogger at ubuntu.com>
Subject: Council quorum rules clarification (was: Re: Kubuntu Policies (for council consideration))
Date: Sat, Jun 7, 2014 13:55

On Friday 06 June 2014 10:20:02 Harald Sitter wrote:
> On Fri, Jun 6, 2014 at 7:36 AM, Scott Kitterman <ubuntu at kitterman.com> 
wrote:
> > On Thursday, June 05, 2014 16:35:30 Philip Muskovac wrote:
> > ...
> > 
> >> Now to the coucil: I'm not quite sure how to intepret [1].
> >> Taking it literally, quorum is 3x +1 no matter what the other 3 people
> >> vote
> >> (if at all). Which would mean though that 3x +1 and 3x -1 are a passing
> >> vote of 0. Our old council voting rules [2] state that quorum is a
> >> majority
> >> vote with the chair having a casting vote, but we haven't had a chair for
> >> years (unless you consider jr to be the permanent chair)
> >> Another quorum definition would be to require +3, with nobody voting -1
> >> (which is what I personally favor, but that might be rather impractical
> >> for
> >> decision making) Or we require a general majority vote of people present
> >> (i.e. 3 people have to vote for >= +3, for 6 people present it's >= +4,
> >> and
> >> for less than 3 people vote continues per mail unless at least +3 is
> >> reached) I believe that's closest to the last CC discussion about this
> >> [3]
> >> 
> >> What may I understand as the correct interpretation here?
> > 
> > ...
> > 
> > How does this compare to what's in the documentation for kubuntu-dev to
> > approave a new member?  I remember agreeing with that and think it's
> > likely
> > what we meant for the council as well, but maybe better written.
> 
> Dev is: simple majority of those present but at least 3 (so, quorum is
> reached with 3 devs in attendance given they all vote the same way).
> We use a present majority vote because dev has a variable member
> count.
> The simple majority requirement certainly does away with all the tie
> complexity as a motion simply isn't carried unless one side can form
> the majority, regardless of how many people are in attendance. i.e.
> dev ties default to -1.
> 
> OTOH, since currently the council has 6 seats I'd say it deliberately
> enables ties in a session with all attending. That being said IMO
> you'd want to change the seat count to an odd number to accomodate the
> simple majority rule. Say you have 7 council members and 6 are in
> attendance resulting in +3/-3 the seventh council member would always
> be breaking the tie when taking to the mailing list. Alternatively
> with 5 council seats in general you don't even have a case where a
> quorum was given but majority prevented by a tie.
> 
> With all that in mind I suggest that you change to a simple majority
> rule with at least 3 members necessary for quorum (not attendance
> majority, mind you). And next year for the elections either add a seat
> and raise the minimum to 4 or remove one and leave it at 3. That way
> you have an uneven seat count and motions cannot be blocked while
> technically having a quorum.
> 
> HS

I think the reason the other councils have 7 people is mostly for attendance 
reasons so I'm not sure whether we really need it.

We could stay close to the dev ruling and say:
A vote needs to have at least +3 with at least 4 people having voted, be it in 
meeting or ML.
That would make the passing conditions:
+6
+5 = +5 [+0]
+4 = +5 -1 [+0], +4 [+2x0]
+3 = +4 -1 [+0], +3 +0 [+2x0]

This would also make ties impossible as at most one person may be against it.
(which would mean that +3 -2 also doesn't pass, it also pretty much reduces 
the voting to a 5 people council with the 6th person being a voting speed up)
Too complicated or do the others think that we can usually agree on something 
to pass it?

Philip

-- 
kubuntu-devel mailing list
kubuntu-devel at lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20140608/b48bc7ae/attachment.html>