Proposals, discussions and announcements

Josip Rodin | 8 Oct 2007 17:33

electing multiple people

Hi,

During the discussion on the proposed social committee, I proposed that we
elect (all) the members of that committee. The Debian Constitution currently
doesn't provide for a way to do so - it only describes how a single winner
is decided.

So, I proposed the following addition to the section A.6. Vote Counting
(part of appendix A Standard Resolution Procedure):

+        If the election requires multiple winners, the list of winners is
+        created by sorting the list of options by ascending strength.
+        If there are multiple winners with the same ranking which exceed
+        the desired length of the list, the length of the list is extended
+        to include the entire last set of multiple winners.

Is this technically sound? I don't know voting method syntax.

[I posted this on -project, but nobody really commented on it, that's why
I'm re-posting to -vote.]

By "sorting the list of options by ascending strength" I refer to that list
we get from the beat matrix, such as in:

http://www.debian.org/vote/2007/vote_001#outcome

If for example in that outcome we wanted to pick four candidates, it
seems to me that they would be Hocever, McIntyre, Herzog, Verhelst.
If for example we wanted to pick seven, we couldn't go past the first six.

(Continue reading)

headers

Ian Jackson | 9 Oct 2007 20:45

Re: electing multiple people

Josip Rodin writes ("electing multiple people"):
> So, I proposed the following addition to the section A.6. Vote Counting
> (part of appendix A Standard Resolution Procedure):

As I've said in the meeting at Debconf and on debian-project, I think
this is the wrong way to do because this voting system implicitly asks
the wrong question.

Voting systems like STV and its derivatives (including Condorcet)
assume that:
  * The number of people to be appointed is fixed in advance
  * The candidates ought to compete against each other.
These assumptions are not true for our social committee.

We discussed at some length in the meeting at Debconf the problem with
electing a social committee, namely that a good social committee will
do much of its work informally, quietly and behind the scenes.  So the
most effective members will have nothing to show.

Actively harmful SC members will be easy to spot of course because
they'll cause flamewars etc.  Inactive or lazy SC members are not a
problem and we can just keep them.

So, as I have said before, we should use straight per-candidate
approval voting.

That is: the DPL should propose candidates, which the electorate will
separately vote on.  That is, if the DPL proposes
      Alice
      Bob

(Continue reading)

headers

MJ Ray | 10 Oct 2007 11:55

Re: electing multiple people

Ian Jackson <ian <at> davenant.greenend.org.uk> wrote:
> So, as I have said before, we should use straight per-candidate
> approval voting.
[...]
> and if more people vote `yes' for Alice than vote `no' for Alice then
> Alice is appointed - regardless of any votes for or against Bob,
> Carol, etc.

Isn't that always going to result in an unrepresentative committee?
It looks even more like blackballing than the SPI method.  A majority
could prevent any minority representatives being elected if they wish,
which leads to having only poodles from minorities.  Yuck.

Should team size be determined in advance?  I think so.

There is the oft-mentioned optimal team size of about seven
active members.  http://www.qsm.com/process_01.html
http://knowledge.wharton.upenn.edu/article.cfm?articleid=1501

How many more than seven would we need, to expect seven to be active?

Regards,
--

-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct

headers

Josip Rodin | 10 Oct 2007 14:13

Re: electing multiple people

On Wed, Oct 10, 2007 at 10:55:28AM +0100, MJ Ray wrote:
> There is the oft-mentioned optimal team size of about seven
> active members.  http://www.qsm.com/process_01.html
> http://knowledge.wharton.upenn.edu/article.cfm?articleid=1501
> 
> How many more than seven would we need, to expect seven to be active?

In one of my university classes I was told that the axiomatic overhead
for telecommunications is 40%... and that's just for hardware and software,
no mention of humanware :)

--

-- 
     2. That which causes joy or happiness.

headers

Josip Rodin | 9 Oct 2007 23:22

Re: electing multiple people

On Tue, Oct 09, 2007 at 07:45:53PM +0100, Ian Jackson wrote:
> That is: the DPL should propose candidates, which the electorate will
> separately vote on.

Well, what can I say other than - the scheme where we depend on the DPL to
propose candidates doesn't work if the DPL never does anything even
approaching the actual proposal of candidates :) Maybe it would be best to
put this whole part off until there's a general GR affirming the charter.

--

-- 
     2. That which causes joy or happiness.

headers

Josip Rodin | 9 Oct 2007 09:29

Re: electing multiple people

On Mon, Oct 08, 2007 at 05:33:54PM +0200, Josip Rodin wrote:
> +        If the election requires multiple winners, the list of winners is
> +        created by sorting the list of options by ascending strength.
> +        If there are multiple winners with the same ranking which exceed
> +        the desired length of the list, the length of the list is extended
> +        to include the entire last set of multiple winners.
> 
> Is this technically sound? I don't know voting method syntax.

So, scrapping that - how does the election of multiple candidates in
the SPI board election work? (weasel?)

--

-- 
     2. That which causes joy or happiness.

headers

MJ Ray | 9 Oct 2007 11:41

Re: electing multiple people

Josip Rodin <joy <at> entuzijast.net> wrote: [...]
> So, scrapping that - how does the election of multiple candidates in
> the SPI board election work? (weasel?)

Badly.  I think it's similar to election-by-blacklist.  It seems
particularly vulnerable to prejudice and smears, which should kill off
any debian social committee if those influence its election.  If we
used a similar system, social committee couldn't really predict
consensus with most minorities, because only majority-acceptable
representatives of minorities (poodles?) would get elected.

Proportionality is very important for a social-committee.  If it has
deep disagreements on certain topics (like Anglo-Victorian values, for
example), then it will be correctly reflecting the wider social
situation.  The important thing will be to give it deadlock-busting
working methods.

In more detail on the SPI voting system:
http://comments.gmane.org/gmane.org.spi.general/482
http://mjr.towers.org.uk/blog/2007/spi#elections

Hope that helps,
--

-- 
MJ Ray http://mjr.towers.org.uk/email.html tel:+44-844-4437-237 -
Webmaster-developer, statistician, sysadmin, online shop builder,
consumer and workers co-operative member http://www.ttllp.co.uk/ -
Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/

headers

Steve Langasek | 9 Oct 2007 09:45

Re: electing multiple people

On Tue, Oct 09, 2007 at 09:29:22AM +0200, Josip Rodin wrote:
> On Mon, Oct 08, 2007 at 05:33:54PM +0200, Josip Rodin wrote:
> > +        If the election requires multiple winners, the list of winners is
> > +        created by sorting the list of options by ascending strength.
> > +        If there are multiple winners with the same ranking which exceed
> > +        the desired length of the list, the length of the list is extended
> > +        to include the entire last set of multiple winners.

> > Is this technically sound? I don't know voting method syntax.

> So, scrapping that - how does the election of multiple candidates in
> the SPI board election work? (weasel?)

Poorly, there's no way to rank candidates below NOTA. :)

--

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon <at> debian.org                                   http://www.debian.org/

headers

Antti-Juhani Kaijanaho | 9 Oct 2007 09:50

Re: electing multiple people

