Hello,<br><br><div class="gmail_quote">On Tue, Jul 1, 2008 at 6:21 PM, Emilio Pozuelo Monfort <<a href="mailto:pochu@ubuntu.com">pochu@ubuntu.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all,<br>
<div class="Ih2E3d"><br>
Emilio Pozuelo Monfort wrote:<br>
> First draft for a policy for motu-{sru,release} membership:<br>
<br>
</div>Sorry for the long delay. I've had a look again at the proposal and at the<br>
comments, let's see if I can summarise them.</blockquote><div><br>Thanks for getting the ball rolling again. I've been doing some thinking about this and so I'm going to jot down some ideas to share :)<br> </div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
<br>
> 0/ The term of service for the motu-sru and motu-release teams is of one release<br>
> cycle (six months).<br>
<br>
</div>It's been said this is too short, and that 1 or 2 years would be better. It's<br>
also been proposed that we could have a long term (e.g. 2 years) but with<br>
"pings" from time to time (e.g. 6 months) to see who is not active and then<br>
replace inactive members. That way you don't change the entire team at the same<br>
time.<br>
<br>
I personally think 2 years is too much, but one year would be fine with me.<br>
<br>
And I don't think there will be problems regarding to changing the entire teams,<br>
as I expect some of the old members to reapply and be re-elected.</blockquote><div><br>It seems to me that it would be beneficial to define the terms in relationship to certain milestones in the release cycle instead of just saying "six months" or "one release cycle". This would ensure that we have individuals in place in case dates for said milestones change. For example, if a release cycle were to ever be extended again (like the first LTS), we don't want to be dealing with an election while we're trying desperately to wrap up a release. It would also give us tentative yet concrete dates to work with - no need to guess when "six months" or "two years" is up as we'd say: "ok, two weeks after the official release date we need to call election for xyz".<br>
<br>As for length, I feel that members should serve for two release cycles. This will tie into my reply to Sherman's post in a minute. <br><br>I also think the ping inbetween the two releases would be a good idea incase someone goes missing.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div><div></div><div class="Wj3C7c"><br>
><br>
> 1/ When the nominating time starts, people may nominate themselves (with a mail<br>
> to ubuntu-motu@). There's no restriction as to how many terms someone can<br>
> participate, but they need to reapply after each term ends.</div></div></blockquote><div><br>I think this should be clarified. Does this mean once elected, the individual can serve as many terms as they'd like as long as they "reapply" (ie. express their intention) or do they have to be re-elected? I think you mean the latter and I agree. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Wj3C7c"><br>
><br>
> 2/ When the nominating time ends, assuming there's any (even just 1, (s)he may<br>
> be rejected) candidature, the MC sets the polls in Launchpad (yes, it has a poor<br>
> interface, we need to file bugs if there aren't yet...), and the MOTU team is<br>
> given a week to vote.</div></div></blockquote><div><br>One week to vote seems fair and I think that having the election date in relation to a milestone as I propose above will help ensure we see optimal participation at the polls.<br>
<br>Also, what does it mean to be rejected or approved? What voting system will we use? Are the candidates with the highest number of votes added until the team reaches capacity? Is it possible to vote *against* a candidate? Do candidates require a majority to be approved?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Wj3C7c"><br>
><br>
> 3/ The MC adds the accepted candidates to the appropriate teams.</div></div></blockquote><div><br>Yup.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div class="Wj3C7c"><br>
><br>
> 4/ If all the vacancies haven't been fulfilled, another call for members may be<br>
> done, after a time of one week.<br>
></div></div></blockquote><div><br>I think this point needs more clarification as well. Is the team allowed to move forward without a full "load"? What if the community at large doesn't think there is another willing candidate suitable and how would that be expressed/measured? What role does the MOTU council play in this situation?<br>
<br>It seems to me that if there is no willing candidate to step forward then the team will simply have to proceed. With the exception being that I think maybe we should also set minimums and maximums for teams - ie. if a minimum number of candidates can not be found then the team does not form and an alternate system is employed (or some other reactive process/measure comes into play) and the flip-side being that the number of members in respective team can not exceed a certain value without getting consensus from MOTU at large like we are now for this specification (or maybe some other process). In addition to a minimum and maximum, there should be a nominal value which if not met would mean the team is still open to the addition of new members (ie. maybe MOTU xyz becomes not so busy in the middle of the release and would like to join MOTU-SRU then they may have their candidacy voted upon). If the nominal value IS met then no second call is met and the team is considered finalized. The purpose would be to help ensure the system/processes employed remains effective and efficient.<br>
<br>Along with my above (strawman) proposal, I'd like to propose the following initial values (which may be moot/inappropriate if we employ an idea I describe below):<br><br>MOTU-Release:<br> Minimum: 3<br> Nominal: 5<br>
Maximum: 7<br><br>MOTU-SRU:<br> Minimum: 2<br> Nominal: 3<br> Maximum: 8<br><br>Also, what do people feel about the MOTU council (either as a monolithic entity or individual members) being able to fill in as an acting member (or members) in situations where the minimum is unable to be reached? What about the MOTU council being able to extend an existing member's term to cover the same situation even if his or her re-election was unsuccessful (or, to clarify, maybe didn't meet the normal qualifying conditions which will be dependent on the voting system we decide to use). What ever your opinion, I feel this specification should enable the motu council the ability through certain processes to help push tough, stalled situations into moving, productive situations.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Wj3C7c"><br>
><br>
> Things that aren't clear yet in that draft:<br>
> - When the nomination period starts for each team (one week after the release<br>
> for motu-release and just after FeatureFreeze for motu-sru?).</div></div></blockquote><div><br>Although I've already given a few example dates/time lines in my discussion above, I feel is important that when deciding that the desire be to have these teams ready *for* action instead of becoming ready *in* reaction. To help facilitate this, I'd like to make the following proposal. Please allow me to quote Stephan Hermann's e-mail which came in as worked on this reply:<br>
<div style="margin-left: 40px;"><br>On Wed, Jul 2, 2008 at 3:48 AM, Stephan Hermann <<a href="mailto:sh@sourcecode.de">sh@sourcecode.de</a>> wrote:<br></div><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 6.8ex; padding-left: 1ex;" class="gmail_quote">
Good Morning,<br><div class="Ih2E3d"><br>
On Fri, 23 May 2008 19:26:40 +0200<br>
Stefan Potyra <<a href="mailto:sistpoty@ubuntu.com">sistpoty@ubuntu.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> as evolved by the discussion for motu-sru members, I guess it might<br>
> make sense to have a good general policy.<br>
<br>
</div>I would like to see a policy for:<br><br>
motu-sru / motu-release:<br><br>
* Changing Members every release cycle<br><br>
Why? It would be a good practice for newer MOTUs to step up and learn<br>
the "hard release work".<br><br>
Merging, fixing bugs, syncing for the actual development release is<br>
good and gives knowledge, but knowing how hard some decisions are is<br>
much better. Sure, re-elections of older members is possible, but I<br>
really want to see young blood.</blockquote><br>I agree with Stephan that is important for us to get "young blood" up to the task with the "hard release work"(sic.) but I also feel that it is important the team remains effective at all times as I feel is the rationale behind other's desire for longer terms. I feel that both scenarios are possible via what I might call "rolling" (and also a process I think other bodies in Ubuntu already use). If we were to set the term at two releases (as I proposed earlier), we could elect a "minimum set" (this is where my idea for min, max, and nominal get messy) but at the end of the first release cycle we could elect even more individuals (ie. "new blood") to bring it up to a "nominal" (or a little bit above nominal). These new individuals would then have an opportunity to learn the tricks of the trade with the more senior, experienced members already settled in (giving them more time to help the more junior members). At the end of the second release cycle, the more senior members will be able to re-apply or retire knowing there is still a number of individuals serving who have came to know what they're doing. Furthermore, an added benefit would be in the case of some sort of electoral issue we aren't left high and dry.<br>
<br>=== Benefits ===<br><br> * Teams change every release cycle but not the entire team which will minimize disruption and provide full coverage.<br> * There will always be a set of experienced individuals on the team.<br>
* Allow for proper transition (ie. if someone plans to retire, they don't have to wait until the last minute to pass things off)<br> * Allow for new individuals to get involved and get trained "on the job" by individuals with appropriate experience.<br>
* Date of the elections is less important - allows for it be scheduled at the most convenient time for everyone instead of last minute, omgz we need them but we're super omgz omgz ponies busy with this something else.<br>
<br>=== Drawbacks ===<br><br> * There would be a little bit of disruption when the new members are added but very pale to the one that is occurring now where huge reshuffles can and do occur.<br> * Guarantee of overhead at the end of each release but pale in comparison of trying to re-elect entire teams at larger intervals.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div><br>
> - How the voting works.</div></div></blockquote><div><br>Above I asked:<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 6.8ex; padding-left: 1ex;" class="gmail_quote">what does it mean to be rejected or approved? What voting
system will we use? Are the candidates with the highest number of votes
added until the team reaches capacity? Is it possible to vote *against*
a candidate? Do candidates require a majority to be approved? <br></blockquote><br>This is probably the toughest part to figure out: "How the voting works". If I understand correctly, the reason we elect these individuals is to legitmize a trusted body to make tough decisions as it is understood to be more effective then alternatives such as a free-for-all. Although similar rationale is the basis for today's governments, I think we should probably adhere to the KISS principle which will be a substantially easier task for us ;]. With that being said, I don't feel the rationale for adopting a system should be that it is the only one (or the only one acceptable) that launchpad can support. If launchpad doesn't support the system we pick, I feel we should move forward with it regardless and utilize our launchpad ambassador (a role I believe recently changed hands - can the new hand wave? <grin>) to communicate that need to the launchpad team. By the time the first election roles around, hopefully launchpad will have had time to facilitate or we can just employ our own interim solution (I'm sure launchpad will have had enough time by the second election (hopefully)). Anyhow, my point is to discourage people from disliking an idea based on the perception it won't be possible with the current launchpad voting/polls system.<br>
<br>Now, as to actual system (originally I was going to simply ask above questions but I figured it would probably be more appreciated if I actually started to flesh something more concrete out) it is important to note that the system we use will have an affect on
the outcome, especially when there is no clear majority preference. We *do* have several options, with the highest level of distinction being: majority rule, proportional representation, and plurity voting. Fortunately for us, we don't have "parties" which eliminate a lot of the different specific systems. Furthermore, we're looking to elect multiple individuals instead of determining a single winner which further narrows our choices down (infact, it completely wipes out plurity voting by definition).<br>
<br>=== Single Transferable Vote ===<br><br><div style="text-align: left;">I'd like to propose the Singe Transferable Vote (STV) with either the Hagenbach-Bischoff quota or the droop quota (most common for STV elections). STV is a preferential voting system which will minimize wasted votes, not require us to vote multiple times, and provides proportional representation. Basically, a candidate requires a certain minimum number of votes to be elected (the quota part). STV will allocate your vote to your most
preferred candidate, subsequently transferring unneeded or unused
votes after candidates are either elected or eliminated, according to your stated preferences.<br><p>An STV election proceeds according to the following steps:</p>
<ol><li>Voters cast their ballot where they rank every candidate by preference.</li><li>A quota is calculated and any candidate who has reached or exceeded the required quota is declared elected.</li><li>If not enough candidates have been elected then the surplus of the elected candidates are transferred to other candidates according to the next preference on each voter's ballot.</li>
<li>If still no one meets the quota, the candidate with the fewest votes is eliminated and their votes are transferred. </li><li>This continues from step 2 until enough candidates are elected.</li></ol>So, how is the quota determined? If we go with the droop quota (which is always rounded down), it looks like this:<br>
<br>( Total Valid Votes / (Seats + 1) ) + 1<br><br>The H-B quota is very similar to droop but theoretically makes it possible for more candidates to reach quota (Normally, it is considered a tie and a candidate is picked at random to be disqualified. In our case, we might just elect all of them since it would occur so rarely?) than there are seats whereas with droop it is mathematically impossible. Some argue this formula should be preferred over droop because it is possible with the droop quota to produce a seemingly undemocratic result. However, that argument has more to do with party representation and so the decision should probably be based on if we want the situation of more winners then seats to be able to occur.<br>
<br>( Total Valid Votes / (Seats + 1) )<br><br>So lets say we have an election with 120 votes, five seats, and six candidates: Andrea, Carter, Brad, Delilah, Scott, and Jennifer. The Droop Quota is 21 and the H-B Quota would be 20. <br>
<br>31 Voters vote: Andrea, Carter, Brad, Delilah, Scott, Jennifer<br>30 Voters vote: Carter, Andrea, Brad, Scott, Delilah, Jennifer<br>1 Voter votes: Brad, Andrea, Carter, Jennifer, Delilah, Scott<br>1 Voter votes: Brad, Andrea, Carter, Scott, Jennifer, Delilah<br>
20 Voters vote: Delilah, Scott, Jennifer, Brad, Carter, Andrea<br>20 Voters vote: Scott, Delilah, Jennifer, Carter, Brad, Andrea<br>17 Voters vote: Jennifer, Delilah, Scott, Andrea, Carter, Brad<br><br>This would give the following tally:<br>
<br>Andrea: 31<br>Carter: 30<br>Brad: 2<br>Delilah: 20<br>Scott: 20<br>Jennifer: 17<br><br>When first preferences are tallied Andrea and Carter have reached the quota and are declared winners. With droop, Andrea has 10 surplus votes and Carter 9. These surplus votes would go to Brad as Brad is the next available preference listed. This would give us the following tally:<br>
<br>Brad: 2 + Andrea's surplus (10) + Carter's Surplus (9) = 21<br>Delilah: 20<br>Scott: 20<br>Jennifer: 17<br><br>Brad has now reached a quota and is declared elected. He has no surplus
so Jennifer, who this time has the fewest votes, is excluded. Because
only Delilah and Scott are left in the count, and there are only two
seats left to fill, they are both declared elected. The result being that Andrea, Carter, Brad, Delilah, and Scott get elected.<br><br>If we instead go with the B-H quota (which we determined earlier to be 20), then the election would be a different story. The original tally is:<br>
<br>Andrea: 31<br>
Carter: 30<br>Brad: 2<br>
Delilah: 20<br>
Scott: 20<br>
Jennifer: 17<br><br>Andrea, Carter, Delilah, and Scott would all be declared winners in the first tally. Andrea's (11) and Carter's (10) surplus (21) would still go to Brad. Delilah and Scott do not have a surplus. This would give the following tally:<br>
<br>Brad: 23<br>Jennifer: 17<br><br>Brad has met the quota and is declared a winner. The result of the election is Andrea, Carter, Delilah, Scott, and Brad being elected (the same as with the Droop quota). However, what about a situation where all six get elected? Same scenario, different votes:<br>
<br>28 Voters vote: Andrea, Carter, Brad, Delilah, Scott, Jennifer<br>30 Voters vote: Carter, Andrea, Brad, Scott, Delilah, Jennifer<br>1 Voter votes: Brad, Andrea, Carter, Jennifer, Delilah, Scott<br>1 Voter votes: Brad, Andrea, Carter, Scott, Jennifer, Delilah<br>
22 Voters vote: Delilah, Scott, Jennifer, Brad, Carter, Andrea<br>21 Voters vote: Scott, Delilah, Jennifer, Carter, Brad, Andrea<br>17 Voters vote: Jennifer, Delilah, Scott, Andrea, Carter, Brad<br><br>Andrea, Carter, Delilah, and Scott are declared winners in the first tally. Andrea and Carter have a surplus of 16 which goes to Brad. Delilah and Scott have a surplus of 3 which ends up going to Jennifer. This gives us the following second tally:<br>
<br>Brad: 20<br>Jennifer: 20<br><br>Either both are declared winners or STV calls for one to randomly be selected.<br><br>To prove that Droop doesn't allow this, note that the Droop quota is 21 and not 20. This means that although Andrea, Carter, Delilah, and Scott are still declared winners the first tally. The surplus to Brad would instead be 16 and the surplus for Jennifer would be 1, resulting in the following: <br>
<br>Brad: 2 + 16 = 18<br>Jennifer: 17 + 1 = 18 <br><br>Oh, whats this?! A tie? Yes, but neither meet the quota. In this case, either tie procedures come into place or (my preference) we decide that neither candidate is elected since they didn't meet the quota.<br>
<br>=== Single Non-Transferable Vote ===<br><br>An alternate to STV would be <font size="2">Single *non*-transferable vote</font> where we would only vote once for the individual most preferred. Candidates would be given available seats in order of number of votes. So if we have three seats and five candidates (a, b, c, d, and e) and there are 100 votes cast with the a - 30, b - 20, c - 19, d - 21, and e - 10 then candidates a, d, and b would be declared the winners. This only provides semi-proportional representation by definition but would be less likely in our case due to small scale we're dealing with.<br>
<br>=== Block Approval Voting ===<br><br>A third alternative would be block approval voting - a simple variant on block voting
where each voter can select an unlimited number of candidates and the
candidates with the most approval votes win - where you would vote yes or no for each candidate. This does not provide proportional representation and is subject to the <a href="http://en.wikipedia.org/wiki/Burr_dilemma" title="Burr dilemma">Burr dilemma</a>, among other problems. Although approval voting is the system we've used in the past, it is really an abuse of the approval system as approval voting is not meant to be multi-member.<br>
</div><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Wj3C7c"><br>
<br>
</div></div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888">Emilio<br></font></blockquote></div><br>As I stated already, I'd like to propose the single transferable ballot with either the Droop or H-B quota. What happened to the thing I said about KISS? Well, although the two other alternatives I presented *are* more simple it also sacrifices the traits that make (IMHO) STV so favourable. STV is a preferential, proportional representative voting system that is relatively simple, allows us to minimize wasted votes, scales well to the multi-member task, and even provides us with an easy way to replace individuals (when more candidates then seats run) who aren't able to fill their entire term. <br>
<br>Anyhow, I didn't origianlly intend for this e-mail to be this long so I do hope someone reads it, lol. Maybe I'll transfer the gist of it to a blog post.<br><br>Cheers,<br><br>-- <br>Cody A.W. Somerville<br>Software Engineer<br>
Red Cow Marketing & Technologies, Inc.<br>Office: 506-458-1290<br>Toll Free: 1-877-733-2699<br>Fax: 506-453-9112<br>Cell: 506-449-5899<br>Email: <a href="mailto:cody@redcow.ca">cody@redcow.ca</a><br><a href="http://www.redcow.ca">http://www.redcow.ca</a>