FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Masters Of The Universe

 
 
LinkBack Thread Tools
 
Old 05-23-2008, 05:26 PM
Stefan Potyra
 
Default policy for membership in MOTU key teams

Hi,

as evolved by the discussion for motu-sru members, I guess it might make sense
to have a good general policy.

First off, what key teams do we have?

- motu-sru
- motu-release
- motu-council*

what else?
[*]: There already is a policy. What is good, what is bad about it?

Policy proposals:
- what worked good so far
- what needs improvement
- any good idea?

Please discuss .

Cheers,
Stefan.
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-25-2008, 11:07 AM
Emilio Pozuelo Monfort
 
Default policy for membership in MOTU key teams

First draft for a policy for motu-{sru,release} membership:

0/ The term of service for the motu-sru and motu-release teams is of one release
cycle (six months).

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.

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.

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

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


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?).
- How the voting works.

Please, comment on it! Even to say no


Stefan Potyra wrote:
> - motu-council*
...
>[*]: There already is a policy. What is good, what is bad about it?

Where? Couldn't find anything in the wiki.

Cheers,
Emilio

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-25-2008, 11:28 AM
Michael Bienia
 
Default policy for membership in MOTU key teams

On 2008-05-25 13:07:44 +0200, Emilio Pozuelo Monfort wrote:
> Stefan Potyra wrote:
> > - motu-council*
> ...
> >[*]: There already is a policy. What is good, what is bad about it?
>
> Where? Couldn't find anything in the wiki.

I guess that would be
https://wiki.ubuntu.com/CommunityCouncil/Delegation

Michael

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-25-2008, 02:33 PM
Scott Kitterman
 
Default policy for membership in MOTU key teams

On Sun, 25 May 2008 13:07:44 +0200 Emilio Pozuelo Monfort
<pochu@ubuntu.com> wrote:
>First draft for a policy for motu-{sru,release} membership:
>
>0/ The term of service for the motu-sru and motu-release teams is of one
release
>cycle (six months).

I think it should be longer. For motu-sru, their effort is continuous.
For motu-release, we are still defining the pre-freeze work that needs to
be done and so it's no clear when in a cycle this should best be done.

I'd suggest we set the term to two years with the idea that most people
won't actually do it long. That way people could be replaced on a rolling
basis as needed. Then neither team is likely to have a complete turnover
and lose corporate memory/ take a while to get organized and block other
people's work.

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-25-2008, 05:57 PM
"Jordan Mantha"
 
Default policy for membership in MOTU key teams

On Sun, May 25, 2008 at 7:33 AM, Scott Kitterman <ubuntu@kitterman.com> wrote:

On Sun, 25 May 2008 13:07:44 +0200 Emilio Pozuelo Monfort

<pochu@ubuntu.com> wrote:

>First draft for a policy for motu-{sru,release} membership:

>

>0/ The term of service for the motu-sru and motu-release teams is of one

release

>cycle (six months).



I think it should be longer. *For motu-sru, their effort is continuous.

For motu-release, we are still defining the pre-freeze work that needs to

be done and so it's no clear when in a cycle this should best be done.


Perhaps somewhere around UDS might be a decent time?
*

*I'd suggest we set the term to two years with the idea that most people

won't actually do it *long. *That way people could be replaced on a rolling

basis as needed. *Then neither team is likely to have a complete turnover

and lose corporate memory/ take a while to get organized and block other

people's work.

I very much agree with you that keeping people around and rolling replacement is important. From my experience with MOTU SRU it takes a while before you really get into the swing of things and I feel like as long as people are willing to server we are better off keeping people in these teams. Two years seems a bit long though, I would've gone for one year but 6 months seems too short.


Overall, there's sort of two things I think are important when it comes to team membership terms. We want to balance keeping good people in and letting people who don't have time/interest leave gracefully. Perhaps the 6 month and 2 year suggestions could be combined by having 2 year terms with 6 month "pings" to see any members wish to resign. That way people don't feel neccesarily obligated to 2 years (that's quite a long time in Ubuntu terms) but avoids having whole new votes every 6 months.


-Jordan

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-26-2008, 09:42 AM
Emilio Pozuelo Monfort
 
Default policy for membership in MOTU key teams

Scott Kitterman wrote:
> On Sun, 25 May 2008 13:07:44 +0200 Emilio Pozuelo Monfort
> <pochu@ubuntu.com> wrote:
>> First draft for a policy for motu-{sru,release} membership:
>>
>> 0/ The term of service for the motu-sru and motu-release teams is of one
> release
>> cycle (six months).
>
> I think it should be longer. For motu-sru, their effort is continuous.