On Tue, Oct 09, 2007 at 09:29:22AM +0200, Josip Rodin wrote:
> So, scrapping that - how does the election of multiple candidates in
> the SPI board election work? (weasel?)

It has the same weakness (this was discussed recently in a SPI list).

--

-- 
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/

headers

Anthony Towns | 9 Oct 2007 09:39

Re: electing multiple people

On Tue, Oct 09, 2007 at 09:29:22AM +0200, Josip Rodin wrote:
> On Mon, Oct 08, 2007 at 05:33:54PM +0200, Josip Rodin wrote:
> > +        If the election requires multiple winners, the list of winners is
> > +        created by sorting the list of options by ascending strength.
> > +        If there are multiple winners with the same ranking which exceed
> > +        the desired length of the list, the length of the list is extended
> > +        to include the entire last set of multiple winners.
> > Is this technically sound? I don't know voting method syntax.
> So, scrapping that - how does the election of multiple candidates in
> the SPI board election work? (weasel?)

Basically the way you describe, though with the addition of staggered
terms.

Cheers,
aj

headers

Russ Allbery | 9 Oct 2007 01:48

Re: electing multiple people

Josip Rodin <joy <at> entuzijast.net> writes:

> So, I proposed the following addition to the section A.6. Vote Counting
> (part of appendix A Standard Resolution Procedure):

> +        If the election requires multiple winners, the list of winners is
> +        created by sorting the list of options by ascending strength.
> +        If there are multiple winners with the same ranking which exceed
> +        the desired length of the list, the length of the list is extended
> +        to include the entire last set of multiple winners.

> Is this technically sound? I don't know voting method syntax.

I think this runs the same risk as the original US Vice Presidential
election system.  If you elect the runner-up as part of the same slate as
the winner, you end up with pathological results in a divisive election
with two or more opposing slates.  Basically, you end up electing the
leaders of each slate and calling them the winning group, resulting in a
team of people who have sharp disagreements and who may not be able to
work together.

I've had enough bad experiences with committees and groups in the past
that I've developed a deep dislike of voting or nomination systems that
don't take into account the ability of the chosen slate to work with each
other.  I'd rather end up with a weaker candidate who can cooperate with
the leading candidate than the two strongest candidates who will then be
at loggerheads.

--

-- 
Russ Allbery (rra <at> debian.org)               <http://www.eyrie.org/~eagle/>

(Continue reading)

headers

Josip Rodin | 9 Oct 2007 09:21

Re: electing multiple people

On Mon, Oct 08, 2007 at 04:48:20PM -0700, Russ Allbery wrote:
> I think this runs the same risk as the original US Vice Presidential
> election system.  If you elect the runner-up as part of the same slate as
> the winner, you end up with pathological results in a divisive election
> with two or more opposing slates.  Basically, you end up electing the
> leaders of each slate and calling them the winning group, resulting in a
> team of people who have sharp disagreements and who may not be able to
> work together.
> 
> I've had enough bad experiences with committees and groups in the past
> that I've developed a deep dislike of voting or nomination systems that
> don't take into account the ability of the chosen slate to work with each
> other.  I'd rather end up with a weaker candidate who can cooperate with
> the leading candidate than the two strongest candidates who will then be
> at loggerheads.

That argument makes sense for technical groups, where accomplishing a
clearly defined task is the primary mission, but this is supposed to be
the basis for electing the first ever social committee, which doesn't have
a straightforward mission (or at least, we're inventing the mission ad hoc :).
If the underlying social group is indeed divided into two proportionate
major factions who are in conflict with each other, then that is who should
be in the social committee in order to fairly represent the voting body.
And at the same time, if the voters think that there are two minor factions
with a conflict that doesn't interest the voters, and they are minor, they
will (hopefully) not vote for them so they won't get elected.

--

-- 
     2. That which causes joy or happiness.

(Continue reading)

headers

Russ Allbery | 9 Oct 2007 10:38

Re: electing multiple people

Josip Rodin <joy <at> entuzijast.net> writes:
> On Mon, Oct 08, 2007 at 04:48:20PM -0700, Russ Allbery wrote:

>> I think this runs the same risk as the original US Vice Presidential
>> election system.  If you elect the runner-up as part of the same slate
>> as the winner, you end up with pathological results in a divisive
>> election with two or more opposing slates.  Basically, you end up
>> electing the leaders of each slate and calling them the winning group,
>> resulting in a team of people who have sharp disagreements and who may
>> not be able to work together.

>> I've had enough bad experiences with committees and groups in the past
>> that I've developed a deep dislike of voting or nomination systems that
>> don't take into account the ability of the chosen slate to work with
>> each other.  I'd rather end up with a weaker candidate who can
>> cooperate with the leading candidate than the two strongest candidates
>> who will then be at loggerheads.

> That argument makes sense for technical groups, where accomplishing a
> clearly defined task is the primary mission, but this is supposed to be
> the basis for electing the first ever social committee, which doesn't
> have a straightforward mission (or at least, we're inventing the mission
> ad hoc :).

Hm, my experience is that this is *way* more important for social groups
than it is for technical groups.  Now, if one is electing essentially a
legislature, where each member is expected to vote and work independently,
it's not as big of a problem.  But if the group is ever expected to work
by consensus or common ground, this sort of voting system is, IMO, a huge
problem.

(Continue reading)

headers

Josip Rodin | 9 Oct 2007 10:53

Re: electing multiple people

On Tue, Oct 09, 2007 at 01:38:26AM -0700, Russ Allbery wrote:
> >> I've had enough bad experiences with committees and groups in the past
> >> that I've developed a deep dislike of voting or nomination systems that
> >> don't take into account the ability of the chosen slate to work with
> >> each other.
> 
> > That argument makes sense for technical groups, where accomplishing a
> > clearly defined task is the primary mission, but this is supposed to be
> > the basis for electing the first ever social committee, which doesn't
> > have a straightforward mission (or at least, we're inventing the mission
> > ad hoc :).
> 
> Hm, my experience is that this is *way* more important for social groups
> than it is for technical groups.  Now, if one is electing essentially a
> legislature, where each member is expected to vote and work independently,
> it's not as big of a problem.  But if the group is ever expected to work
> by consensus or common ground, this sort of voting system is, IMO, a huge
> problem.

I don't get it. Isn't the point of "consensus" to get agreement from an
entire group, or at least the entire relevant part of the group? If we use
a voting system that aims to eliminate conflicting options, and instead have
a small set of compatible options win, then that's not really aiming for
a consensus, it's just aiming for a majority.

If the social committee represents only the majority, it instantly loses
credibility, and in Debian, that would pretty much be its ruin.

--

-- 
     2. That which causes joy or happiness.

(Continue reading)

headers

Russ Allbery | 9 Oct 2007 11:22

Re: electing multiple people

Josip Rodin <joy <at> entuzijast.net> writes:
> On Tue, Oct 09, 2007 at 01:38:26AM -0700, Russ Allbery wrote:

>> Hm, my experience is that this is *way* more important for social
>> groups than it is for technical groups.  Now, if one is electing
>> essentially a legislature, where each member is expected to vote and
>> work independently, it's not as big of a problem.  But if the group is
>> ever expected to work by consensus or common ground, this sort of
>> voting system is, IMO, a huge problem.

> I don't get it. Isn't the point of "consensus" to get agreement from an
> entire group, or at least the entire relevant part of the group? If we
> use a voting system that aims to eliminate conflicting options, and
> instead have a small set of compatible options win, then that's not
> really aiming for a consensus, it's just aiming for a majority.

It's not about opinions.  It's about people.  The problem most often
materializes when there are heated opinions, but the fundamental problem
is when people can't work together with mutual respect.  If you end up
with people who intensely dislike each other, the group will have an
exceedingly hard time reaching consensus on anything.

It's one of those sorts of landmine situations where it looks like it
works fine up until the point where there's a major problem that provokes
a lot of heated disagreement, and that's when the body designed to try to
defuse such situations is most vulnerable to a breakdown of civility and
willingness to work together among its members.

One of the things that I find troubling about the idea of the social
committee is that I think it takes the idea of a democratic body and some

(Continue reading)

headers

Josip Rodin | 9 Oct 2007 14:19

Re: electing multiple people

On Tue, Oct 09, 2007 at 02:22:41AM -0700, Russ Allbery wrote:
> The problem most often materializes when there are heated opinions, but
> the fundamental problem is when people can't work together with mutual
> respect.  If you end up with people who intensely dislike each other, the
> group will have an exceedingly hard time reaching consensus on anything.

MJ and Bernhard made good points already, I'll just concentrate on a few
bits that troubled me: I don't agree with these two premises - that any
two elected Debianites would so intensely dislike each other to cause
a deadlock in the rest of the group, or that this deadlock would spread
onto all other issues (other than the one they over which they originally
came in conflict). I do not see any historical precedent in Debian history
to reach that harsh a conclusion.

> One of the things that I find troubling about the idea of the social
> committee is that I think it takes the idea of a democratic body and some
> vague notions that smart people can work anything out and applies them to
> problems that are considerably thornier than the technical problems our
> existing example deals with.  Constructing organizations that can
> effectively deal with social problems is way harder than constructing a
> technical committee and I'm worried that insufficient attention is being
> paid to some of the fuzzier aspects of how such a group can work together.

It's not just a matter of us Debianites really being smart people who can
work anything out :) it's that we actually currently try to do the soc-ctte
job in conflict situations *without* having a soc-ctte, and we generally
succeed. And the whole project is practically a social experiment, we deal
with social problems every day, whenever there's a misunderstanding on a bug
report or a squabble on the mailing lists. Having soc-ctte couldn't undo
this history of good faith effort to get along with each other; should it

