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 07-02-2008, 01:45 PM
"Jordan Mantha"
 
Default policy for membership in MOTU key teams

On Wed, Jul 2, 2008 at 4:29 AM, Cody A.W. Somerville
<cody-somerville@ubuntu.com> wrote:
> Hello,
>
> On Tue, Jul 1, 2008 at 6:21 PM, Emilio Pozuelo Monfort <pochu@ubuntu.com>
> wrote:
<looooong snip>

I think that Cody's really got some good thoughts going on here and
I'd like to thank him and Emilio for working on this. My view is
simply:

1) 2 release, rolling terms is good (i.e. 1/2 of the members are
elected each release). New blood is good, but it needs to be tempered
with experience. We want new people to re-energize teams and have a
chance to "learn the ropes" but these teams are also very important to
the quality of our processes so we shouldn't take them lightly either.

2) STV + droop quota is a very nice voting system. It is fairly
accurate to how I would *like* to vote in that I very very rarely want
to vote against somebody, I just prefer some candidates over others
for the job at hand. STV also seems fairly simple as voting systems
go, especially when trying to fill multiple positions.

3) I'd rather the MOTU Council stay out of filling positions and just
work on conflict resolution and MOTU/Universe Contributor memberships.
I would let the existing team figure out how best to proceed if
members are lost mid-stream, as they know their situation best. Either
then can make it with the members they have, call for a quick
election, or make an interim appointment.

-Jordan

--
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, 01:50 PM
"Emmet Hikory"
 
Default policy for membership in MOTU key teams

Stephan Hermann wrote:
> Stefan Potyra wrote:
>> 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".

I believe there are certain sorts of expertise and interest that
drive people to become part of this team, and that we would do well to
foster that, and encourage repeat activities. That said, if there is
a sufficiency of interest in a rotation, I'd rather create teams to
handle a specific release for the lifecycle of that release (typically
2 years), rather than change membership of the same team each release.

To expand on this, each team would be selected during the
toolchain wait for a release, based on their individual documented
plans for the release and familiarity with release planning processes.
This team would then be responsible for ensuring the quality of the
release: focusing on selecting transitions to pull from Debian,
upstream updates for local packages, general integration, archive
consistency, low bug count, etc. As the release nears, this team
would have a larger and larger role in ensuring that critical issues
are resolved and the chances of regression are reduced. Once the
release happens, this team would coordinate SRUs for the release and
generally watch after the release as is ages. After the following
release (about 1 year after selection), the workload is then further
reduced, as the release fades into senescence, and after the releae
becomes unsupported, the role has expired. This process allows for
reasonably long terms, opportunities for fresh ideas and fresh energy,
and reduces handover confusion between the release team and the
updates team. Further, the experience of working with the various
freezes will help build expertise in the team in code review, likely
improving their ability to do SRU work. Lastly, by having individuals
responsible for a single release, the chances that those people have
that release running and available for testing are very much
increased.

Despite the attractiveness of such a solution, I believe that the
various stages of release planning require very different
personalities, and that we would do well to foster the development of
expertise at the given role in those of us who have those
personalities, rather than encouraging lots of turnover or expecting
people to fufill multiple roles (although some may also be good at
this). I see three key portions of release management, as follows:

1: Definition of target goals for release
2: Monitoring and coordination to meet freeze requirements
3: Regression potential analysis for release updates

In the first portion, we would do well to have people who are
familiar with upstream plans, have a good understanding of upcoming
transitions planned for Debian, and keep track of plans by various
Ubuntu teams. These individuals would be in the best shape to help
determine what goals can be achieved, and what coordination between
groups is needed to avoid conflict and confusion. I would expect this
coordination and review to happen early in the cycle, and be
essentially static by Feature Freeze (as we're not likely to be making
many significant changes after FeatureFreeze, unless we've done a poor
job of coordination).

In the second portion, we would do well to have people who are
good at regression analysis and testing, and who understand how any
given set of changes is likely to impact other aspects of the release.
Rather than being communicators and coordinators, these people are
more reviewers and controllers, and have secondary focii on archive
consistency, verification that everything works (to some acceptable
minimum level), and oversight of integration testing of any last-minut
updates. I would expect this work to start around FeatureFreeze, and
last through to the final release (at least for packages not included
on any pre-built images).

