policy for membership in MOTU key teams

[Cody A.W. Somerville]

Hello,

On Tue, Jul 1, 2008 at 6:21 PM, Emilio Pozuelo Monfort <pochu at ubuntu.com>
wrote:

> Hi all,
>
> Emilio Pozuelo Monfort wrote:
> > First draft for a policy for motu-{sru,release} membership:
>
> Sorry for the long delay. I've had a look again at the proposal and at the
> comments, let's see if I can summarise them.


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 :)


>
>
>
> > 0/ The term of service for the motu-sru and motu-release teams is of one
> release
> > cycle (six months).
>
> It's been said this is too short, and that 1 or 2 years would be better.
> It's
> also been proposed that we could have a long term (e.g. 2 years) but with
> "pings" from time to time (e.g. 6 months) to see who is not active and then
> replace inactive members. That way you don't change the entire team at the
> same
> time.
>
> I personally think 2 years is too much, but one year would be fine with me.
>
> And I don't think there will be problems regarding to changing the entire
> teams,
> as I expect some of the old members to reapply and be re-elected.


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".

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.

I also think the ping inbetween the two releases would be a good idea incase
someone goes missing.


>
> >
> > 1/ When the nominating time starts, people may nominate themselves (with
> a mail
> > to ubuntu-motu@). There's no restriction as to how many terms someone
> can
> > participate, but they need to reapply after each term ends.
>

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.


>
> >
> > 2/ When the nominating time ends, assuming there's any (even just 1,
> (s)he may
> > be rejected) candidature, the MC sets the polls in Launchpad (yes, it has
> a poor
> > interface, we need to file bugs if there aren't yet...), and the MOTU
> team is
> > given a week to vote.
>

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.

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?


>
> >
> > 3/ The MC adds the accepted candidates to the appropriate teams.
>

Yup.


>
> >
> > 4/ If all the vacancies haven't been fulfilled, another call for members
> may be
> > done, after a time of one week.
> >
>

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?

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.

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):

MOTU-Release:
 Minimum: 3
 Nominal: 5
 Maximum: 7

MOTU-SRU:
 Minimum: 2
 Nominal: 3
 Maximum: 8

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.


> >
> > Things that aren't clear yet in that draft:
> > - When the nomination period starts for each team (one week after the
> release
> > for motu-release and just after FeatureFreeze for motu-sru?).
>

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:

On Wed, Jul 2, 2008 at 3:48 AM, Stephan Hermann <sh at sourcecode.de> wrote:

> Good Morning,
>
> On Fri, 23 May 2008 19:26:40 +0200
> Stefan Potyra <sistpoty at ubuntu.com> wrote:
>
> > Hi,
> >
> > as evolved by the discussion for motu-sru members, I guess it might
> > make sense to have a good general policy.
>
> I would like to see a policy for:
>
> motu-sru / motu-release:
>
>        * Changing Members every release cycle
>
> Why? It would be a good practice for newer MOTUs to step up and learn
> the "hard release work".
>
> Merging, fixing bugs, syncing for the actual development release is
> good and gives knowledge, but knowing how hard some decisions are is
> much better. Sure, re-elections of older members is possible, but I
> really want to see young blood.


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.

=== Benefits ===

 * Teams change every release cycle but not the entire team which will
minimize disruption and provide full coverage.
 * There will always be a set of experienced individuals on the team.
 * Allow for proper transition (ie. if someone plans to retire, they don't
have to wait until the last minute to pass things off)
 * Allow for new individuals to get involved and get trained "on the job" by
individuals with appropriate experience.
 * 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.

=== Drawbacks ===

 * 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.
 * Guarantee of overhead at the end of each release but pale in comparison
of trying to re-elect entire teams at larger intervals.


>
> > - How the voting works.
>

Above I asked:

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?
>

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.

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).

=== Single Transferable Vote ===

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.

An STV election proceeds according to the following steps:

   1. Voters cast their ballot where they rank every candidate by
   preference.
   2. A quota is calculated and any candidate who has reached or exceeded
   the required quota is declared elected.
   3. 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.
   4. If still no one meets the quota, the candidate with the fewest votes
   is eliminated and their votes are transferred.
   5. This continues from step 2 until enough candidates are elected.

So, how is the quota determined? If we go with the droop quota (which is
always rounded down), it looks like this:

( Total Valid Votes / (Seats + 1) ) + 1

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.

( Total Valid Votes / (Seats + 1) )

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.

31 Voters vote: Andrea, Carter, Brad, Delilah, Scott, Jennifer
30 Voters vote: Carter, Andrea, Brad, Scott, Delilah, Jennifer
1 Voter votes: Brad, Andrea, Carter, Jennifer, Delilah, Scott
1 Voter votes: Brad, Andrea, Carter, Scott, Jennifer, Delilah
20 Voters vote: Delilah, Scott, Jennifer, Brad, Carter, Andrea
20 Voters vote: Scott, Delilah, Jennifer, Carter, Brad, Andrea
17 Voters vote: Jennifer, Delilah, Scott, Andrea, Carter, Brad

This would give the following tally:

Andrea: 31
Carter: 30
Brad: 2
Delilah: 20
Scott: 20
Jennifer: 17

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:

Brad: 2 + Andrea's surplus (10) + Carter's Surplus (9) = 21
Delilah: 20
Scott: 20
Jennifer: 17

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.

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:

Andrea: 31
Carter: 30
Brad: 2
Delilah: 20
Scott: 20
Jennifer: 17

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:

Brad: 23
Jennifer: 17

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:

28 Voters vote: Andrea, Carter, Brad, Delilah, Scott, Jennifer
30 Voters vote: Carter, Andrea, Brad, Scott, Delilah, Jennifer
1 Voter votes: Brad, Andrea, Carter, Jennifer, Delilah, Scott
1 Voter votes: Brad, Andrea, Carter, Scott, Jennifer, Delilah
22 Voters vote: Delilah, Scott, Jennifer, Brad, Carter, Andrea
21 Voters vote: Scott, Delilah, Jennifer, Carter, Brad, Andrea
17 Voters vote: Jennifer, Delilah, Scott, Andrea, Carter, Brad

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:

Brad: 20
Jennifer: 20

Either both are declared winners or STV calls for one to randomly be
selected.

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:

Brad: 2 + 16 = 18
Jennifer: 17 + 1 = 18

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.

=== Single Non-Transferable Vote ===

An alternate to STV would be Single *non*-transferable vote 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.

=== Block Approval Voting ===

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 Burr
dilemma<http://en.wikipedia.org/wiki/Burr_dilemma>,
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.


>
> Emilio
>

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.

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.

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/20080702/0626de53/attachment-0001.htm