(Continue reading)

headers

Manoj Srivastava | 9 Oct 2007 16:24

Re: electing multiple people

On Tue, 9 Oct 2007 14:19:43 +0200, Josip Rodin <joy <at> entuzijast.net> said: 

> On Tue, Oct 09, 2007 at 02:22:41AM -0700, Russ Allbery wrote:
>> The problem most often materializes when there are heated opinions,
>> but the fundamental problem is when people can't work together with
>> mutual respect.  If you end up with people who intensely dislike each
>> other, the group will have an exceedingly hard time reaching
>> consensus on anything.

> MJ and Bernhard made good points already, I'll just concentrate on a
> few bits that troubled me: I don't agree with these two premises -
> that any two elected Debianites would so intensely dislike each other
> to cause a deadlock in the rest of the group, or that this deadlock
> would spread onto all other issues (other than the one they over which
> they originally came in conflict). I do not see any historical
> precedent in Debian history to reach that harsh a conclusion.

        Err. I see an immediate historical precedent, which in fact lead
 to a recent expulsion.  Several mailing lists became poisoned to the
 level that people left off volunteering. If it happened once, it can
 happen again ...

        manoj
--

-- 
Why don't you fix your little problem... and light this candle? Alan
Shepherd, the first man into space, Gemini program
Manoj Srivastava <srivasta <at> debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

(Continue reading)

headers

Josip Rodin | 9 Oct 2007 17:17

Re: electing multiple people

On Tue, Oct 09, 2007 at 09:24:41AM -0500, Manoj Srivastava wrote:
> >> The problem most often materializes when there are heated opinions,
> >> but the fundamental problem is when people can't work together with
> >> mutual respect.  If you end up with people who intensely dislike each
> >> other, the group will have an exceedingly hard time reaching
> >> consensus on anything.
> 
> > MJ and Bernhard made good points already, I'll just concentrate on a
> > few bits that troubled me: I don't agree with these two premises -
> > that any two elected Debianites would so intensely dislike each other
> > to cause a deadlock in the rest of the group, or that this deadlock
> > would spread onto all other issues (other than the one they over which
> > they originally came in conflict). I do not see any historical
> > precedent in Debian history to reach that harsh a conclusion.
> 
>         Err. I see an immediate historical precedent, which in fact lead
>  to a recent expulsion.  Several mailing lists became poisoned to the
>  level that people left off volunteering. If it happened once, it can
>  happen again ...

Oh, but that's just not the same, the expulsed person was not an elected
member of a general committee.

The best historical precedents for a lot of disagreement on general
positions was when everyone was pissed off at Bruce, or even better when
aj and you disagreed about policy, but those situations were settled in
a much calm manner than the Sven affair.

--

-- 
     2. That which causes joy or happiness.

(Continue reading)

headers

Bas Wijnen | 9 Oct 2007 12:43

Social committee, legislature, sanctioning (was: Re: electing multiple people)

On Tue, Oct 09, 2007 at 02:22:41AM -0700, Russ Allbery wrote:
> It's not about opinions.  It's about people.  The problem most often
> materializes when there are heated opinions, but the fundamental problem
> is when people can't work together with mutual respect.  If you end up
> with people who intensely dislike each other, the group will have an
> exceedingly hard time reaching consensus on anything.

It is very important that the people in the Social Committee can work
together well.  If we can use a voting system which makes sure we don't
elect people who dislike each other, we certainly should.  But that
doesn't mean they all have to be on the same side of important
arguments.  The members of the committee must respect each other, so
they can work together.  But they must also represent both sides (or
none) of any argument, so that they are acceptable as a mediator for
both conflicting parties.

> It's one of those sorts of landmine situations where it looks like it
> works fine up until the point where there's a major problem that provokes
> a lot of heated disagreement, and that's when the body designed to try to
> defuse such situations is most vulnerable to a breakdown of civility and
> willingness to work together among its members.

Of course.  It's a hard job, and it will likely be hard to keep the
committee together at times (but those times are exactly what the
committee is set up for).  I'm confident that we vote for people who we
expect to be good at that.  But that quality is orthogonal to most
conflicts, so having all people in the committee being able to work
together even in hard times doesn't mean they cannot be representative.

> One of the things that I find troubling about the idea of the social

(Continue reading)

headers

Russ Allbery | 9 Oct 2007 23:54

Re: Social committee, legislature, sanctioning

Bas Wijnen <wijnen <at> debian.org> writes:
> On Tue, Oct 09, 2007 at 02:22:41AM -0700, Russ Allbery wrote:

