MOTU Leadership Teams - Membership Policy

[Cody A.W. Somerville]

Hello,

 At the last MOTU Meeting, plenty of healthy and constructive discussion
occured regarding membership policy in MOTU Leadership Teams. However, it
was determined that the issue did not yet have a concrete proposal for any
sort of decision making process to move forward with. I have developed the
following summary of the different proposals based on the mailing list
archives, IRC chat logs, and a summary that Stefan Potrya prepared.

 Currently, the MOTU community feels that it is beneficial to delegate
certain responsibilities and permissions to a subset of trusted individuals;
for example the MOTU Release Team and Universe Stable Release Update Team.
Since these bodies represent and act on behalf of MOTU-at-large, it is
argued that for these leadership teams to be legitimate that they must
accurately reflect the MOTU via an electoral process. Others feel
alternative solutions would instead be optimal. Regardless, over the last
few releases, the methodology used to populate these teams has been
inconsistent. It is desired that a standard practice/policy be adopted.

 Initial discussion on this topic in June began with modifying the electoral
system we've used in the past (voters vote yes or no for candidates and
candidates who have the highest net count would be appointed OR candidates
would have to achieve a certain percentage of approval). Strong consensus
was reached on all major points except for the actual voting system to be
used.

 * Terms will be in the length of two release cycles which will usually work
out to be roughly 12 months.
 * Individuals interested in serving on a team will nominate themselves by
e-mailing their intentions to ubuntu-motu. The MOTU Council will make a call
for nominations 15 days before polls open.
 * To allow for new individuals to get involved in the leadership teams and
to ensure minimal disruption between terms, only a subset of the team will
be up for re-election at the end of each release cycle. This will either be
accomplished by holding a second election on the second release this policy
is adopted or by designating certain members of first election to serve an
extra release cycle.
 * If a member if not able to complete their term, they will be able to
resign and the runner up in the election will be appointed to serve the
remainder of the term. If a runner up is not available, the team may choice
to optionally replace the resigning member with an appointment of their
choice. If the latter occurs, any MOTU may veto the appointment by filing
grievance with the MOTU Council whom will allow the team to either leave the
position vacant or call a by-election.
 * Normal elections will start at an agreed date relative to a development
milestone and polls will remain open until a second agreed date that is also
relative to a development milestone. Once polls close, results will become
available and a short period to allow for grievances and/or disputes to
occur takes place. Finally, a third agreed date, which will also be relative
to a development milestone, will mark the normal conclusion with the MOTU
council officially announcing results and updating team memberships. If a
grievance of dispute arises, the MOTU council will resolve the issue in 15
days of the third date or escalate the issue to the technical board.

 Although a voting system has not been agreed upon yet, two systems which
have received a lot of discussion include Single Transferable Vote (used by
some governments) and the Schulze method (used by Debian and Wikipedia among
others). It is generally agreed that a preferential voting system, where
voters would rank their preference of the candidates instead of voting for
or against, is best.

 An alternative proposal by Emmet Hickory would have members be attached to
a "release" and favors replacing team members through a process more
closely related to apprenticeship than any sort of election. The team would
define goals for a release, handle freeze exceptions for the release, and
then follow the release as the SRU team until the release is no longer
supported (all together, roughly terms of 2 years). His full e-mail can be
found here: https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004169.

 1. Do we still agree with the items in the list above or do you prefer
Emmet's proposal?
 2. If yes, what voting system should we use? If no, we should work on
elaborating Emmet's proposal.
 3. If you're not sure what voting system we should use, you might pick the
one you best understand.

Cheers,


-- 
Cody A.W. Somerville
Software Engineer
Red Cow Marketing & Technologies, Inc.
Office: 506-458-1290
Toll Free: 1-877-733-2699
Fax: 506-453-9112
Cell: 506-449-5899
Email: cody at redcow.ca
http://www.redcow.ca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20080717/14701526/attachment.htm