<div dir="ltr">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: <a href="https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004169">https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004169</a>.  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: <a href="mailto:cody@redcow.ca">cody@redcow.ca</a> <a href="http://www.redcow.ca">http://www.redcow.ca</a> </div>