In the third portion, we would do well to have people who are good
at code review in many languages, have good relationships with the
various QA teams, and a strong understanding of common issues related
to handling updates for stable releases (given that many of the
assumptions that may be safe in a development release do not apply for
stable release updates). While these people are also reviewers and
controllers, this role is much more about understanding the specific
change, the entirely of the implications of making such a change, and
striving for minimal visibilty to users beyond targeted solutions to
known problems (be they user-reported bugs or otherwise), which
strikes me as different than the sort of review done pre-release. I
would expect this work to start around FinalFreeze, with the team
familiarising themselves with the changes for the new release, and
continue for the remainder of the lifecycle of the release.

If these teams do require the different skillsets and mindsets
described above, there is significant value in preserving the
expertise through several cycles (an argument against turnover),
clearly segmenting the teams and their roles (an argument against
merging the teams), and replacing team members through a process more
closely related to apprenticeship than any sort of election (assuming
that MOTU provides general oversight to avoid excessive insularity).

--
Emmet HIKORY

--
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, 07:50 PM
Scott Kitterman
 
Default policy for membership in MOTU key teams

On Wednesday 02 July 2008 02:48, Stephan Hermann 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 think some rotation is good, but not wholesale. I'd support a longer term
with staggered vacancies so we don't start over entirely.

The other thing is that we are not exactly over-run with volunteers. I
volunteered for motu-sru on the 2nd round after we didn't get enough on the
first. I've be glad to volunteer for a short initial term on motu-sru to get
the cycle started.

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-02-2008, 08:29 PM
Scott Kitterman
 
Default policy for membership in MOTU key teams

On Wednesday 02 July 2008 07:29, Cody A.W. Somerville wrote:
> 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.

As long as not everyone expires at the same time this sounds fine.

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

We should use an actual election system, not the botched system in Launchpad.
My preference would be for http://en.wikipedia.org/wiki/Condorcet_method. We
can use something like http://www.cs.cornell.edu/andru/civs.html until
Launchpad grows some useful functionality in this area.

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

Ask again for more volunteers. It worked just fine for motu-sru this time.

... snip

I don't think we need to decide numbers in advance.

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

No. I don't think they should do this. They can help find solutions to
disputes and encourage volunteers, but that's it.

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

Rolling changes are good.

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

... snip

Actuall I think it's not. There is a lot of research supporting the
http://en.wikipedia.org/wiki/Condorcet_method and services that support it.
It's a little complex in the theory, but actual voting is just ranking your
preferences.

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-02-2008, 10:31 PM
"Cody A.W. Somerville"
 
Default policy for membership in MOTU key teams

On Wed, Jul 2, 2008 at 5:29 PM, Scott Kitterman <ubuntu@kitterman.com> wrote:

On Wednesday 02 July 2008 07:29, Cody A.W. Somerville wrote:

> Hello,

<snip>
*





>

> This is probably the toughest part to figure out: "How the voting works".



... *snip



Actuall I think it's not. * There is a lot of research supporting *the

http://en.wikipedia.org/wiki/Condorcet_method and services that support it.

It's a little complex in the theory, but actual voting is just ranking your

preferences.



Scott K

For those not familiar, the Condorcet method is the method used by Debian. Personally, I'm not overly familiar myself but I've attempted to do some research for the benefit of the crowd.


