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
-- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