Sure, but we need to choose some time, and I think around FeatureFreeze people
will have done most of their SRU work and will be concentrated on fixing things
for the development release. Anyway, while the new members are decided, the old
ones are still operative, so it shouldn't be a big deal.

> For motu-release, we are still defining the pre-freeze work that needs to
> be done and so it's no clear when in a cycle this should best be done.

Ok. Let's wait for that then.

> I'd suggest we set the term to two years with the idea that most people
> won't actually do it long. That way people could be replaced on a rolling
> basis as needed. Then neither team is likely to have a complete turnover
> and lose corporate memory/ take a while to get organized and block other
> people's work.

Two years sounds like too much to me. What about one year?

Also, I don't like that idea of people not finishing their term because it's too
long. If it's too long and they will leave it before its end, then we should
make it shorter IMHO.

Cheers,
Emilio

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-26-2008, 07:52 PM
Scott Kitterman
 
Default policy for membership in MOTU key teams

On Sunday 25 May 2008 13:57, Jordan Mantha wrote:
> On Sun, May 25, 2008 at 7:33 AM, Scott Kitterman <ubuntu@kitterman.com>
>
> wrote:
> > On Sun, 25 May 2008 13:07:44 +0200 Emilio Pozuelo Monfort
> >
> > <pochu@ubuntu.com> wrote:
> > >First draft for a policy for motu-{sru,release} membership:
> > >
> > >0/ The term of service for the motu-sru and motu-release teams is of one
> >
> > release
> >
> > >cycle (six months).
> >
> > I think it should be longer. For motu-sru, their effort is continuous.
> > For motu-release, we are still defining the pre-freeze work that needs to
> > be done and so it's no clear when in a cycle this should best be done.
>
> Perhaps somewhere around UDS might be a decent time?
>
> > I'd suggest we set the term to two years with the idea that most people
> > won't actually do it long. That way people could be replaced on a
> > rolling basis as needed. Then neither team is likely to have a complete
> > turnover and lose corporate memory/ take a while to get organized and
> > block other people's work.
>
> I very much agree with you that keeping people around and rolling
> replacement is important. From my experience with MOTU SRU it takes a while
> before you really get into the swing of things and I feel like as long as
> people are willing to server we are better off keeping people in these
> teams. Two years seems a bit long though, I would've gone for one year but
> 6 months seems too short.
>
> Overall, there's sort of two things I think are important when it comes to
> team membership terms. We want to balance keeping good people in and
> letting people who don't have time/interest leave gracefully. Perhaps the 6
> month and 2 year suggestions could be combined by having 2 year terms with
> 6 month "pings" to see any members wish to resign. That way people don't
> feel neccesarily obligated to 2 years (that's quite a long time in Ubuntu
> terms) but avoids having whole new votes every 6 months.
>
> -Jordan

I think this is a good middle ground. I support it.

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-01-2008, 09:21 PM
Emilio Pozuelo Monfort
 
Default policy for membership in MOTU key teams

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.


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

>
> 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.
>
> 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.
>
> 3/ The MC adds the accepted candidates to the appropriate teams.
>
> 4/ If all the vacancies haven't been fulfilled, another call for members may be
> done, after a time of one week.
>
>
> 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?).
> - How the voting works.

Emilio

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-02-2008, 06:48 AM
Stephan Hermann
 
Default policy for membership in MOTU key teams

Good Morning,

On Fri, 23 May 2008 19:26:40 +0200
Stefan Potyra <sistpoty@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.


IMHO

Regards,

sh

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-02-2008, 11:29 AM
"Cody A.W. Somerville"
 
Default policy for membership in MOTU key teams

Hello,

On Tue, Jul 1, 2008 at 6:21 PM, Emilio Pozuelo Monfort <pochu@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@sourcecode.de> wrote:

Good Morning,


On Fri, 23 May 2008 19:26:40 +0200

Stefan Potyra <sistpoty@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:

Voters cast their ballot where they rank every candidate by preference.A quota is calculated and any candidate who has reached or exceeded the required quota is declared elected.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.
If still no one meets the quota, the candidate with the fewest votes is eliminated and their votes are transferred.*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, 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@redcow.ca
http://www.redcow.ca
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 

Thread Tools




All times are GMT. The time now is 09:55 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org