>> One of the things that I find troubling about the idea of the social
>> committee is that I think it takes the idea of a democratic body and
>> some vague notions that smart people can work anything out and applies
>> them to problems that are considerably thornier than the technical
>> problems our existing example deals with.

> I'm not sure what example you're talking about, but I think we all agree
> that what we're trying to solve is an extremely hard problem.  But we're
> Debian.  We try anyway.  And we try to do it the best way possible, not
> just acceptable. 

The tech-ctte is the example that I think the soc-ctte is partly modelled
after.  It works pretty well and handles internal disagreements, but it's
aided in that by the fact that the questions are very technical and voting
is used to resolve disagreements.  I'm not sure the same tools would work
here.  Taking votes on difficult personal issues often ends up being a
lose-lose situation, where every voting outcome escalates the situation in
a different way and at least creates the appearance of factions.

I do want to stress, though, that I may be too pessimistic and I don't
want people to stop trying to put something together.  I'm more just
airing my worries in case they spark any thought or in case thinking about
them in advance helps head them off.

--

-- 
Russ Allbery (rra <at> debian.org)               <http://www.eyrie.org/~eagle/>

(Continue reading)

headers

Bas Wijnen | 10 Oct 2007 11:00

Re: Social committee, legislature, sanctioning

On Tue, Oct 09, 2007 at 02:54:00PM -0700, Russ Allbery wrote:
> The tech-ctte is the example that I think the soc-ctte is partly modelled
> after.  It works pretty well and handles internal disagreements, but it's
> aided in that by the fact that the questions are very technical and voting
> is used to resolve disagreements.  I'm not sure the same tools would work
> here.  Taking votes on difficult personal issues often ends up being a
> lose-lose situation, where every voting outcome escalates the situation in
> a different way and at least creates the appearance of factions.

Agreed.  IMO the social committee must not vote, in fact it mustn't ever
decide who is Right and who is Wrong.  For that, we could use some
"judges".  Combining the function of mediator and judge in one committee
will very likely escalate problems instead of solve them.

What I think is the main task of the social committee is to defuse
situations when that is still possible.  So they must be there early on.
Some policing helps there (kicking people off IRC channels, temporary
list bans, that sort of thing), because either people will think about
their actions and conclude the sanction was appropriate, or they will
get angry and request mediation (hopefully).  Without the sanction, the
problems can grow while they remain unnoticed until it's too late to
solve them.

Thanks,
Bas

--

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text

(Continue reading)

headers

MJ Ray | 9 Oct 2007 11:59

Re: electing multiple people

Russ Allbery <rra <at> debian.org> wrote: [...]
> It's not about opinions.  It's about people.  The problem most often
> materializes when there are heated opinions, but the fundamental problem
> is when people can't work together with mutual respect.  If you end up
> with people who intensely dislike each other, the group will have an
> exceedingly hard time reaching consensus on anything.

There are two situations in danger of being confused there:
 - people who intensely dislike each other; and
 - people who intensely dislike each other's views.

> [...] unless there's some feeling that the other members of the
> committee "have one's back" so to speak and are willing to put some effort
> into presenting a united front, I think you're going to have a really
> serious burnout problem.

I would be disappointed and fairly concerned about a social committee
which presented a united front in most ways, except how to deal with a
problem.  I think we should be expecting a social committee that
speaks with several voices about a problem, but agrees a course of
action.

> [...]  In other words, to what degree is the committee expected to be
> a decision-making body and to what degree is it expected to be a
> facilitator?

Personally, I expect it to be a facilitator almost always and almost
never a decision-making body.  Sometimes I expect it to suggest how to
decide something, but give everyone involved opportunities to avoid a
destructive decision by their own actions.

(Continue reading)

headers

Bernhard R. Link | 9 Oct 2007 11:33

Re: electing multiple people

* Russ Allbery <rra <at> debian.org> [071009 11:23]:
> It's not about opinions.  It's about people.  The problem most often
> materializes when there are heated opinions, but the fundamental problem
> is when people can't work together with mutual respect.  If you end up
> with people who intensely dislike each other, the group will have an
> exceedingly hard time reaching consensus on anything.
>
> It's one of those sorts of landmine situations where it looks like it
> works fine up until the point where there's a major problem that provokes
> a lot of heated disagreement, and that's when the body designed to try to
> defuse such situations is most vulnerable to a breakdown of civility and
> willingness to work together among its members.

But if there is such an situation and there is heated disagreement
outside of this body, how would having only one side of that in the body
help? That would only make a body supposed to defuse such a situation
to be weapon for one side and thus could even rise such a problem to
much higher spheres.

Thus I think something more proportional is better than something more
cloneful. Unless someone comes up with an idea for a system where anyone
disliked stronly by a reasonable large minority cannot become elected at
all. (and that system is not vulnerable to tactical voting, which I
think it most likely would be as there is no way to let people honestly
distinguish between "I dislike" and "I like the other side better").

Hochachtungsvoll,
	Bernhard R. Link

(Continue reading)

headers

Russ Allbery | 9 Oct 2007 23:50

Re: electing multiple people

"Bernhard R. Link" <brlink <at> debian.org> writes:

> But if there is such an situation and there is heated disagreement
> outside of this body, how would having only one side of that in the body
> help? That would only make a body supposed to defuse such a situation to
> be weapon for one side and thus could even rise such a problem to much
> higher spheres.

It depends.  Being able to reach consensus may make it easier for the
soc-ctte to look at the situation and go "there's strong disagreement here
and even if we're mostly on one side, we realize that and we should decide
that we can't really intervene."  I don't know if that's more likely or
less likely with a group of people who work well together but may be
mostly or entirely on one side of an issue, or with a group of people who
are representative but don't work well together.

> Thus I think something more proportional is better than something more
> cloneful. Unless someone comes up with an idea for a system where anyone
> disliked stronly by a reasonable large minority cannot become elected at
> all. (and that system is not vulnerable to tactical voting, which I
> think it most likely would be as there is no way to let people honestly
> distinguish between "I dislike" and "I like the other side better").

Try this reduction of my worry (which may be very unlikely):  Suppose we
have two basic factions in Debian, one that thinks the soc-ctte is a good
idea, and one that thinks it's a horrible idea.  If you have proportional
representation of both sides, that means you should elect a few people to
the soc-ctte who think it's a horrible idea and should never do anything.
If those people act to represent their constituency, they should try to
block any action by the soc-ctte on any topic.  What does that do to the

(Continue reading)

headers

MJ Ray | 10 Oct 2007 12:02

soc-ctte default position, was: electing multiple people

Russ Allbery <rra <at> debian.org> wrote:
> It depends.  Being able to reach consensus may make it easier for the
> soc-ctte to look at the situation and go "there's strong disagreement here
> and even if we're mostly on one side, we realize that and we should decide
> that we can't really intervene."  [...]

This raises a question.

I assumed that soc-ctte would intervene somehow on any issue referred
to them, even if it is just to say "let the existing processes stand".
If it ends up at soc-ctte, there is a problem to resolve.

However, the above suggests that if soc-ctte is weakly divided (mostly
on one side), it shouldn't intervene.

What should be soc-ctte's default position?  To do nothing, or to
announce their (maybe-weak) support for the existing situation?

