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

Philip Muskovac yofel at gmx.net
Thu Jun 5 14:35:30 UTC 2014


On Monday 17 February 2014 17:47:54 Harald Sitter wrote:
> Salut,
> 
> TLDR: request for the council to discuss and vote on new policies document.
> 
> The past couple of weeks I worked towards rewriting and updating our
> current Kubuntu specific policies of which [1] is the result.
> 
> As with all policies all of it now requires approval by the Kubuntu
> Council which I propose should be done on the list as meetings are
> tedious to organize and some of the policies might require length
> discussions (or hopefully not).
> 
> For the better part these policies are either aligned with current
> practise that we had not previously put into written policy or solve
> problems to which we never had a best practise solution. Completely
> new policies are marked with ((NEW)), all others were derived from
> existing policies.
> 
> New key policies:
> 
> * Dead Upstream - how to deal with software that is unmaintained upstream.
> 
> * Handlers - list of contact people for various important things
> (requested by JR).
> 
> * Kubuntu Council - I did not find a standing policy document on the
> council, one may feel free to enhance it.
> 
> * Kubuntu Teams - describing all Kubuntu teams, how to get it and what
> they are there for (requested by JR)
> 
> * Patching - while originally written 3 years ago the patch policy was
> never actually approved so this is a slighly refined version of the
> previous one. however equally restrictive in what patches can or
> cannot do.
> 
> * Stable Updates/Misc - when one may SRU software that is not covered
> by our patch-update-exception (primarily KDE SC), it seeks to minimize
> the amount of wasted time on SRUs that won't get verified.
> 
> * Long Term Support - outlines what sets an  LTS release apart from
> other releases specifically for Kubuntu.
> 
> Additionaly the bug triage policy has been changed to reflect what I
> did for the past year or two (primarily streamlining over the previous
> policy).
> 
> The code style policy from Lucid has been dropped and instead a global
> fallback policy was introduced making the upstream policies our
> policies unless we have a policy of our own (e.g. upstream code style
> and licensing policies apply now - again, what we have practised for
> years anyway).
> 
> [1] https://wiki.ubuntu.com/Kubuntu/Policies
> 
> HS

First of all, I fixed two things in the team definitions:
* kubuntu-packagers: kubuntu-ninjas can commit too (this syncs the information 
with the permissions in the ~ninjas section)
* kubuntu-members: instead of notifying ~members about applying for 
membership, the notification should go to the council via kubuntu-devel

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?

As for the policy itself, I'm +1 as long as we get this cleared up

[1] 
http://community.kde.org/Kubuntu/Policies#Kubuntu_Council_.28.28NEW.29.29[1] 
[2] https://wiki.ubuntu.com/Kubuntu/Council?action=recall&rev=16
[3] http://irclogs.ubuntu.com/2014/05/15/%23ubuntu-meeting.html#t17:00[2] 


--------
[1] 
http://community.kde.org/Kubuntu/Policies#Kubuntu_Council_.28.28NEW.29.29
[2] http://irclogs.ubuntu.com/2014/05/15/%23ubuntu-meeting.html#t17:00
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20140605/6bbab8e5/attachment.html>


More information about the kubuntu-devel mailing list