What benefits does the Condorcet method provide over Single Transferable Vote? From what I see, both systems are preferential voting systems however the Condorcet method is exceedingly more complex than STV and is classed as a single member system (ie. engineered to elect one member) where STV is classified as a multi-member system. Although STV suffers from the issue of sequential exclusions (meaning that sometimes STV eliminates at an early stage in the count a candidate who might have gone on to be elected later had they been allowed to remain in the contest), there have been a number of recent refinements to STV such as CPO-STV and Sequential STV which solve the problem by incorporating elements of the Condorcet methods into STV. Alternatively, a method known as BTR-STV deals with the problem with a completely different (but exceedingly more simple than the other systems) solution by simply making sure no candidate could possible be eliminated. On the other hands, a neat feature of Condorcet is that it is possible for a candidate to be the most preferred *overall* without being the first preference of on any of the ballots yielding a compromise candidate whom the largest majority will find to be the least disagreeable even if not their top pick. This may or may not be desired (I'm not sure).


So what *is* the "Condorcet method", well it isn't actually *a* method but a set of criteria. When people refer to the Condorcet method, they are talking about any single-winner election method that meets the Condorcet criterion. What is the criterion? Basically that the system has to always selects the Condorcet winner. What is the Condorcet winner? It is he candidate who would beat each of the other candidates in a run-off
election (there is actually a few different types of run-off elections to boot but in this context I would describe it as the guy who gets the majority votes if everyone voted on only those two people) . In modern examples, voters rank candidates in order of
preference but things get very tricky from there as there is need to resolve circular ambiguities. This situation emerges when, once all votes have been added up, the
preferences of voters with respect to some candidates form a circle in
which every candidate is beaten by at least one other candidate. An example borrowed from wikipedia is if there are three candidates, Alex, Cody and David,
there will be no Condorcet winner if voters prefer Alex to Cody and Cody to David, but also David to Alex. Frustratingly, depending on the context
in which elections are held, circular ambiguities may or may not be a
common occurrence .

Now, if the Condorcett method is meant to elect a single member only how would we use it? Well, it will actually produce a list and I'd suppose we'd pick the number the highest ranking individuals? Erm... maybe? I suppose it depends on the exact system used. Earlier I said that Debian uses the Condorcet method but now you must be wondering which method they *really* use now that you know what Condorcet is really all about. The name is "the Schulze method", aka Schwartz Sequential Dropping (SSD), Cloneproof Schwartz Sequential Dropping (CSSD), Beatpath Method, Beatpath Winner, Path Voting, and Path Winner. In this system,
each ballot contains a complete list of all candidates and the
individual voter ranks this list in order of preference. Generally, ascending numbers are
used, whereby the voter places a '1' beside the most preferred
candidate, a '2' beside the second-most preferred, and so forth. Sounds like how one might vote on a Single Transferable Ballot, no? Just wait... it isn't so simple. Voters
may give the *same* preference to more than one candidate and *may keep
candidates unranked*. If the latter occur (ie. doesn't rank all candidates)
then it is assumed that all ranked candidates are strictly preferred to those that he or she did not rank and indifferent between the non-ranked candidates. Then to determine the actual winner (this is a single-member system remember), it determines the "strongest path". The following is from wikipedia:


Procedure

Suppose d[V,W] is the number of voters who strictly prefer candidate V to candidate W.


A path from candidate X to candidate Y of strength p is a sequence of candidates C(1),...,C(n) with the following properties:

C(1) = X and C(n) = Y.For all i = 1,...,(n-1): d[C(i),C(i+1)] > d[C(i+1),C(i)].For all i = 1,...,(n-1): d[C(i),C(i+1)] ≥ p.

p[A,B], the strength of the strongest path from candidate A
to candidate B, is the maximum value such that there is a path from
candidate A to candidate B of that strength. If there is no path from
candidate A to candidate B at all, then p[A,B]*: = 0.

Candidate D is better than candidate E if and only if p[D,E] > p[E,D].

Candidate D is a potential winner if and only if p[D,E] ≥ p[E,D] for every other candidate E.

Confused? No worries. This system actually comes with a tutorial (albeit in German).

I'll just stop here (lots on Wikipedia you can read though). So, why am I still leaning in favor of the Single Transferable Vote (or a refined version that sees that STV meets the monotonic criterion)? Because it is a *multi-member*, proportional representative, preferential electoral system and is *significantly simpler* then any of the Condorcet methods. Do we really care that Schwartz Sequential Dropping meets Condorcet loser, clone independence, reversal symmetry, polynomial time, and local independence of irrelevant alternatives criterion when it is so complicated that a lengthy manual is required to actual determine who is the winner not to mention further complex circular ambiguity resolutions using yet another voting system? Besides, according to Wikipedia, Condorcet methods are not currently in use in government elections anywhere in the world - although a Condorcet method known as Nanson's method was used in city elections in the U.S. town of Marquette, Michigan in the 1920s, and today Condorcet methods are used by a number of private organisations (Debian, Wikimedia Foundation, Gentoo Foundation all use SSD) . If you've seen some of the vote pages for Debian, you'll see all sorts of lovely matrices and graphs and what not and hey, it might look nice but I think we'll get desired results with a much simpler to understand system that is actually geared towards what we're dong. Maybe in the future when our numbers are larger and we run into some of the electoral corner cases SSD (or something else) would be more appropriate but for now STV seems to serve the purpose rather well.


I should also note there is already software out there to calculate both STV and SSD.

Just to clarify, this e-mail isn't a vote *against* SSD or anything like that, just me expressing that SSD seems like overkill for now.


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
 
Old 07-03-2008, 06:06 AM
Scott Kitterman
 
Default policy for membership in MOTU key teams

On Wednesday 02 July 2008 18:31, Cody A.W. Somerville wrote:
> On Wed, Jul 2, 2008 at 5:29 PM, Scott Kitterman <ubuntu@kitterman.com>
>
> wrote:
> > On Wednesday 02 July 2008 07:29, Cody A.W. Somerville wrote:
> > > Hello,
>
> <snip>
>
> > > This is probably the toughest part to figure out: "How the voting
> > > works".
> >
> > ... snip
> >
> > Actuall I think it's not. There is a lot of research supporting the
> > http://en.wikipedia.org/wiki/Condorcet_method and services that support
> > it.
> > It's a little complex in the theory, but actual voting is just ranking
> > your preferences.
> >
> > Scott K
>
> For those not familiar, the Condorcet method is the method used by Debian.
> Personally, I'm not overly familiar myself but I've attempted to do some
> research for the benefit of the crowd.
>
> What benefits does the Condorcet method provide over Single Transferable
> Vote? From what I see, both systems are preferential voting systems however
> the Condorcet method is exceedingly more complex than STV and is classed as
> a single member system (ie. engineered to elect one member) where STV is
> classified as a multi-member system. Although STV suffers from the issue of
> sequential exclusions (meaning that sometimes STV eliminates at an early
> stage in the count a candidate who might have gone on to be elected later
> had they been allowed to remain in the contest), there have been a number
> of recent refinements to STV such as CPO-STV and Sequential STV which solve
> the problem by incorporating elements of the Condorcet methods into STV.
> Alternatively, a method known as BTR-STV deals with the problem with a
> completely different (but exceedingly more simple than the other systems)
> solution by simply making sure no candidate could possible be eliminated.
> On the other hands, a neat feature of Condorcet is that it is possible for
> a candidate to be the most preferred *overall* without being the first
> preference of on any of the ballots yielding a compromise candidate whom
> the largest majority will find to be the least disagreeable even if not
> their top pick. This may or may not be desired (I'm not sure).

I think this is a very Ubuntu feature.

In general, Condorcet methods are more resistant to strategic voting and will
tend to produce a fairer result. The only downside is the complexity, but I
don't think it matters since we aren't going to figure it out by hand.

...snip

> I'll just stop here (lots on Wikipedia you can read though). So, why am I
> still leaning in favor of the Single Transferable Vote (or a refined
> version that sees that STV meets the monotonic criterion)? Because it is a
> *multi-member*, proportional representative, preferential electoral system
> and is *significantly simpler* then any of the Condorcet methods. Do we
> really care that Schwartz Sequential Dropping meets Condorcet loser, clone
> independence, reversal symmetry, polynomial time, and local independence of
> irrelevant alternatives criterion when it is so complicated that a lengthy
> manual is required to actual determine who is the winner not to mention
> further complex circular ambiguity resolutions using yet another voting
> system? Besides, according to Wikipedia, Condorcet methods are not
> currently in use in government elections anywhere in the world - although a
> Condorcet method known as Nanson's method was used in city elections in the
> U.S. town of Marquette, Michigan in the 1920s, and today Condorcet methods
> are used by a number of private organisations (Debian, Wikimedia
> Foundation, Gentoo Foundation all use SSD) . If you've seen some of the
> vote pages for Debian, you'll see all sorts of lovely matrices and graphs
> and what not and hey, it might look nice but I think we'll get desired
> results with a much simpler to understand system that is actually geared
> towards what we're dong. Maybe in the future when our numbers are larger
> and we run into some of the electoral corner cases SSD (or something else)
> would be more appropriate but for now STV seems to serve the purpose rather
> well.
>
> I should also note there is already software out there to calculate both
> STV and SSD.
>
> Just to clarify, this e-mail isn't a vote *against* SSD or anything like
> that, just me expressing that SSD seems like overkill for now.
>
In my experience Condercet methods work quick well with multiple selection
votes too and retain their resistance to strategic voting. In either case we
wouldn't count it by hand, so the complexity of counting isn't a significant
factor.

Yes, Debian does like the fancy charts to prove they got a correct result.
Here is an example (another election I was in) that shows how easy it is:

http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_8e5a1ca7f86a5d5d

I'd rather just use the best system to begin with rather than have to worry
about when we need to change.

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-03-2008, 08:07 AM
"Cody A.W. Somerville"
 
Default policy for membership in MOTU key teams

On Thu, Jul 3, 2008 at 3:06 AM, Scott Kitterman <ubuntu@kitterman.com> wrote:

On Wednesday 02 July 2008 18:31, Cody A.W. Somerville wrote:

> On Wed, Jul 2, 2008 at 5:29 PM, Scott Kitterman <ubuntu@kitterman.com>

><snip>


In my experience Condercet methods work quick well with multiple selection

votes too and retain their resistance to strategic voting. *In either case we

wouldn't count it by hand, so the complexity of counting isn't a significant

factor.



Yes, Debian does like the fancy charts to prove they got a correct result.

Here is an example (another election I was in) that shows how easy it is:



http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_8e5a1ca7f86a5d5d



I'd rather just use the best system to begin with rather than have to worry

about when we need to change.
How is a Condorcet system superior exactly? According to the Gibbard-Satterthwaite theorem, tactical voting is possible in all non-dictatorial deterministic
voting systems. I fail to see how it is more resistant to strategic voting (I can describe a number of methods for you).* Furthermore, the small number of methods of tactical or strategic voting that does exist for elections conducted using STV in general only are effective in marginal district... but do we really need to worry so much about strategic voting? Strategic voting really comes into play when there are "parties" involved (we don't have that). And do we want an individual least un-preferred (Condorcet) or most preferred (STV)?


The biggest fault that I can see with STV would be that it fails the monotonicity criteria but it is important to note that *no* preference voting system satisfies all the criteria described in Arrow's impossibility theorem. For example with Schulze (the actual system I think you're proposing) it fails to meet independence of irrelevant alternatives, participation, consistency, invulnerability to compromising, invulnerability to burying, and later-no-harm criteria.


And to hit the simple point home a bit more, don't you think we'd all have a bit more faith in a system that we could actually figure out the result on our own? Personally, I don't want my vote going into some black box which magically produces a set of winning candidates.


I'm not suggesting that STV is the choice we go with but I don't think Condorcet is either "just because".
*




Scott K



--

Ubuntu-motu mailing list

Ubuntu-motu@lists.ubuntu.com

Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu



--
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
 
Old 07-04-2008, 07:25 PM
Stefan Potyra
 
Default policy for membership in MOTU key teams

Hi folks,

since we're trying out the new MOTU decision making process [1, 2], I'm asking
if anyone of you would like to act as a "shepherd" for this discussion.

Since I started the discussion with my initial mail, I guess I'm out due to
policy.

Nonetheless, I'd volunteer, if noone else would like to step in, and noone
raises any objections in this regard until Sunday evening (from an UTC+2 POV).

Cheers,
Stefan.
--
[1]: <https://lists.ubuntu.com/archives/ubuntu-motu/2008-June/004060.html>
[2]: <https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004177.html>
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-04-2008, 07:44 PM
Scott Kitterman
 
Default policy for membership in MOTU key teams

On Fri, 4 Jul 2008 21:25:20 +0200 Stefan Potyra <sistpoty@ubuntu.com> wrote:
>Hi folks,
>
>since we're trying out the new MOTU decision making process [1, 2], I'm
asking
>if anyone of you would like to act as a "shepherd" for this discussion.
>
>Since I started the discussion with my initial mail, I guess I'm out due
to
>policy.
>
>Nonetheless, I'd volunteer, if noone else would like to step in, and noone
>raises any objections in this regard until Sunday evening (from an UTC+2
POV).
>
The idea is we discuss this at the next meeting and pick the shepherd
there. If you are interested, please show up.

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-05-2008, 02:24 AM
Emilio Pozuelo Monfort
 
Default policy for membership in MOTU key teams

Cody A.W. Somerville wrote:
> 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

Thanks a lot to you too for this! I like many of your comments and ideas. I
don't have the time right now to answer to this in detail and may not be able to
do it anytime soon, but please keep moving on with this!

Best,
Emilio

--
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 03:29 AM.

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