As you may know, I believe that ignoring problems is a bug, so I'd
expect soc-ctte to make decisions, even if mostly null, rather than do
nothing.  If it will mostly do nothing, is it worth creating it?

Regards,
--

-- 
MJ Ray http://mjr.towers.org.uk/email.html tel:+44-844-4437-237 -
Webmaster-developer, statistician, sysadmin, online shop builder,
consumer and workers co-operative member http://www.ttllp.co.uk/ -
Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/

(Continue reading)

headers

Josip Rodin | 10 Oct 2007 14:17

Re: soc-ctte default position, was: electing multiple people

On Wed, Oct 10, 2007 at 11:02:09AM +0100, MJ Ray wrote:
> Russ Allbery <rra <at> debian.org> wrote:
> > It depends.  Being able to reach consensus may make it easier for the
> > soc-ctte to look at the situation and go "there's strong disagreement
> > here and even if we're mostly on one side, we realize that and we should
> > decide that we can't really intervene." [...]
> 
> This raises a question.
> 
> I assumed that soc-ctte would intervene somehow on any issue referred
> to them, even if it is just to say "let the existing processes stand".
> If it ends up at soc-ctte, there is a problem to resolve.
> 
> However, the above suggests that if soc-ctte is weakly divided (mostly
> on one side), it shouldn't intervene.
> 
> What should be soc-ctte's default position?  To do nothing, or to
> announce their (maybe-weak) support for the existing situation?
> 
> As you may know, I believe that ignoring problems is a bug, so I'd
> expect soc-ctte to make decisions, even if mostly null, rather than do
> nothing.  If it will mostly do nothing, is it worth creating it?

This is getting needlessly intricate - most people won't care for the
difference between doing nothing and formally deciding to do nothing :)

But, we've strayed from the topic of debian-vote, let's move this back to
debian-project...

--

--

(Continue reading)

headers

MJ Ray | 19 Oct 2007 14:48

Re: soc-ctte default position, was: electing multiple people

Josip Rodin <joy <at> entuzijast.net> wrote:
> On Wed, Oct 10, 2007 at 11:02:09AM +0100, MJ Ray wrote: [...]
> > I assumed that soc-ctte would intervene somehow on any issue referred
> > to them, even if it is just to say "let the existing processes stand".
> > If it ends up at soc-ctte, there is a problem to resolve.
[...]
> > What should be soc-ctte's default position?  To do nothing, or to
> > announce their (maybe-weak) support for the existing situation?
[...]
> This is getting needlessly intricate - most people won't care for the
> difference between doing nothing and formally deciding to do nothing :)

Please don't be daft.  That's not my suggestion: it's the difference
between doing nothing and doing something to support the existing
situation.  Also, I think soc-ctte should do, not formally decide.

There are lots of project practices, both formal and informal, and
written and customary, which will pre-date soc-ctte and I expect some
of them will be challenged by referring to soc-ctte.  Some of those
will split soc-ctte, if it represents the project at all well, so I
think we need to try to be clear about what we want from soc-ctte in
those cases.

Personally, I expect soc-ctte to do something to support the existing
situation when they think it's fair overall.  We've seen situations
where doing nothing has allowed complaints to fester.

> But, we've strayed from the topic of debian-vote, let's move this back to
> debian-project...

(Continue reading)

headers

Josip Rodin | 19 Oct 2007 15:35

Re: soc-ctte default position, was: electing multiple people

On Fri, Oct 19, 2007 at 01:48:44PM +0100, MJ Ray wrote:
> > > I assumed that soc-ctte would intervene somehow on any issue referred
> > > to them, even if it is just to say "let the existing processes stand".
> > > If it ends up at soc-ctte, there is a problem to resolve.
> [...]
> > > What should be soc-ctte's default position?  To do nothing, or to
> > > announce their (maybe-weak) support for the existing situation?
> [...]
> > This is getting needlessly intricate - most people won't care for the
> > difference between doing nothing and formally deciding to do nothing :)
> 
> Please don't be daft.  That's not my suggestion: it's the difference
> between doing nothing and doing something to support the existing
> situation.  Also, I think soc-ctte should do, not formally decide.
> 
> There are lots of project practices, both formal and informal, and
> written and customary, which will pre-date soc-ctte and I expect some
> of them will be challenged by referring to soc-ctte.  Some of those
> will split soc-ctte, if it represents the project at all well, so I
> think we need to try to be clear about what we want from soc-ctte in
> those cases.
> 
> Personally, I expect soc-ctte to do something to support the existing
> situation when they think it's fair overall.  We've seen situations
> where doing nothing has allowed complaints to fester.

Well, that's like saying they should act on common sense. Why would we ever
want to say that it should support an existing situation even if it is
not fair?

(Continue reading)

headers

MJ Ray | 19 Oct 2007 21:33

Re: soc-ctte default position, was: electing multiple people

Josip Rodin <joy <at> entuzijast.net> wrote:
> On Fri, Oct 19, 2007 at 01:48:44PM +0100, MJ Ray wrote: [...]
> > Personally, I expect soc-ctte to do something to support the existing
> > situation when they think it's fair overall.  We've seen situations
> > where doing nothing has allowed complaints to fester.
>
> Well, that's like saying they should act on common sense. Why would we ever
> want to say that it should support an existing situation even if it is
> not fair?

Am I being trolled?  I mean that soc-ctte should either:
1. do something to support an existing fair situation;
2. seek replacement of an unfair situation.

That is, doing nothing about a problem, becoming another /dev/null
alias, should not be a regular option.

> Please see Message-ID: <20071009221042.GA3055 <at> keid.carnet.hr> on -project
> for my last take on this general stance.

What bit?  "placing emphasis on existing practice rather than novel
ideas"?  Seems to me like a soc-ctte that is expected to rubber stamp
even unfair practices, but maybe the mail didn't include enough context.

> > I prefer to keep this topic on a development list, rather than hidden
> > on a miscellaneous one.  It's developers who may vote on it.
>
> Uhh, debian-project is not a miscellaneous list for hiding things, at least
> it's not any less miscellaneous than debian-vote.

(Continue reading)

headers

Josip Rodin | 19 Oct 2007 23:35

Re: soc-ctte default position, was: electing multiple people

On Fri, Oct 19, 2007 at 08:33:03PM +0100, MJ Ray wrote:
> > > Personally, I expect soc-ctte to do something to support the existing
> > > situation when they think it's fair overall.  We've seen situations
> > > where doing nothing has allowed complaints to fester.
> >
> > Well, that's like saying they should act on common sense. Why would we ever
> > want to say that it should support an existing situation even if it is
> > not fair?
> 
> Am I being trolled?

You're not.

> I mean that soc-ctte should either:
> 1. do something to support an existing fair situation;
> 2. seek replacement of an unfair situation.
> 
> That is, doing nothing about a problem, becoming another /dev/null
> alias, should not be a regular option.

Well, yes.

> > Please see Message-ID: <20071009221042.GA3055 <at> keid.carnet.hr> on -project
> > for my last take on this general stance.
> 
> What bit?  "placing emphasis on existing practice rather than novel
> ideas"?  Seems to me like a soc-ctte that is expected to rubber stamp
> even unfair practices, but maybe the mail didn't include enough context.

No, I meant the general stance as in:

(Continue reading)

headers

Bas Wijnen | 10 Oct 2007 11:19

Re: electing multiple people

On Tue, Oct 09, 2007 at 02:50:42PM -0700, Russ Allbery wrote:
> "Bernhard R. Link" <brlink <at> debian.org> writes:
> 
> > But if there is such an situation and there is heated disagreement
> > outside of this body, how would having only one side of that in the body
> > help? That would only make a body supposed to defuse such a situation to
> > be weapon for one side and thus could even rise such a problem to much
> > higher spheres.
> 
> It depends.  Being able to reach consensus may make it easier for the
> soc-ctte to look at the situation and go "there's strong disagreement here
> and even if we're mostly on one side, we realize that and we should decide
> that we can't really intervene."  I don't know if that's more likely or
> less likely with a group of people who work well together but may be
> mostly or entirely on one side of an issue, or with a group of people who
> are representative but don't work well together.

Both points are very valid: we need a representative committee (if it
should do mediation, at least), and we also need people who can work
well together.  Luckily, these are not exclusive properties. 

> Try this reduction of my worry (which may be very unlikely):  Suppose we
> have two basic factions in Debian, one that thinks the soc-ctte is a good
> idea, and one that thinks it's a horrible idea.  If you have proportional
> representation of both sides, that means you should elect a few people to
> the soc-ctte who think it's a horrible idea and should never do anything.
> If those people act to represent their constituency, they should try to
> block any action by the soc-ctte on any topic.

I do not think this must follow from the situation.  First of all,

(Continue reading)

headers

Manoj Srivastava | 8 Oct 2007 18:57

Re: electing multiple people

On Mon, 8 Oct 2007 17:33:54 +0200, Josip Rodin <joy <at> entuzijast.net> said: 

> Hi, During the discussion on the proposed social committee, I proposed
> that we elect (all) the members of that committee. The Debian
> Constitution currently doesn't provide for a way to do so - it only
> describes how a single winner is decided.

> So, I proposed the following addition to the section A.6. Vote
> Counting (part of appendix A Standard Resolution Procedure):

> + If the election requires multiple winners, the list of winners is
> + created by sorting the list of options by ascending strength.
> + If there are multiple winners with the same ranking which exceed
> + the desired length of the list, the length of the list is extended
> + to include the entire last set of multiple winners.

> Is this technically sound? I don't know voting method syntax.

        I do not think this is. I would like the solution to at least
 have the property of proportionality, if nothing else, which the above
 does not have.

        I am working on a variant of the method we use (which is also
 defined very clearly in [0].  I want to prevent the kinds of problems
 of free riding mentioned in [1], for example, in any mechanism we
 select.

        With that in mind, I would like to expand on the ideas
 presented in [1] above, and expanded upon in [2], rather than try
 ad-hoc voting methods. If there are other methods to use that have the

(Continue reading)

headers

Wouter Verhelst | 9 Oct 2007 00:56

Re: electing multiple people

On Mon, Oct 08, 2007 at 11:57:18AM -0500, Manoj Srivastava wrote:
[...]
>  ad-hoc voting methods. If there are other methods to use that have the
>  same theoretical underpinnings as [2], I would be happy to consider
>  them.

What about the Kemeny-Young method?

http://en.wikipedia.org/wiki/Kemeny-Young_method

--

-- 
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

headers

Anthony Towns | 8 Oct 2007 18:29

Re: electing multiple people

On Mon, Oct 08, 2007 at 05:33:54PM +0200, Josip Rodin wrote:
> So, I proposed the following addition to the section A.6. Vote Counting
> (part of appendix A Standard Resolution Procedure):
> +        If the election requires multiple winners, the list of winners is
> +        created by sorting the list of options by ascending strength. ...
> Is this technically sound? I don't know voting method syntax.

Even if you get the wording right for that, it might not be a *sound*
method if you're trying to get a representative selection of winners,
rather than the 1st best, 2nd best, 3rd best, etc, for whatever people
happen to think "best" means.

To select "events coordinators", for example, we might want to have
five people each on a different continent, even though three of the
best events coordinators happen to be in Europe, on the basis that one
European, one North American and one South/Latin American would be more
useful than three Europeans.

Basically, the question is: if you've got, say, five positions, then do
you want 20% of people to be able to get together and guarantee one of
the positions goes to someone they like, or do you want 51% of people
to be able to get together and guarantee that none of the positions go
to someone they don't like? 

The latter's probably more likely to result in a good functioning
consensus amongst the elected members, the former's probably more likely
to result in (significant) minority views getting representation. It
really depends on what you're trying to achieve as to which is better,
afaics.

(Continue reading)

headers

Josip Rodin | 9 Oct 2007 15:55

Re: electing multiple people

On Tue, Oct 09, 2007 at 02:29:23AM +1000, Anthony Towns wrote:
> To select "events coordinators", for example, we might want to have
> five people each on a different continent, even though three of the
> best events coordinators happen to be in Europe, on the basis that one
> European, one North American and one South/Latin American would be more
> useful than three Europeans.

BTW, that's the question of whether a single election with multiple winners
is the right election to use. In that case, it's better to simply have five
elections, one for each continent, but allowing the same candidate to run
for more than one seat. :)

--

-- 
     2. That which causes joy or happiness.

headers

Manoj Srivastava | 9 Oct 2007 16:26

Re: electing multiple people

On Tue, 9 Oct 2007 15:55:11 +0200, Josip Rodin <joy <at> entuzijast.net> said: 

> On Tue, Oct 09, 2007 at 02:29:23AM +1000, Anthony Towns wrote:
>> To select "events coordinators", for example, we might want to have
>> five people each on a different continent, even though three of the
>> best events coordinators happen to be in Europe, on the basis that
>> one European, one North American and one South/Latin American would
>> be more useful than three Europeans.

> BTW, that's the question of whether a single election with multiple
> winners is the right election to use. In that case, it's better to
> simply have five elections, one for each continent, but allowing the
> same candidate to run for more than one seat. :)

        If the same candidate wins all elections, or if people from one
 city win all elections, would that be an acceptable outcome?

        manoj
--

-- 
The man who raises a fist has run out of ideas. H.G. Wells, "Time After
Time"
Manoj Srivastava <srivasta <at> debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

headers

Josip Rodin | 9 Oct 2007 17:19

Re: electing multiple people

On Tue, Oct 09, 2007 at 09:26:53AM -0500, Manoj Srivastava wrote:
> >> To select "events coordinators", for example, we might want to have
> >> five people each on a different continent, even though three of the
> >> best events coordinators happen to be in Europe, on the basis that
> >> one European, one North American and one South/Latin American would
> >> be more useful than three Europeans.
> 
> > BTW, that's the question of whether a single election with multiple
> > winners is the right election to use. In that case, it's better to
> > simply have five elections, one for each continent, but allowing the
> > same candidate to run for more than one seat. :)
> 
>         If the same candidate wins all elections, or if people from one
>  city win all elections, would that be an acceptable outcome?

I wasn't trying to provide an end-all solution to the said problem :)

--

-- 
     2. That which causes joy or happiness.

headers

Antti-Juhani Kaijanaho | 8 Oct 2007 18:26

Re: electing multiple people

On Mon, Oct 08, 2007 at 05:33:54PM +0200, Josip Rodin wrote:
> So, I proposed the following addition to the section A.6. Vote Counting
> (part of appendix A Standard Resolution Procedure):

The method you suggest suffers from not delivering proportional results.
See discussion in
  http://lists.debian.org/debian-project/2007/06/msg00318.html
and
  http://lists.debian.org/debian-project/2007/06/msg00261.html

Let's not invent our own bad voting systems.

--

-- 
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/

headers

Josip Rodin | 8 Oct 2007 18:35

Re: electing multiple people

On Mon, Oct 08, 2007 at 07:26:42PM +0300, Antti-Juhani Kaijanaho wrote:
> > So, I proposed the following addition to the section A.6. Vote Counting
> > (part of appendix A Standard Resolution Procedure):
> 
> The method you suggest suffers from not delivering proportional results.
> See discussion in
>   http://lists.debian.org/debian-project/2007/06/msg00318.html
> and
>   http://lists.debian.org/debian-project/2007/06/msg00261.html
> 
> Let's not invent our own bad voting systems.

Er, but I didn't suggest that. Or at least I don't think I did - or is the
picture provided at the vote.d.o generated by applying the iterative method?

--

-- 
     2. That which causes joy or happiness.

headers

Manoj Srivastava | 8 Oct 2007 19:02

Re: electing multiple people

On Mon, 8 Oct 2007 18:35:32 +0200, Josip Rodin <joy <at> entuzijast.net> said: 

> On Mon, Oct 08, 2007 at 07:26:42PM +0300, Antti-Juhani Kaijanaho wrote:
>> > So, I proposed the following addition to the section A.6. Vote
>> > Counting (part of appendix A Standard Resolution Procedure):
>> 
>> The method you suggest suffers from not delivering proportional
>> results.  See discussion in
>> http://lists.debian.org/debian-project/2007/06/msg00318.html> and
>> http://lists.debian.org/debian-project/2007/06/msg00261.html> 
>> Let's not invent our own bad voting systems.

> Er, but I didn't suggest that. Or at least I don't think I did - or is
> the picture provided at the vote.d.o generated by applying the
> iterative method?

        The pictures are my very own, minimal computation, not-to-be-
 taken-seriously-but-present-some-pretty-pictures-that-in-most-cases-
 do-not-depart-too-far-from-the-truth.

        In no way are these pretty graphics to be taken as a basis of
 actually making decisions; they present instead a rough graphical view
 of the pair wise defeats in a method only suited to finding a single
 winner.

        I am working on getting a working code for devotee for multiple
 winners; which will degenerate into the current method for the special
 case where the number of winners = 1; please don't hurry me, I tend to
 commit typos  and other errors when so hurried.

(Continue reading)

headers

Josip Rodin | 8 Oct 2007 19:18

Re: electing multiple people

On Mon, Oct 08, 2007 at 12:02:26PM -0500, Manoj Srivastava wrote:
> > Er, but I didn't suggest that. Or at least I don't think I did - or is
> > the picture provided at the vote.d.o generated by applying the
> > iterative method?
> 
>         The pictures are my very own, minimal computation, not-to-be-
>  taken-seriously-but-present-some-pretty-pictures-that-in-most-cases-
>  do-not-depart-too-far-from-the-truth.
> 
>         In no way are these pretty graphics to be taken as a basis of
>  actually making decisions; they present instead a rough graphical view
>  of the pair wise defeats in a method only suited to finding a single
>  winner.

You should then reorganize the pages to put the actual data used to make
the outcome first, and the purely informative picture later. Right now
the picture is shown as the first thing under the "Outcome" heading,
which is not right.

--

-- 
     2. That which causes joy or happiness.

headers

Manoj Srivastava | 8 Oct 2007 21:54

Re: electing multiple people

On Mon, 8 Oct 2007 19:18:50 +0200, Josip Rodin <joy <at> entuzijast.net> said: 

> On Mon, Oct 08, 2007 at 12:02:26PM -0500, Manoj Srivastava wrote:
>> > Er, but I didn't suggest that. Or at least I don't think I did - or
>> > is the picture provided at the vote.d.o generated by applying the
>> > iterative method?
>> 
>> The pictures are my very own, minimal computation, not-to-be-
>> taken-seriously-but-present-some-pretty-pictures-that-in-most-cases-
>> do-not-depart-too-far-from-the-truth.
>> 
>> In no way are these pretty graphics to be taken as a basis of
>> actually making decisions; they present instead a rough graphical
>> view of the pair wise defeats in a method only suited to finding a
>> single winner.

> You should then reorganize the pages to put the actual data used to
> make the outcome first, and the purely informative picture
> later. Right now the picture is shown as the first thing under the
> "Outcome" heading, which is not right.

        I think you misunderstand.  The graph is a perfectly clear
 representation of the pairwise defeats as it  corresponds to the single
 winner outcome; and it shows the relative strengths of the defeats.
 There is nothing wrong with it -- as long as you do not try to project
 and use that data for multi-winner predictions. All the candidates are
 rpesented, and the relative pairwise defeats are presented -- quite
 correctly.  Assuming that the pairwise defeats have something to do
 with global ordering is a leap, however, and not one which is promoted
 by the web page.

(Continue reading)

headers

Josip Rodin | 8 Oct 2007 23:41

Re: electing multiple people

On Mon, Oct 08, 2007 at 02:54:18PM -0500, Manoj Srivastava wrote:
>         I think you misunderstand.  The graph is a perfectly clear
>  representation of the pairwise defeats as it  corresponds to the single
>  winner outcome; and it shows the relative strengths of the defeats.
>  There is nothing wrong with it -- as long as you do not try to project
>  and use that data for multi-winner predictions. All the candidates are
>  rpesented, and the relative pairwise defeats are presented -- quite
>  correctly.  Assuming that the pairwise defeats have something to do
>  with global ordering is a leap, however, and not one which is promoted
>  by the web page.

Uh, yes, it is. The picture clearly orders candidates from top to bottom,
so it's a fair assumption. But never mind.

--

-- 
     2. That which causes joy or happiness.

headers

Manoj Srivastava | 9 Oct 2007 00:05

Re: electing multiple people

On Mon, 8 Oct 2007 23:41:41 +0200, Josip Rodin <joy <at> entuzijast.net> said: 

> On Mon, Oct 08, 2007 at 02:54:18PM -0500, Manoj Srivastava wrote:
>> I think you misunderstand.  The graph is a perfectly clear
>> representation of the pairwise defeats as it corresponds to the
>> single winner outcome; and it shows the relative strengths of the
>> defeats.  There is nothing wrong with it -- as long as you do not try
>> to project and use that data for multi-winner predictions. All the
>> candidates are rpesented, and the relative pairwise defeats are
>> presented -- quite correctly.  Assuming that the pairwise defeats
>> have something to do with global ordering is a leap, however, and not
>> one which is promoted by the web page.

> Uh, yes, it is. The picture clearly orders candidates from top to
> bottom, so it's a fair assumption. But never mind.

        You do have a point.  Based on the pairwise defeats, one can get
 a sense of how candidates might have ranked --- and the ranking so
 uncovered is likely to be correct in absence of circular defeats (in
 other words, if the second place race did not have a clear [condorcet]
 winner).

        The picture gives, in other words, a ranking that conveys
 information, is often not far from the truth, and thus, useful
 interpretation of the beat matrix, and yet is still unsuitable for more
 formal use cases -- like deciding how to order N winners, where N > 1.

        Anyway, I'll try and place the winner first on the next set of
 updates I do.

(Continue reading)

headers

Antti-Juhani Kaijanaho | 8 Oct 2007 18:43

Re: electing multiple people

On Mon, Oct 08, 2007 at 06:35:32PM +0200, Josip Rodin wrote:
> Er, but I didn't suggest that. Or at least I don't think I did - or is the
> picture provided at the vote.d.o generated by applying the iterative method?

It's similar enough.  I'm not sure that it produces the same answer as
iteration (it might), but it does suffer from the same problem of
nonproportionality.

--

-- 
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/

headers

Lucas Nussbaum | 8 Oct 2007 18:08

Re: electing multiple people

On 08/10/07 at 17:33 +0200, Josip Rodin wrote:
> Hi,
> 
> During the discussion on the proposed social committee, I proposed that we
> elect (all) the members of that committee. The Debian Constitution currently
> doesn't provide for a way to do so - it only describes how a single winner
> is decided.
> 
> So, I proposed the following addition to the section A.6. Vote Counting
> (part of appendix A Standard Resolution Procedure):
> 
> +        If the election requires multiple winners, the list of winners is
> +        created by sorting the list of options by ascending strength.
> +        If there are multiple winners with the same ranking which exceed
> +        the desired length of the list, the length of the list is extended
> +        to include the entire last set of multiple winners.
> 
> Is this technically sound? I don't know voting method syntax.

couldn't we get cycles using that? Alternatively, we could iteratively
elect:
- winner1: the winner with all candidates
- winner2: the winner with all candidates minus winner1
- winner3: the winner with all candidates minus [winner1, winner2]
- etc
using the same tally sheet

Or, we could elect a list directly (ie each option is a list of people
willing to work together as SC), which would allow to elect a SC which
is actually representative for Debian. It's probably better than the

(Continue reading)

headers

Josip Rodin | 8 Oct 2007 18:24

Re: electing multiple people

On Mon, Oct 08, 2007 at 06:08:41PM +0200, Lucas Nussbaum wrote:
> couldn't we get cycles using that? Alternatively, we could iteratively
> elect:
> - winner1: the winner with all candidates
> - winner2: the winner with all candidates minus winner1
> - winner3: the winner with all candidates minus [winner1, winner2]
> - etc
> using the same tally sheet

You can't do that and keep all the 'goodness' of our voting system, because
doing that loses the interdependencies of votes. I don't know how to explain
it properly :), please see:
http://lists.debian.org/debian-project/2007/06/msg00318.html

> Or, we could elect a list directly (ie each option is a list of people
> willing to work together as SC), which would allow to elect a SC which
> is actually representative for Debian.

This means parties, and I don't see any proof that this would help with
being representative?

> It's probably better than the first solution, as the first solution isn't
> clone-proof: we could have elected n Sams!! ;)

There should be some sentence in the constitution that can be interpreted as
a rule against cloning... :)

--

-- 
     2. That which causes joy or happiness.

(Continue reading)

headers

Anthony Towns | 9 Oct 2007 06:47

Re: electing multiple people

> On Mon, Oct 08, 2007 at 06:08:41PM +0200, Lucas Nussbaum wrote:
> > It's probably better than the first solution, as the first solution isn't
> > clone-proof: we could have elected n Sams!! ;)

So the first question is why would that be a bad thing?

(Of course, we don't have n Sams, we only have one, so there'll
be alternative points of view no matter what; but let's go with the
hypothetical)

Having one person do all the work can be a problem if they're not
available or get exhausted, but if those are the only problems we're
trying to solve by having a committee instead of one person, having
"n Sams" does actually solve it, and doesn't come at a cost of creating
friction and indecisiveness within the group, which is the downfall of
lots of committees.

On Mon, Oct 08, 2007 at 04:48:20PM -0700, Russ Allbery wrote:
> I've had enough bad experiences with committees and groups in the past
> that I've developed a deep dislike of voting or nomination systems that
> don't take into account the ability of the chosen slate to work with each
> other.  I'd rather end up with a weaker candidate who can cooperate with
> the leading candidate than the two strongest candidates who will then be
> at loggerheads.

On Mon, Oct 08, 2007 at 06:24:38PM +0200, Josip Rodin wrote:
> On Mon, Oct 08, 2007 at 06:08:41PM +0200, Lucas Nussbaum wrote:
> > Or, we could elect a list directly (ie each option is a list of people
> > willing to work together as SC), which would allow to elect a SC which
> > is actually representative for Debian.

(Continue reading)

headers

Josip Rodin | 9 Oct 2007 09:27

Re: electing multiple people

On Tue, Oct 09, 2007 at 02:47:20PM +1000, Anthony Towns wrote:
> > > Or, we could elect a list directly (ie each option is a list of people
> > > willing to work together as SC), which would allow to elect a SC which
> > > is actually representative for Debian.
> > This means parties, and I don't see any proof that this would help with
> > being representative?
> 
> It doesn't necessarily mean parties in the normal sense. You could, eg,
> have two rounds of nominations; first letting people nominate themselves
> to be on the committee, then letting the nominees pick their "dream team",
> so if your nominees for a three person committee are Alice, Bob, Carol,
> Dave, Eve, and Fred, they might pick their teams as:
> 
> 	Alice, Carol, Eve
> 	Bob, Carol, Fred
> 	Carol, Bob, Alice
> 	Dave, Bob, Carol
> 	Eve, Alice, Bob
> 	Fred, Carol, Dave
> 
> ie, you can get a genuine mix, rather than just a party-line split
> (Alice, Carol, Eve versus Bob, Dave and Fred, eg).

Another problem is how to determine the number and choice of permutations
to use if there are e.g. 10 candidates who suggest 40 options? A huge ballot
is quite unwieldy, and its sorting sounds like an easily contested issue :)

--

-- 
     2. That which causes joy or happiness.

(Continue reading)

headers

Andreas Tille | 9 Oct 2007 08:19

Re: electing multiple people

Hi,

just a very ruogh idea (I never dived into the theory of voting)
which IMHO sounds apropriate for our case.  At first we need
a set of volunteer candidates.  Let's assume we have ten
candidates for a team of seven people: A, B, ... J.
Now let people do a negative selection and vota "against"
candidates that they do not want into the set of people.  Assume
candidate C, I and H got most negative votes the other ones
are elected.  This could be a little bit harsh for C, I and H
personally, but IMHO it is an apropriate way to easily select
a team of equal people.

Kind regards

          Andreas.
--

-- 
http://fam-tille.de