Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Cyril Brulebois]

Andreas Tille <[EMAIL PROTECTED]> (09/10/2007):
> I also did not forgot, but wanted to revisit the video of the BOF
> which to my knowledge was not yet published (perhaps we should ask the
> video team for the location of the recording stream?)

Are you referring to [1]? If so [2] looks like it to me (and also with
s/low/high/ in the URL).

 1. https://penta.debconf.org/~joerg/events/93.en.html
 2. 
http://meetings-archive.debian.net/pub/debian-meetings/2007/debconf7/low/349_Solving_social_problems_via_soc-ctte.ogg

Cheers,

-- 
Cyril Brulebois


pgpkmGmzQweJH.pgp
Description: PGP signature

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Andreas Tille]

On Mon, 8 Oct 2007, Josip Rodin wrote:


Well, that was so in June, but apparently everybody including the leader
forgot about this in the last three months.


Wrong.  You did not forgot.  I also did not forgot, but wanted to revisit
the video of the BOF which to my knowledge was not yet published (perhaps
we should ask the video team for the location of the recording stream?)
to make up my mind a little bit more.


So, it looks now that that was
one of those things that "seemed like a good idea at the time" but in
practice it doesn't work.


Well, I think as long as there is no practice at all we could not not
draw this conclusion.  I bet that this topic would immediately would be
back on the table if we would have another problem showing up here - on
the other hand I'm very happy that we had "such a quiet time" since
Edinburgh.  Very productive ... ;-)

Thanks for bringing this up again

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Josip Rodin]

On Tue, Jun 26, 2007 at 12:43:56AM +0200, Josip Rodin wrote:
>   * We seemed to agree that a leader's delegation would be a useful tool to
> bootstrap the soc-ctte and modify it later

Well, that was so in June, but apparently everybody including the leader
forgot about this in the last three months. So, it looks now that that was
one of those things that "seemed like a good idea at the time" but in
practice it doesn't work.

I'm going to post on -vote asking for input regarding the details of the
proposed multiple person election procedure, because that was only remaining
part of my old proposal that was technically unclear. (Perhaps it's better
in general that that part of constitution text modification is done
separately, because it's generic.)

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[MJ Ray]

Kalle Kivimaa <[EMAIL PROTECTED]> wrote:
> MJ Ray <[EMAIL PROTECTED]> writes:
> > I think we need to do something else.  For example, list-admins.
>
> Have you discussed this with the listmasters (ie. how difficult it
> would be to grant list-admins the power to enforce bans on lists)? If
> the listmasters don't see any difficulties [...]

I've tried in the past without success.  From this thread, there seem
to be objection to lists appointing admin teams, for unspecified
reasons (or bogus ones - list-admins would not grow uncontrolled).

The reasons to not use soc-ctte as the first port of call for list
management include that soc-ctte will probably not be in good standing
on all lists and that the day-to-day work would be a waste of its time
and process, so I expect soc-ctte could continue the effective power
vacuum in our list management.

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[Andreas Tille]

On Mon, 2 Jul 2007, Manoj Srivastava wrote:


   This might well be the case.  But I can see where an informed
electorate can make a different decision for party selection if they
keep cultural diversity in mind.  So the practical solution might be as
simple as adding a note to the charter of the soc ctte admonisng them
to be aware of these issues; and for the entity selecting members to
also be aware as well.


Would you be able and willing to provide such a note you have in mind?


   Me? I belong to the modern diaspora of migrants stuck between
diverse cultures, belonging perfectly to neither.  I think modern
migrants like me are often better at recognizing two vastly different,
and often opposed, but equally valid takes on issues that our social
and cultural sets take.


This sounds very reasonable.


   And no, you do not want me on your soc ctte.


Well, it's not me who wants anybody.  At first we need volunteers.
Than we will run a procedure to pick the final set from. 
It was just me who had a lightening (well - at least I thought it

was) chat with you. ;-)

Kind regards

 Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[Manoj Srivastava]

On Sun, 1 Jul 2007 22:54:53 +0200 (CEST), Andreas Tille <[EMAIL PROTECTED]> 
said: 

> On Sun, 1 Jul 2007, Manoj Srivastava wrote:
>> I am not talking about _not_ having a soc-ctte. I am talking about
>> whether or not the selection criteria for ctte members needs to be
>> looked at with due consideration to the cultural diversity.

> I'm afraid that we will have not enough volunteers from different
> cultures.

This might well be the case.  But I can see where an informed
 electorate can make a different decision for party selection if they
 keep cultural diversity in mind.  So the practical solution might be as
 simple as adding a note to the charter of the soc ctte admonisng them
 to be aware of these issues; and for the entity selecting members to
 also be aware as well.

> Moreover it is hard to separate between different cultures.  There is
> no sharp borderline between cultures and there are people who belong
> to more than one culture.

While boundaries might be blurred, let me assure you that the
 cultural background in Tennessee is distinctly different from that in the
 Scottish highlands, and palpably so; and both are a world apart from
 the culture of nothern India.


> So this is a quite weak criterium to choose members for a soc-ctte
> from.

I dunno. I think there is a wide diversity in cultural norms and
 expectations (the news headlines scream with the effects); and just
 because there are crossovers and individuals and families who straddle
 the divide is no reason to pretend that the differences do not exist,
 or can not be catered to.

> I think I understood perfectly your concerns - but I see no practical
> solution.  I just hope that a soc-ctte that is elected according to
> the rules we mentioned will be able to understand social aspects that
> are brought up by a person who has the kind of trouble you have in
> mind.

Well, the re are practical solutions, and there are practical
 solutions.  Let not the perfect be the enemy of an adequate
 solution. While we might never be able to get a perfectly unbiased,
 culture neutral and yet culture sensitive soc ctte, as you rightly
 fear; we can still add language to the charter of the soc ctte  to
 remind the members of this aspect of their duty long after this
 conversation has been forgotten.


>> Based on recent conversation in the list, I would suggest that the
>> proportionality criteria for party list selection be given emhpasis
>> for electing the members, so the minority cultures do not fail to
>> have representation on the ctte, drowned our by the dominant cultural
>> subgroups.

> Just for the sake of interest: What would you say to which cultural
> group you would belong?

Me? I belong to the modern diaspora of migrants stuck between
 diverse cultures, belonging perfectly to neither.  I think modern
 migrants like me are often better at recognizing two vastly different,
 and often opposed, but equally valid takes on issues that our social
 and cultural sets take.

And no, you do not want me on your soc ctte.

manoj
-- 
He whose path devas, spirits and men cannot know, whose inflowing
thoughts are ended, a saint - that is what I call a brahmin. 420
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[Raphael Hertzog]

Hi,

On Mon, 02 Jul 2007, MJ Ray wrote:
> No.  On that, I sympathise with Josip Rodin's views in
> http://lists.debian.org/debian-project/2007/06/msg00244.html
> that it's not a role listmasters have been wanting or expecting.
> I think we need to do something else.  For example, list-admins.
> 
> I do have grave concerns about installing an all-powerful soc-ctte
> that carries big sticks, while leaving vacuums at these lower levels.

I don't see why the soc-ctte wouldn't play at those lower levels. It's
been mentionned clearly that the committee members are expected to mail
privately people who are on a bad track. They won't ban people directly.

On the other hand, the soc-ctte members are probably following the major
mailing lists mainly, and I have no problems with the soc-ctte delegating 
"list-admins" for other lists... they would warn in place of the soc-ctte
and refer to the soc-ctte if they believe that some action needs to be
taken.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[Frans Pop]

On Monday 02 July 2007 10:03, MJ Ray wrote:
> No.  On that, I sympathise with Josip Rodin's views in
> http://lists.debian.org/debian-project/2007/06/msg00244.html
> that it's not a role listmasters have been wanting or expecting.
> I think we need to do something else.  For example, list-admins.
>
> I do have grave concerns about installing an all-powerful soc-ctte
> that carries big sticks, while leaving vacuums at these lower levels.

I don't think it has to be that way. IMO the solution is to make sure that 
the soc-ctte has both big _and_ little sticks.

Why not let the soc-ctte have the ability to request listmasters to set 
and revoke certain measures against certain people?
That would mean that we do not have an uncontrolled growth of smallish 
teams all dealing with social issues for individual mailing lists, but 
rather have the judgement about issues in one place. That would also have 
the advantage that one body will follow the development of issues from an 
early stage, instead of getting dragged in late.

The main issues I, as former listmaster, had with having the listmasters 
do sanctions, are:
- the listmasters have never really been given that authority be the
  project and using it would probably have resulted in flamewars about
  such sanctions instead of people responding to the warning such a
  sanction is intended to send
- it takes a significant amount of time to investigate the background of
  such requests and that is just not why I originally signed up as a
  listmaster; current listmaster team is a 'technical infrastructure' team
  rather than a community management team [1]
- it is never optimal have both the judging of issues and the implementing
  of measures with the same people

I am fairly confident that listmasters would be willing to set filters and 
such if there was a separate body authorized by the project to mediate 
and intervene in social issues.

Cheers,
FJP

[1] Which IMO is in line with the general purpose of the Debian mailing 
lists, whose primary function is to enable collaboration rather than 
creating a community.


pgpEzJY8SfsBd.pgp
Description: PGP signature

Re: soc-ctte discussion at DebConf7

[Kalle Kivimaa]

MJ Ray <[EMAIL PROTECTED]> writes:
> I think we need to do something else.  For example, list-admins.

Have you discussed this with the listmasters (ie. how difficult it
would be to grant list-admins the power to enforce bans on lists)? If
the listmasters don't see any difficulties, I would like to see this
as an option in the upcoming ballot, with or without the soc-ctte (I
don't see list-admins and soc-ctte as mutually exclusive).

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[MJ Ray]

Andreas Tille <[EMAIL PROTECTED]> wrote:
> On Sun, 1 Jul 2007, MJ Ray wrote: [...]
> > It's not soc-ctte or nothing!  We could take smaller steps first!
>
> Sounds like out of context quoting.

Well, my complaint isn't about the whole of the message, but that - as
you've later written - your arguments have been a bit binary.

> My post was about regarding
> cultural aspects of soc-ctte.  I wonder if you think that list master
> intervention might serve cultural aspects better than a soc-ctte.

No.  On that, I sympathise with Josip Rodin's views in
http://lists.debian.org/debian-project/2007/06/msg00244.html
that it's not a role listmasters have been wanting or expecting.
I think we need to do something else.  For example, list-admins.

I do have grave concerns about installing an all-powerful soc-ctte
that carries big sticks, while leaving vacuums at these lower levels.

Hope that explains,
-- 
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Experienced webmaster-developers for hire http://www.ttllp.co.uk/
Also: statistician, sysadmin, online shop builder, workers co-op.
Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[Andreas Tille]

On Sun, 1 Jul 2007, Manoj Srivastava wrote:


So we have the choice to do either nothing against social problems in
Debian or just give a soc-ctte a chance to try - your comments about
the cultural diversion might be a helpful guideline here - but in my
opinion no argument against a soc-ctte.


   Why does everyone  see any discussion at all in the mailing list
a binary, either-or, confrontational debate?


I admit my posting sounded a little bit binary - but it was not intended
to be that way.  Even if I would consider myself as one of the first ones
who brought up this idea I'm not really convinced that it is an appropriate
mean to solve our problems.  But for the moment I do not see a suggestion
that sounds more promissing.


   I am not talking about _not_ having a soc-ctte. I am talking
about whether or not the selection criteria for ctte members needs to
be looked at with due consideration to the cultural diversity.


I'm afraid that we will have not enough volunteers from different
cultures.  Moreover it is hard to separate between different cultures.
There is no sharp borderline between cultures and there are people who
belong to more than one culture.  So this is a quite weak criterium
to choose members for a soc-ctte from.  I think I understood perfectly
your concerns - but I see no practical solution.  I just hope that
a soc-ctte that is elected according to the rules we mentioned will
be able to understand social aspects that are brought up by a person
who has the kind of trouble you have in mind.


   Based on recent conversation in the list, I would suggest that
the proportionality criteria for party list selection be given emhpasis
for electing the members, so the minority cultures do not fail to have
representation on the ctte, drowned our by the dominant cultural
subgroups.


Just for the sake of interest: What would you say to which cultural
group you would belong?

Kind regards

   Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[Andreas Tille]

On Sun, 1 Jul 2007, MJ Ray wrote:


Andreas Tille <[EMAIL PROTECTED]> wrote: [...]

So we have the choice to do either nothing against social problems in
Debian or just give a soc-ctte a chance to try [...]


That's a false dilemma.  For example, I suggested letting email lists
(suffering most badly ATM) promote their own admins in
http://lists.debian.org/debian-project/2007/06/msg00258.html

It's not soc-ctte or nothing!  We could take smaller steps first!


Sounds like out of context quoting.  My post was about regarding
cultural aspects of soc-ctte.  I wonder if you think that list master
intervention might serve cultural aspects better than a soc-ctte.

Kind regards

   Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[Manoj Srivastava]

On Sat, 30 Jun 2007 22:17:27 +0200 (CEST), Andreas Tille <[EMAIL PROTECTED]> 
said: 

> On Fri, 29 Jun 2007, Manoj Srivastava wrote:
>> In other words, we share a common technical "culture". This is not
>> the case for social culture of the community; and this distinction
>> would tend to make a difference, in my opinion.

> Well, we discussed it in private at DebConf (when I lost my live in an
> assassin attack ;-)).  I wonder in how far you think different
> cultural aspects are regarded if there is no social committee at all.

Not very much, if at all, I would imagine.

> So we have the choice to do either nothing against social problems in
> Debian or just give a soc-ctte a chance to try - your comments about
> the cultural diversion might be a helpful guideline here - but in my
> opinion no argument against a soc-ctte.

Why does everyone  see any discussion at all in the mailing list
 a binary, either-or, confrontational debate?

I am not talking about _not_ having a soc-ctte. I am talking
 about whether or not the selection criteria for ctte members needs to
 be looked at with due consideration to the cultural diversity.

Based on recent conversation in the list, I would suggest that
 the proportionality criteria for party list selection be given emhpasis
 for electing the members, so the minority cultures do not fail to have
 representation on the ctte, drowned our by the dominant cultural
 subgroups.

manoj
 ps: is it so hard to believe that people who actually want to improve a
 proposal are not all rah-rah cheer leaders for the idea? Or that all
 skeptics are not locked in a life-or-death struggle to scuttle the
 proposal?
-- 
Experiments must be reproducible; they should all fail in the same way.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[Manoj Srivastava]

On Sun, 01 Jul 2007 13:28:00 +0300, Kalle Kivimaa <[EMAIL PROTECTED]> said: 

> Josip Rodin <[EMAIL PROTECTED]> writes:
>> +  If the election requires multiple winners, the list of winners
>> is
>> + created by sorting the list of options by ascending strength.

> Why couldn't we just use some STV method for such elections? STV is a
> tried and proved method, no need for us to start inventing new
> methods.

Most traditional STV methods suffer from free riding (in which
 strategic voting as in not voting for people who you want to vote for,
 but who will, in your opinion, win anyway) and vote management. There
 is a modified STV method, that also satisfies the condorcet method, and
 falls back to our current mechanism for a single winner.

Our current method has been demonstrated to satisfy Pareto,
 monotonicity, resolvability, independence of clones, reversal symmetry,
 Smith-IIA, Schwartz, Woodall's plurality criterion, and Woodall's CDTT
 criterion, etc.

I think we should consider the paper pointed out by Antti-Juhani
 Kaijanaho, found at  http://m-schulze.webhop.net/schulze2.pdf

manoj
-- 
There are no saints, only unrecognized villains.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[Antti-Juhani Kaijanaho]

On Sun, Jul 01, 2007 at 01:28:00PM +0300, Kalle Kivimaa wrote:
> Why couldn't we just use some STV method for such elections? STV is a
> tried and proved method, no need for us to start inventing new
> methods.

Many of the tried and "proved" STV methods are faulty.  (Perhaps not as faulty
as iterating Condorcet, but still:)

-- 
Antti-Juhani Kaijanaho, Jyväskylä
http://antti-juhani.kaijanaho.fi/newblog/


signature.asc
Description: Digital signature

Re: soc-ctte discussion at DebConf7

[Kalle Kivimaa]

Josip Rodin <[EMAIL PROTECTED]> writes:
> +If the election requires multiple winners, the list of winners is
> +created by sorting the list of options by ascending strength.

Why couldn't we just use some STV method for such elections? STV is a
tried and proved method, no need for us to start inventing new
methods.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Josip Rodin]

On Wed, Jun 27, 2007 at 01:27:00PM +0200, Jacobo Tarrio wrote:
> > Just nitpicking, but is our Condorcet method for running election
> > suitable for voting when an (ordered) set of result is expected? Isn't
> > it targeted at finding only one winner (if it exists)?  Not a big
> 
>  It's targeted to finding the one winner, but it's easy to adapt to finding
> a list: get the winner, then remove it from the list of options and get the
> new winner, then remove it from the list of options and get the new winner,
> etc.

I never proposed that, for reasons made obvious by other people in the
thread. My ammendment to the standard resolution procedure was this:

+If the election requires multiple winners, the list of winners is
+created by sorting the list of options by ascending strength.

Instant disclaimer - I don't know if this is clear enough, I don't know
voting method syntax.

The point is that the list of options is *sorted*, and then N are taken
as winners. It's not run in a loop of N iterations.

And by "sorted" I mean the thing 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.

In that graph, no two options happened to be at the same horizontal level.
If by any chance we got that situation, my ammendment further stated:

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

I thought that that made sense.

Others?

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[MJ Ray]

Andreas Tille <[EMAIL PROTECTED]> wrote: [...]
> So we have the choice to do either nothing against social problems in
> Debian or just give a soc-ctte a chance to try [...]

That's a false dilemma.  For example, I suggested letting email lists
(suffering most badly ATM) promote their own admins in
http://lists.debian.org/debian-project/2007/06/msg00258.html

It's not soc-ctte or nothing!  We could take smaller steps first!

Amazed,
-- 
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Experienced webmaster-developers for hire http://www.ttllp.co.uk/
Also: statistician, sysadmin, online shop builder, workers co-op.
Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[Andreas Tille]

On Fri, 29 Jun 2007, Manoj Srivastava wrote:


   In other words, we share a common technical "culture". This is
not the case for social culture of the community; and this distinction
would tend to make a difference, in my opinion.


Well, we discussed it in private at DebConf (when I lost my live
in an assassin attack ;-)).  I wonder in how far you think different
cultural aspects are regarded if there is no social committee at all.
So we have the choice to do either nothing against social problems in
Debian or just give a soc-ctte a chance to try - your comments about
the cultural diversion might be a helpful guideline here - but in
my opinion no argument against a soc-ctte.

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Multi-winner elections, soc-ctte (Was: Re: soc-ctte discussion at DebConf7)

[Anthony Towns]

On Sat, Jun 30, 2007 at 10:00:47AM +0300, Antti-Juhani Kaijanaho wrote:
> On Fri, Jun 29, 2007 at 02:43:24PM -0500, Manoj Srivastava wrote:
> > It should be relatively straight forward for Devotee to find the
> >  winner, take the winner out of contention the next round, find the next
> >  winner (ignoring any pairwise contests dealing with any candidate no
> >  longer in the contest), and continue until the number of candidates
> >  desired has been reached.
> This is no doubt true.
> As I mentioned in another mail, this procedure does have the problem of not
> delivering proprtional results.
> A scenario.  

A simpler scenario. A bunch of candidates divide themselves into
essentially two parties, people focussed on free software, and people
focussed on our users. As it turns out, one group has 60% support within
the project, the other group has 40% support within the project. There
are six candidates, and three places to fill. Votes go along the lines of:

60% [ 1 ] A-1
[ 2 ] A-2
[ 3 ] A-3
[ 4 ] B-1
[ 5 ] B-2
[ 6 ] B-3


40% [ 4 ] A-1
[ 5 ] A-2
[ 6 ] A-3
[ 1 ] B-1
[ 2 ] B-2
[ 3 ] B-3

Condorcet gives the winner as A-1. Excluding A-1 gives you a Condorcet winner
of A-2. Excluding A-1 and A-2 gives you a Condorcet winner of A-3.

A more desirable outcome, IMO, would have given B-1 a seat in the above
circumstances. Which is what proportionality is all about...

Whether A is "free software" and B is "our users" or vice-versa is left as
an exercise for the reader. ;) Other plausible scenarios might involve
soc-ctte candidates promoting "freedom of speech" versus "improving
signal:noise".

Cheers,
aj



signature.asc
Description: Digital signature

Re: soc-ctte discussion at DebConf7

[MJ Ray]

Richard Hecker <[EMAIL PROTECTED]> wrote:
> Manoj Srivastava wrote:
> > Are we planning on taking into account things like cultural
> >  differences? Or is the decision going to be that the majority rule (or
> >  the dominant culture) be the governing one?
>
> I hope the committee will consider these differences before a
> decision is made. [...]

Hope for the best.  Prepare for the worst.

In light of Multi-winner elections, soc-ctte from Antti-Juhani
Kaijanaho, I think it's clear that iterating the DPL election method
does badly against the worst case.  So I looked at recent thinking on
multi-minority elections... governments.  About ten years ago, the UK
Government had a review commission under Roy Jenkins that surveyed
several systems and made recommendations.  You can download a 4Mb PDF
of its report from http://www.makemyvotecount.org.uk/opus16/vol1.pdf

Its recommendation was for alternative vote with a 20% open list
corrective additional member system.  Would soc-ctte candidate
factions group themselves to enable an AMS to work?

Looking more widely, some very divided communities seem to use Single
Transferable Vote when trying to include all views.  If candidates
won't group (which I think they won't), then I think I'd prefer STV.

Finally on this, a short note: I know soc-ctte isn't a bloody
government, but I think it will sometimes have to choose between
exclusive events, which is one thing which makes government so
divisive, so it's a fair place to look for ideas.

Manoj Srivastava <[EMAIL PROTECTED]> wrote: [...]
> I am not sure I agree that Debian as the melting pot is a viable
>  idea. And I find the  concept of cultural hegemony (in other words,
>  Debian culture is dictated by the predominant subgroups, everyone else
>  better fall in line) mildly distasteful.
>
> But if this is the will of the masses, I suppose I must give in.

Please don't.

Regards,
-- 
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Experienced webmaster-developers for hire http://www.ttllp.co.uk/
Also: statistician, sysadmin, online shop builder, workers co-op.
Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[Frank Küster]

Richard Hecker <[EMAIL PROTECTED]> wrote:

> Manoj Srivastava wrote:
>
> ..
>> I have seen no discussion on how the soc ctte is going to go
>>  about ensuring that such cultural differences are noticed, or taken
>>  into account in the resolution process; or that any thought has been
>>  taken to address cultural diversity in the dispute resolution process.
>>
>>   
> I see no way to legislate that cultural differences are "taken
> into account." About the only way I see of ensuring that these are
> considered is by selecting a committee that has a group with
> diverse backgrounds.

Which should be taken into account when designing the election and vote
evaluation method.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: soc-ctte discussion at DebConf7

[Frank Küster]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:

> I am not sure I agree that Debian as the melting pot is a viable
>  idea. And I find the  concept of cultural hegemony (in other words,
>  Debian culture is dictated by the predominant subgroups, everyone else
>  better fall in line) mildly distasteful.
>
> But if this is the will of the masses, I suppose I must give in.

I don't know about the masses, but I feel similar to you; and someone
(Andreas Tille or someone in reply to him?) has also expressed concern
about "minority viewpoints", which I think is approximately what you
have expressed much better as cultural differences.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: soc-ctte discussion at DebConf7

[Richard Hecker]

Manoj Srivastava wrote:

..

I have seen no discussion on how the soc ctte is going to go
 about ensuring that such cultural differences are noticed, or taken
 into account in the resolution process; or that any thought has been
 taken to address cultural diversity in the dispute resolution process.

  

I see no way to legislate that cultural differences are "taken
into account." About the only way I see of ensuring that these are
considered is by selecting a committee that has a group with
diverse backgrounds.


Are we planning on taking into account things like cultural
 differences? Or is the decision going to be that the majority rule (or
 the dominant culture) be the governing one?
  


I hope the committee will consider these differences before a
decision is made. I would propose that open, frank, and honest
communication between all the parties will bring such
differences to light. An independent objective third party like
the committee should be in a good position to recognize such
cultural differences. Whether any of the warring parties will
accept what the committee recognizes is an entirely
different matter ;-)

Richard


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Multi-winner elections, soc-ctte (Was: Re: soc-ctte discussion at DebConf7)

[Antti-Juhani Kaijanaho]

On Fri, Jun 29, 2007 at 02:43:24PM -0500, Manoj Srivastava wrote:
> It should be relatively straight forward for Devotee to find the
>  winner, take the winner out of contention the next round, find the next
>  winner (ignoring any pairwise contests dealing with any candidate no
>  longer in the contest), and continue until the number of candidates
>  desired has been reached.

This is no doubt true.

As I mentioned in another mail, this procedure does have the problem of not
delivering proprtional results.

A scenario.  Suppose that, in the future, Debian comes to be divided fairly
cleanly into three factions in terms of who should be elected in a particular
multi-winner election.  One of the factions has a 55 % support, the second has
30 % support and the third has the remaining 15 % support.  All three field
at least as many candidates as there are seats.  Supporters of a faction place
the candidates fielded by their faction above the candidates fielded by the
other factions.   Now, under the "iterate single-winner-Schulze" method, it
seems to me the winners will all be candidates fielded by the majority faction,
no candidates of the minority factions ending up elected.

Now, for the present discussion, this is relevant for the initial election
of the committee, and it may actually be relevant for reconfirmation as well
(if we decide that the soc ctte should be proportional, then the suggested
reconfirmation method is wrong).   It may even be desirable, in some
situations, to create a body that has no factions in itself (justifying "winner
takes all"), but I doubt the proposed soc committee is one of them.

-- 
Antti-Juhani Kaijanaho, Jyväskylä
http://antti-juhani.kaijanaho.fi/newblog/


signature.asc
Description: Digital signature

Re: soc-ctte discussion at DebConf7

[Manoj Srivastava]

On Fri, 29 Jun 2007 14:27:40 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 

> On Fri, Jun 29, 2007 at 02:37:46PM -0500, Manoj Srivastava wrote:
>> The first set of comments I have is related to efficacy, and,
>> perhaps, the notion of fairness.  There is a fundamental difference
>> between a technical committee and a social committee: a technical
>> issue is likely to be far less subjective

>  http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=162;bug=367709
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=177;bug=367709

> Ruling based on the technical details of a question is apparently no
> defense against accusations of subjectivity anyway.  Nor are any of
> our existing poor methods for dealing with social problems any less
> subjective, so I don't think this is a reason not to proceed.


Err, anyone can be accused of anything at anytime, apparently,
 on Debian lists; so that is not really the point.

Also, why would you think anyone is talking about not proceeding?

The point is disputes over technical matters are inherently
 different from disputes of social issues.  If you don't see that, I
 suppose we have little basis for further discussion -- I am finding it
 hard to explain what seems like a self evident fact to me.

>> and while there are tradeoff aspects to technical problems, it is far
>> easier to come up with reasons for the trade offs, and a rationale
>> for selecting one option over the other, and do so in a relatively
>> objective fashion.

> The weighting of the trade-offs is always subjective.

But the rationale of the tradeoffs can be objective, as can an
 explanation for why more weight is being placed on one side or the
 other.

> The technical committee works not because it's more *objective*, but
> because it's configured so that its particular subjectivity is biased
> in favor of institutional stability (= the status quo), which means
> developers are more likely to be accepting of such decisions because
> on some level the TC's bias shares an overall alignment with their
> own.

In other words, we share a common technical "culture". This is
 not the case for social culture of the community; and this distinction
 would tend to make a difference, in my opinion.

>> I have seen no discussion on how the soc ctte is going to go about
>> ensuring that such cultural differences are noticed, or taken into
>> account in the resolution process; or that any thought has been taken
>> to address cultural diversity in the dispute resolution process.

> I frankly think this is a red herring.  The society that the social
> committee is purposed to serve is not Chinese, or American, or
> Middle-Eastern, or French, or Indian, or German, or Japanese; it's
> Debian as a society per se that must be served by this committee.

The issue is not whether the soc-ctte server the culture of
 outer mongolia, or not; the issue is whether the committee recognizes
 the cause belli;  failure to do so would make rapproachment more
 ... difficult. 

> Now each member of the project is going to bring his or her own
> cultural preconceptions to the table, to be sure[1], and the overall
> Debian culture is certainly going to reflect to some degree the mother
> culture of the predominant subgroups (whether that's predominance in
> terms of numbers, contributions, key positions held within the
> project, or volume of mailing list posts).  But I think it's the
> responsibility of each individual developer to integrate themselves
> into the overall community, and that it should not be the role of the
> social committee to inject an artificial measure of "cultural
> sensitivity" beyond what the project as a whole is actually capable of
> sustaining.

I am not sure I agree that Debian as the melting pot is a viable
 idea. And I find the  concept of cultural hegemony (in other words,
 Debian culture is dictated by the predominant subgroups, everyone else
 better fall in line) mildly distasteful.

But if this is the will of the masses, I suppose I must give in.

> And OTOH, I think to some degree recognition of cultural differences
> falls out *naturally* from any social committee whose charter includes
> rapprochement instead of just judgement and sentencing.  If
> rapprochement is your goal, all the cultural background that
> contributes to explaining *why* an individual views a situation the
> way they do is much less important than understanding *that* they
> understand the situation in that way.

My point was that unless care is taken in ensuring the ctte
 diversity, the ctte might not even be aware that one of the disputants
 views a situation differently (and why they might not be open to
 explaining that); far less than knowing the reasons behind the views.

>> Are we planning on taking into account things like cultural
>> differences? Or is the decision going to be that the majority rule
>> (or the dominant culture) be the governing one?

Re: soc-ctte discussion at DebConf7

[Steve Langasek]

On Fri, Jun 29, 2007 at 02:37:46PM -0500, Manoj Srivastava wrote:
> The first set of comments I have is related to efficacy, and,
>  perhaps, the notion of fairness.  There is a fundamental difference
>  between a technical committee and a social committee: a technical issue
>  is likely to be far less subjective

 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=162;bug=367709
 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=177;bug=367709

Ruling based on the technical details of a question is apparently no defense
against accusations of subjectivity anyway.  Nor are any of our existing
poor methods for dealing with social problems any less subjective, so I
don't think this is a reason not to proceed.

> and while there are tradeoff aspects to technical problems, it is far
> easier to come up with reasons for the trade offs, and a rationale for
> selecting one option over the other, and do so in a relatively objective
> fashion.

The weighting of the trade-offs is always subjective.

The technical committee works not because it's more *objective*, but because
it's configured so that its particular subjectivity is biased in favor of
institutional stability (= the status quo), which means developers are more
likely to be accepting of such decisions because on some level the TC's bias
shares an overall alignment with their own.

> I have seen no discussion on how the soc ctte is going to go
>  about ensuring that such cultural differences are noticed, or taken
>  into account in the resolution process; or that any thought has been
>  taken to address cultural diversity in the dispute resolution process.

I frankly think this is a red herring.  The society that the social
committee is purposed to serve is not Chinese, or American, or
Middle-Eastern, or French, or Indian, or German, or Japanese; it's Debian as
a society per se that must be served by this committee.

Now each member of the project is going to bring his or her own cultural
preconceptions to the table, to be sure[1], and the overall Debian culture
is certainly going to reflect to some degree the mother culture of the
predominant subgroups (whether that's predominance in terms of numbers,
contributions, key positions held within the project, or volume of mailing
list posts).  But I think it's the responsibility of each individual
developer to integrate themselves into the overall community, and that it
should not be the role of the social committee to inject an artificial
measure of "cultural sensitivity" beyond what the project as a whole is
actually capable of sustaining.

And OTOH, I think to some degree recognition of cultural differences falls
out *naturally* from any social committee whose charter includes
rapprochement instead of just judgement and sentencing.  If rapprochement is
your goal, all the cultural background that contributes to explaining *why*
an individual views a situation the way they do is much less important than
understanding *that* they understand the situation in that way.

> Are we planning on taking into account things like cultural
>  differences? Or is the decision going to be that the majority rule (or
>  the dominant culture) be the governing one?

Do you take into account cultural differences every time you send a mail to
a mailing list or reply to a bug report, or do you allow your cultural ideas
to dominate by virtue of your position of authority (as a package maintainer
or as a community "elder")?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/

[1] There have been a number of mailing list threads over the past year that
have opened my own eyes to just how different American culture is from
French and Belgian culture in some ways, in spite of these countries
supposedly sharing a common overall Western heritage


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[Manoj Srivastava]

Hi,

Firstly, wearing my secretary hat, I have no objections to
 running votes for the soc-ctte membership, if we do decide such votes
 are how things will be done.

Now, taking the hat off, and speaking bare headed, I have a
 couple of comments to make.

The first set of comments I have is related to efficacy, and,
 perhaps, the notion of fairness.  There is a fundamental difference
 between a technical committee and a social committee: a technical issue
 is likely to be far less subjective, and while there are tradeoff
 aspects to technical problems, it is far easier to come up with reasons
 for the trade offs, and a rationale for selecting one option over the
 other, and do so in a relatively objective fashion.

A social committee resolving disputes has no such luxury.  In a
 sense, since a machine interprets the end results of technical problems
 (well, for the most part), we tend to speak in one language; but as
 Debian contributers come from varied and diverse backgrounds and
 cultures, the cultural differences have an impact on the disputes and
 also the perception of the resolution.

Differences in culture make the difference between commonplace
 conversation and unacceptable insults; there are various anecdotes
 about ocidental and mist eastern differences in something as simple as
 inviting a guest to the dinner table (us americans would be seen as
 horribly rude). An anecdote I tell deals with a young developer on an
 Indian mailing list somewhat rudely contradicting me about the Etch
 release; the other members jumped on him not because he was incorrect,
 nor necessarily because of his rudeness; but because a lack of respect
 from a younger person to an older person was unacceptable.

The age based distinction would make absolutely no sense for my
 American friends.

I have seen no discussion on how the soc ctte is going to go
 about ensuring that such cultural differences are noticed, or taken
 into account in the resolution process; or that any thought has been
 taken to address cultural diversity in the dispute resolution process.

Are we planning on taking into account things like cultural
 differences? Or is the decision going to be that the majority rule (or
 the dominant culture) be the governing one?

The second set of comments I have are about accountability (and,
 yes, this applies to the tech ctte as well). Who are the tech and soc
 ctte members accountable to? Is there any recourse to the membership,
 apart from overturning individual decisions via a GR, to counteract a
 committee (social or technical) that has turned wayward and out of
 control?



manoj
-- 
The girl who remembers her first kiss now has a daughter who can't even
remember her first husband.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[Manoj Srivastava]

On Tue, 26 Jun 2007 23:16:50 +0200, Stefano Zacchiroli <[EMAIL PROTECTED]> 
said: 

> Just nitpicking, but is our Condorcet method for running election
> suitable for voting when an (ordered) set of result is expected? Isn't
> it targeted at finding only one winner (if it exists)?  Not a big
> problem though: I guess if it's not suitable we can find an
> alternative method, but I definitely don't want a ballot with all
> possible permutation of resulting soc-ctte :-) Something to be looked
> for before the election though, or maybe Manoj can enlighten all us
> out of the box.

It should be relatively straight forward for Devotee to find the
 winner, take the winner out of contention the next round, find the next
 winner (ignoring any pairwise contests dealing with any candidate no
 longer in the contest), and continue until the number of candidates
 desired has been reached.

manoj
-- 
Moore's Constant: Everybody sets out to do something, and everybody does
something, but no one does what he sets out to do.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Andreas Tille]

On Thu, 28 Jun 2007, Josip Rodin wrote:


While I certainly appreciate Andreas organizing the talk in the first place,
because if he hadn't, it wouldn't have even gotten into the schedule early
enough for people to generally notice it :) it does seem that we would have
been better off having someone formally steer the discussion and take
official notes (with obligatory interjections, saying "all right, now
everybody making casual comments shut up, do we agree on point X or do
we not?" :).


You are perfectly right.  I intended in the first place some kind of
unmoderated brainstorming but I should have noticed that we just crossed
the line to real decisions by far.  Sorry, perhaps we should do some
"fork universe" before such events to enable us to see how it would
work better when doing different things.  So sorry if I did not made
something better out of it.  I hope that the recording contains the
main information - at least this was my hope when I concentrated more
on the discussion than onto making much notes.


The meeting agreed that a DPL delegation was the appropriate basis for
the SC.  This would allow the process to be refined as we get more
experience and also helpfully provides a useful appointment mechanism.


(I agreed only on the former part of that sentence, but not on the latter :)


Well, I'd regard it "useful" because it might be the fastest way
to get an appointment.  If we do not really know which might be the
best method I'd go for the faster and observe closely how it works.

Kind regards

 Andreas.


--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Andreas Barth]

* Ian Jackson ([EMAIL PROTECTED]) [070627 23:31]:
> Raphael Hertzog writes ("Re: soc-ctte discussion at DebConf7 [was Re: Social 
> committee proposal]"):
> > AFAIR, the consensus was that:
> > - by default, every 2 years the project has to reapprove individually each
> >   member of the soc-ctte. This gives the project an opportunity to recall
> >   members who are judged as no more representative or whatever.
> >   Reapproving probably means having more ranking above NOTA than rankings
> >   below NOTA. Maybe we should make that ratio 66%.
> 
> I remember 1 year rather than 2 but it doesn't make much difference.

Actually, we had two different voting systems with different time
ranges:

Either "normal" voting with 2 years (though voting every year, but only
on half of the people), or approval voting every year. Basically, voting
every year is ok, but we want to avoid having too large changes
happening to the people to "keep the knowledgebase intact". (As with
approval voting, that goal is reached different, so we can vote every
year on everyone, and not only on half of the people.)


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Josip Rodin]

On Wed, Jun 27, 2007 at 10:22:04PM +0100, Ian Jackson wrote:
> > One thing that I hadn't had the chance to mention (because other people were
> > simply being louder than me ;) was that the "proactivity" still needs to be
> > documented in an internal archive of soc-ctte, so that there is a clear
> > record of exactly what was done in the name of the committee and when.
> 
> I think that it might be useful for the SC members to send two kinds
> of private mails:
>  * Ones which are fairly formal and which are CC'd to soc-ctte
>(and hence visible in the private archive).
>  * Informal messages which are wholly private and which the other SC
>members are not necessarily aware of.
> 
> The important point here is to allow people who are temporarily
> misbehaving to back down without losing face.  The fewer people see
> anything that could be thought of as a reprimand, the easier that is.
> 
> Because those latter informal messages will probably happen anyway I
> think it's important to make the rule that the SC members are taken to
> have waived their normal right of confidentiality for such a message
> (even if it doesn't explicitly contain any mention of the SC).

In the second case, I think it's best that they still Cc: a second private
alias, one kept in a directory that is readable only to soc-ctte members.
That will keep it out of the general view and the view of thousands of
developers, but there will still be a clear record of it.

> > Well, I think that that's inconsistent. The DPL shouldn't be able to
> > randomly modify ('undelegate') membership in the soc-ctte once they were
> > confirmed by the developer body using the normal voting procedure.
> 
> I think in fact it's probably fine for the DPL to be able to do that.
> In practice this isn't going to come up unless the DPL is very sure of
> their ground.
> 
> I think this is the price we pay for 1. the flexibility of having the
> DPL be able to easily change the setup if it turns out not to be
> working so well

I'm not sure why this flexibility is necessary. Granted, it's a new body
and we don't know if it will implode and take down the universe, but
I really believe that we can set it up sufficiently right from the start
that it doesn't require a 'nuclear button'.

> and 2. a clear backstop limit on the SC's powers
> (which are necessarily derived from the DPL's).

Once the GR approves the committee, the powers are derived from the
developers in general, not just the leader. I argued this before - just
because the leader is theoretically in charge of this stuff right now
under the constitution, that doesn't make it his powers, because they're
not used (for whatever reason).

> > In general I don't see the rationale for the leader to be naming people
> > to the social committee which is already elected separately.
> 
> No, the ideal isn't that we elect people to the SC.  The voting is not
> a way to select the committee from a long list of candidates.

Erm, excuse me, but my original proposals from months ago were exactly that,
and the people who commented then seemed to like it (at least sufficiently
enough for none of them to actually voice a negative opinion on the whole
concept of voting them!).

Please refer to the earlier threads on this mailing list:

http://lists.debian.org/debian-project/2007/01/msg00063.html
http://lists.debian.org/debian-project/2007/02/msg00055.html

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Josip Rodin]

On Thu, Jun 28, 2007 at 07:32:15AM +0200, Josip Rodin wrote:
> > Straight elections were not considered to be a good appointment
> > strategy, at least for any subsequent years, because most of the work
> > done by the committee is in private.
> 
> This is also something that I didn't get a chance to respond to as well
> as I intended, so please excuse the following rant :)
> 
> While the analysis of the tenure at the committee is certainly a useful
> criterion on which the voters would decide whether a member should be kept
> or removed, I don't think that it is the most important, because of the
> nature of the committee - we basically want this body to elaborate and
> establish certain social consensuses (consensa? sp?), and then when
> necessary enforce it against people who are so out of line that they
> piss off most everyone else.
> 
> For that, most of the time, you just need a few level-headed people with a
> sufficient supply of common sense. They don't need a particular procedural
> skill - it's sufficient if they are just guided by others. They don't need
> to demonstrate that they were level-headed and common-sensical (heh) just
> on the committee - I think that they should continuously demonstrate these
> qualities in social interactions *in general*.
> 
> I don't want us to end up with a couple of members appointed and elected
> because they're otherwise somehow popular (usually because they have l33t
> technical skills :) which are cool, but mainly irrelevant here), and then
> at re-election time they feel a need to demonstrate their actions on the
> soc-ctte, and then the problem of private interactions comes up. That's
> not necessary.
> 
> The voters will generally simply observe whether these people continued
> to act sensibly on the committee, and sensibly in general, and they will
> appreciate this by continuing to affirm them in the committee.
> Debian is a pretty cooperative bunch (I did manage to mention that
> particular point, but wasn't able to explain all what I meant by that :)
> and for any soc-ctte member it will not take much effort to convince people
> not to randomly replace them.
> 
> (Yet, the people should continue to have even that option, to randomly
> replace people, because eventually they might get tired from seeing all
> the same faces on the committee all the time :) and that's perfectly all
> right, actually, because I do hope that we have a long line of other
> level-headed common-sensical people ready to serve.)

And, obviously, here I refer primarily to the *committee* function of
soc-ctte. These remarks don't all apply to the 'social team' function --
those people need to have more procedural skills and they have to
be judged on their ability to do the concrete work of the team.

But I think that soc-ctte should primarily perform the committee function,
and then the existence of that will facilitate the team-like action, whether
by those same people or by other people, because they will have a solid
backing - a place to refer to and to appeal to when in doubt, so it will
be easier to do the work.

This is similar to one of the ideas discussed all some of governance bofs at
dc7... when people have a mission statement or a manifesto, or in this case
more generically: a documented commonness in ideas and procedures, it
becomes easier for all of them act to resolve certain conflicts.

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Josip Rodin]

On Wed, Jun 27, 2007 at 10:03:56PM +0100, Ian Jackson wrote:
> Rationale
> -
> 
> There wasn't a huge amount of discussion about this; mostly people
> seemed to acquiesce to the way I put it, which is that we need some
> method for dealing with disruptive behaviour that lies between
> individuals asking for it to stop and expelling people.

Yet I wouldn't go so far to say that this was the only rationale why people
attended and supported the idea. It should be mentioned that it was early in
the morning, that people were still coming in through the initial part of
the debate, and that many people have a problem with just taking over the
podium in front of a group of people and expressing a general introductory
opinion. (Unlike you and me, perhaps ;)

While I certainly appreciate Andreas organizing the talk in the first place,
because if he hadn't, it wouldn't have even gotten into the schedule early
enough for people to generally notice it :) it does seem that we would have
been better off having someone formally steer the discussion and take
official notes (with obligatory interjections, saying "all right, now
everybody making casual comments shut up, do we agree on point X or do
we not?" :).

But it's not a big problem, we are a herd of cats after all :)

> I mentioned that I wasn't sure about it myself and that we should
> probably limit the power to apply to access to _communications
> facilities_.  That would deal with the cases of CVS repositories and
> team membership.

I think that this was mostly covered by my latest proposal, because
I phrased it like this:

  Intervene in communication processes in matters of common interest.

  The Social Committee may issue a formal request that a person refrain
  from certain acts and communications. [...]

(Did you read that diff? :) Now it shouldn't be a diff any more, I better
go rephrase and repost it as a statement.)

> The meeting agreed that a DPL delegation was the appropriate basis for
> the SC.  This would allow the process to be refined as we get more
> experience and also helpfully provides a useful appointment mechanism.

(I agreed only on the former part of that sentence, but not on the latter :)

> Straight elections were not considered to be a good appointment
> strategy, at least for any subsequent years, because most of the work
> done by the committee is in private.

This is also something that I didn't get a chance to respond to as well
as I intended, so please excuse the following rant :)

While the analysis of the tenure at the committee is certainly a useful
criterion on which the voters would decide whether a member should be kept
or removed, I don't think that it is the most important, because of the
nature of the committee - we basically want this body to elaborate and
establish certain social consensuses (consensa? sp?), and then when
necessary enforce it against people who are so out of line that they
piss off most everyone else.

For that, most of the time, you just need a few level-headed people with a
sufficient supply of common sense. They don't need a particular procedural
skill - it's sufficient if they are just guided by others. They don't need
to demonstrate that they were level-headed and common-sensical (heh) just
on the committee - I think that they should continuously demonstrate these
qualities in social interactions *in general*.

I don't want us to end up with a couple of members appointed and elected
because they're otherwise somehow popular (usually because they have l33t
technical skills :) which are cool, but mainly irrelevant here), and then
at re-election time they feel a need to demonstrate their actions on the
soc-ctte, and then the problem of private interactions comes up. That's
not necessary.

The voters will generally simply observe whether these people continued
to act sensibly on the committee, and sensibly in general, and they will
appreciate this by continuing to affirm them in the committee.
Debian is a pretty cooperative bunch (I did manage to mention that
particular point, but wasn't able to explain all what I meant by that :)
and for any soc-ctte member it will not take much effort to convince people
not to randomly replace them.

(Yet, the people should continue to have even that option, to randomly
replace people, because eventually they might get tired from seeing all
the same faces on the committee all the time :) and that's perfectly all
right, actually, because I do hope that we have a long line of other
level-headed common-sensical people ready to serve.)

> >   * The communication of soc-ctte members with people about their
> > behaviour which might eventually become a matter of committee
> > deliberation should be kept reasonably private, to prevent
> > unnecessary escalation
> 
> However, we agreed that if an SC member communicates privately with
> someone on a matter covered by the SC's remit (eg, to give advice or
> praise or ask someone to stop doing something), the

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Ian Jackson]

Josip Rodin writes ("Re: soc-ctte discussion at DebConf7 [was Re: Social 
committee proposal]"):
> One thing that I hadn't had the chance to mention (because other people were
> simply being louder than me ;) was that the "proactivity" still needs to be
> documented in an internal archive of soc-ctte, so that there is a clear
> record of exactly what was done in the name of the committee and when.

I think that it might be useful for the SC members to send two kinds
of private mails:
 * Ones which are fairly formal and which are CC'd to soc-ctte
   (and hence visible in the private archive).
 * Informal messages which are wholly private and which the other SC
   members are not necessarily aware of.

The important point here is to allow people who are temporarily
misbehaving to back down without losing face.  The fewer people see
anything that could be thought of as a reprimand, the easier that is.

Because those latter informal messages will probably happen anyway I
think it's important to make the rule that the SC members are taken to
have waived their normal right of confidentiality for such a message
(even if it doesn't explicitly contain any mention of the SC).

> > We also agreed that the formulation was a bit broad. For instance,
> > granting "adm" membership (ie DSA team rights) is also an ACL decision,
> > but it's certainly not the resort of the social ctte.
> 
> Right, but I don't think that someone would actually argue that.
> That's simply not a social issue so by default it's not a soc-ctte issue.

These kinds of things have been subject to some argument in the past.
We should make it clear that this isn't covered.

> > - make decision concerning DD's behaviour everywhere where they are acting
> >   as member/representative of the project (including #debian* IRC channels).
> 
> Also non-DDs in such venues, Sam mentioned something like that.
> Sponsored maintainers too, I guess.

Yes.

> Well, I think that that's inconsistent. The DPL shouldn't be able to
> randomly modify ('undelegate') membership in the soc-ctte once they were
> confirmed by the developer body using the normal voting procedure.

I think in fact it's probably fine for the DPL to be able to do that.
In practice this isn't going to come up unless the DPL is very sure of
their ground.

I think this is the price we pay for 1. the flexibility of having the
DPL be able to easily change the setup if it turns out not to be
working so well and 2. a clear backstop limit on the SC's powers
(which are necessarily derived from the DPL's).

> > We have decided to have 2 GR at the same time. One deciding the creation
> > of the soc-ctte and one deciding its membership.
> 
> Yes, but it wasn't clear who would compose the ballot for the membership.

The DPL will 1. invite candidates; 2. filter them; 3. publish the
draft list (inviting rejected candidates if any to get K sponsors).

> > AFAIR, the consensus was that:
> > - whenever a soc-ctte member steps down (or is recalled due to the
> >   reapproval vote), the DPL appoints a new member
> >   (unless he decided to vary the size of the team)
> 
> I didn't see this as a consensus decision, because there was a lot of murmur
> in the room at the time :) and I believe I tried to object, but it was
> pretty late anyway.

:-).

> In general I don't see the rationale for the leader to be naming people to
> the social committee which is already elected separately.

No, the ideal isn't that we elect people to the SC.  The voting is not
a way to select the committee from a long list of candidates.  It's
there so that the developers can get rid of a loose cannon without
having to find K sponsors for a recall GR.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Ian Jackson]

Raphael Hertzog writes ("Re: soc-ctte discussion at DebConf7 [was Re: Social 
committee proposal]"):
> Basicaly, any communication concerning the "proactive" part shall be
> private. The person receiving the warning can publicize it by themselves
> if they so desire (but it's certainly not expected to be the general rule,
> it's just to avoid the criticism of lack of transparency).

Right.

> We also agreed that the formulation was a bit broad. For instance,
> granting "adm" membership (ie DSA team rights) is also an ACL decision,
> but it's certainly not the resort of the social ctte.
> 
> So we sort of decided that it should:
> - make ACL decisions concerning the Debian lists (the listmasters clearly
>   indicated that they don't want to take those by themselves)
>   This includes the possibility to decide ML bans for DD as well as
>   for non-DD.
> - make decision concerning DD's behaviour everywhere where they are acting
>   as member/representative of the project (including #debian* IRC channels).
> - make recommandation to any other party that defers a judgment to the
>   social ctte (example: the OFTC admin defers a dispute on the
>   soc-ctte over ownership of a channel #debian*)
> 
> Since it's a "delegated body", the DPL can grant additionals powers if
> needed.

This is a good alternative to explicitly specifying the powers.

> We have decided to have 2 GR at the same time. One deciding the creation
> of the soc-ctte and one deciding its membership.

Indeed so.

> AFAIR, the consensus was that:
> - by default, every 2 years the project has to reapprove individually each
>   member of the soc-ctte. This gives the project an opportunity to recall
>   members who are judged as no more representative or whatever.
>   Reapproving probably means having more ranking above NOTA than rankings
>   below NOTA. Maybe we should make that ratio 66%.

I remember 1 year rather than 2 but it doesn't make much difference.

I disagree about the voting system.  We should use straight approval
voting: each voter votes `yes' or `no' separately for each candidate.
Candidates who get more `yes' than `no' get to stay.  Others are
dismissed.

The DPL will then make up the numbers.  Obviously the DPL is expected
not to reappoint the dismissed members (even though that's technically
possible).

I don't think it's necessarily a problem that the DPL has in theory
powers which the SC setup expects the leader not to use.  After all
any such outrage could be overruled by GR.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Ian Jackson]

Josip Rodin writes ("soc-ctte discussion at DebConf7 [was Re: Social committee 
proposal]"):
> Ian said he'll send over his notes, but I'm impatient so I'll have a go :)

Right, thanks :-).  My recollection and notes broadly agree with you.

I'll write from my notes a new posting because that's easier, and then
follow up to your comments where they seem to have disagreed.  That
will make this message of mine rather long, I'm afraid.

We discussed:
  - Rationale
  - Powers and jurisdiction
  - Appointment
  - Procedure
  - How to appeal or overrule the committee's decisions


Rationale
-

There wasn't a huge amount of discussion about this; mostly people
seemed to acquiesce to the way I put it, which is that we need some
method for dealing with disruptive behaviour that lies between
individuals asking for it to stop and expelling people.

We discussed what kind of structure should take these decisions and we
seemed to all agree that a group of several people was best - ie, a
committee.


Powers
--

I tried to get people to refine (ie, disagree with) my `access control
decisions' formulation for the scope of the committee's power.  Sadly
this was quite difficult.

I mentioned that I wasn't sure about it myself and that we should
probably limit the power to apply to access to _communications
facilities_.  That would deal with the cases of CVS repositories and
team membership.


Jurisdiction and appeal
---

As Josip says, we basically agreed that in cases of disputed
jurisdiction the DPL would decide whether a dispute was for the TC or
the SC.  Normally, hopefully, all the parties would agree which
committee was right.  There was some discussion of how to get a
disputant to agree to the jurisdiction up-front, which I felt was
essential.

There would be no appeal from the SC to the TC or vice versa.
Likewise there would be no appeal of a decision, once made, to the
DPL.  Any appeal from either committee's decision must be via GR.


Procedure
-

We agreed that the committee members ought to be allowed (and indeed
encouraged) to make informal private comments to people about their
behaviour.  Any actual binding decision would definitely be made
public.  I don't remember a clear consensus on whether discussions and
non-binding recommendations should necessarily be public.


Appointment and constitutional basis


The meeting agreed that a DPL delegation was the appropriate basis for
the SC.  This would allow the process to be refined as we get more
experience and also helpfully provides a useful appointment mechanism.

Straight elections were not considered to be a good appointment
strategy, at least for any subsequent years, because most of the work
done by the committee is in private.

IIRC we settled on individual approval voting on each member: each
year the DDs would vote seperately for each SC member in a straight
`keep or ditch' fashion.  SC members voted off in this way would be
replaced by appointments made by the DD.

We also felt that to give the committee legitimacy it should be
initially constituted by a DPL-proposed-GR.



So, discussion of Josip's notes:

>   * The communication of soc-ctte members with people about their behaviour
> which might eventually become a matter of committee deliberation should
> be kept reasonably private, to prevent unnecessary escalation

However, we agreed that if an SC member communicates privately with
someone on a matter covered by the SC's remit (eg, to give advice or
praise or ask someone to stop doing something), then such messages may
be published without the consent of the SC member.  This allows an
out-of-control SC member to be challenged more effectively.

>   * The phrasing of the access control power should be subtle enough to
> avoid the pitfall of people complaining to the soc-ctte regarding
> political decisions such as who has commit access to a VCS repository,
> because there the distinction between 'political', 'technical' and
> 'social' can be blurry, which might cause problems, and nobody really
> had an answer for that

I think I have come to the conclusion that limiting its binding
decisions to access control to project-owned communication facilities
will be sufficient.

> * The establishment and composition of the actual soc-ctte:
>   * We seemed to agree that a leader's delegation would be a useful tool to
> bootstrap the soc-ctte and modify it later (even though it's unclear
> whether the constitutional barrier to leader messing with the delegates
> would apply), as opposed to the inclusion in the constitution which
> would delay the process and make it less modifiable later - a proposed
> compromise solution is that a general res

Multiple-winner elections and Condorcet (Was: Re: soc-ctte discussion at DebConf7)

[Antti-Juhani Kaijanaho]

On Wed, Jun 27, 2007 at 01:27:00PM +0200, Jacobo Tarrio wrote:
[ on the Debian Condorcet method ]
>  It's targeted to finding the one winner, but it's easy to adapt to finding
> a list: get the winner, then remove it from the list of options and get the
> new winner, then remove it from the list of options and get the new winner,
> etc.

The reason we use the Condorcet method (particularly, I believe, its Schulze
variant) is that it satisfies all kinds of nice properties.  The obvious
adaptation you mention fails a property which I consider a very important
property of multiple-winner election methods (namely, proportionality).

However, there is a proposal from Markus Schulze for a multiple-winner election
method that is claimed to satisfy proportionality and that contains the
single-winner Schulze method as a special case.  (See
http://m-schulze.webhop.net/schulze2.pdf)

-- 
Antti-Juhani Kaijanaho, Jyväskylä
http://antti-juhani.kaijanaho.fi/newblog/


signature.asc
Description: Digital signature

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Jacobo Tarrio]

El martes, 26 de junio de 2007 a las 23:16:50 +0200, Stefano Zacchiroli 
escribía:

> Just nitpicking, but is our Condorcet method for running election
> suitable for voting when an (ordered) set of result is expected? Isn't
> it targeted at finding only one winner (if it exists)?  Not a big

 It's targeted to finding the one winner, but it's easy to adapt to finding
a list: get the winner, then remove it from the list of options and get the
new winner, then remove it from the list of options and get the new winner,
etc.

-- 
   Jacobo Tarrío | http://jacobo.tarrio.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

list-admins and juries, was Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[MJ Ray]

Josip Rodin <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 26, 2007 at 10:48:51AM +0100, MJ Ray wrote:
> > I feel we're really missing most sorely list-admin teams [...]
>
> The problem with that is that nobody is proposing any sort of a model
> by which these teams would be composed.

Naive proposal for composing these teams:

Each list will have up to five list-admins.  Each list-admin may be
admin of no more than three lists.  A list-admin may be appointed or
removed by filing a bug against lists.debian.org and getting 12 more
supporters than objectors for the change from last months posters to
that list.  As part of their bug closure message, listmasters may
decide to discount any irregular supporters or objectors (such as
people posting mainly to contribute to such a bug).

I hope that list-admins would have some way of updating the list info
page and would have their requests prioritised by listmasters, but I
leave the technical details to them.

Another nice touch is that addition or removal of a list-admin is a
bug, which is probably a good way to view it.  In an ideal world, they
shouldn't be needed to do anything, but I think we do need some now.

Comments?

> I personally can't see such a thing
> going far, because that would create various rulesets for various lists,
> and require involvement of far too many people to be authoritative.

Those rulesets already exist, whether documented or not.  I also think
that involving many people will help to make the lists popularly-managed
- this is more about grassroots control more than authority.

[...]
> > Will its actions also be heavy, as the "big stick" mentioned in its powers
> > suggests it could.
>
> The main point, which apparently eluded you :) was that it needs to be able
> to have a big stick simply so that it has tangible authority. For some
> people, the authority provided by being a regularly elected body might
> not be sufficient to make them respect it.

So shall we top the big sticks with an axe, to show that authority in
the classical way?  (see "dict fasces")

I remember similar stupid arguments being used by governments
throughout history, but I won't go further lest the thread dies.
In short: owning the big stick is not a good way to rule.

[...]
> > Was the jury selection model discussed at all?
>
> I don't think it was. Can you explain a bit?

It was in the end of the thread-starter:

"A third idea: instead of having delegates or a committee or
whatever to decide amongst disputes, how about randomly selecting
a jury from DDs and having their word (on who's right, on what
punishment is plausible) be absolutely final, with no appeal,
ever?"
http://lists.debian.org/debian-project/2007/05/msg00240.html

I don't think the "no appeal" is realistic, but I believe there's a
lot to commend that approach for these disputes.  At least you get a
random chance of having similar viewpoints in the jury.

Regards,
-- 
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Experienced webmaster-developers for hire http://www.ttllp.co.uk/
Also: statistician, sysadmin, online shop builder, workers co-op.
Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Gaudenz Steinlin]

On Tue, Jun 26, 2007 at 04:50:37PM -0700, Mike Bird wrote:
> On Tuesday 26 June 2007 15:33, Gaudenz Steinlin wrote:
> > After a decision is made I think it's less problematic to make the
> > discussion available to all DDs. But still there is the problem, that
> > offending behaviour would be exposed to all DDs.
> 
> The committee's deliberations should be solely based on objective facts.
> 
> If the committee's deliberations cannot withstand the light of day,
> they are not a sufficiently robust basis for a _Debian_ decision.
> 
> Cabals and secret deliberations are the antithesis of freedom.
> 

Judging form the part of my message you cited above, you probably
misunderstood what I wanted to say. My reasoning in that part was 
not that the comitee should be able to keep the reasoning private
because the comitee members fear something (or whatever other reason),
but that the offender might wish to keep the fact private that an action
was taken by the comitee against him. In case of only minor offences I
think it might be reasonable to keep the name of the offender secret and
to only publish an annonimized version to all DDs. This way the offender
does not loose his face.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Stefano Zacchiroli]

On Tue, Jun 26, 2007 at 09:19:46AM +0200, Raphael Hertzog wrote:
> We have decided to have 2 GR at the same time. One deciding the creation
> of the soc-ctte and one deciding its membership.

> - by default, every 2 years the project has to reapprove individually each
>   member of the soc-ctte. This gives the project an opportunity to recall
>   members who are judged as no more representative or whatever.
>   Reapproving probably means having more ranking above NOTA than rankings
>   below NOTA. Maybe we should make that ratio 66%.

Just nitpicking, but is our Condorcet method for running election
suitable for voting when an (ordered) set of result is expected? Isn't
it targeted at finding only one winner (if it exists)?  Not a big
problem though: I guess if it's not suitable we can find an alternative
method, but I definitely don't want a ballot with all possible
permutation of resulting soc-ctte :-)  Something to be looked for before
the election though, or maybe Manoj can enlighten all us out of the box.

( Sorry I can't look for the answer of the above by myself, but I'm
writing offline )

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Raphael Hertzog]

On Tue, 26 Jun 2007, Josip Rodin wrote:
> On the other hand, a single social committee provides for a body which will
> be by and large neutral towards all lists (it will apply the same reasoning
> towards all).

... if the committee isn't too big. I don't expect "early warnings" to be
approved by a majority of the ctte members before they are sent out.
Otherwise this team will never do anything. On the other hand, since such
notices are always cced to the ctte, I expect some internal discussions at
the beginning to discuss what warrants a warning and what doesn't (and how
to properly draft them).

However for more important decisions (list ban, etc.), there must be an
internal vote in order to provide some confidence that the decision was
the right one.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Mike Bird]

On Tuesday 26 June 2007 15:33, Gaudenz Steinlin wrote:
> After a decision is made I think it's less problematic to make the
> discussion available to all DDs. But still there is the problem, that
> offending behaviour would be exposed to all DDs.

The committee's deliberations should be solely based on objective facts.

If the committee's deliberations cannot withstand the light of day,
they are not a sufficiently robust basis for a _Debian_ decision.

Cabals and secret deliberations are the antithesis of freedom.

--Mike Bird


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Don Armstrong]

On Wed, 27 Jun 2007, Gaudenz Steinlin wrote:
> I think that the internal discussions should be kept private to the
> soc-ctte at least as long as no decision is made. As decisions made
> by the comitee will probably quite often involve social behaviour of
> DDs I think it's problematic if all DDs can read the internal
> discussions of the comitee members.

DDs have to have a level of oversight over the committee. This
includes being aware of the rationale behind decisions as well as the
decision making process which leads up to them. Cases where decisions
are not made are as important as cases where they are. Members of the
committee who are concerned about that level of oversight probably
shouldn't be on the committee.

It's fine to make distribution of the internal discussion list
non-automatic, but it needs to be viewable. It's also seems
appropriate if the internal discussion list is moderated or restricted
to ctte members.


Don Armstrong

-- 
Information wants to be free to kill again.
 -- Red Robot http://www.dieselsweeties.com/archive.php?s=1372

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Gaudenz Steinlin]

On Tue, Jun 26, 2007 at 05:19:27PM +0200, Josip Rodin wrote:
> On Tue, Jun 26, 2007 at 09:19:46AM +0200, Raphael Hertzog wrote:
> 
> > The biggest decisions need to be publicly documented however. I don't
> > think we've clearly drawn the line here. I'm also unsure if it's important
> > to have a clear line here. We can just let the ctte draw the line where
> > it's appropriate given that any communication concerning the ctte should
> > ideally be archived on master.d.o just like other aliases are archived
> > there ([EMAIL PROTECTED], [EMAIL PROTECTED], etc.) and that DD should be 
> > able to
> > consult them.
> 
> I was going to suggest DDs being able to read it, exactly like that,
> but I did get a vibe from Bdale and others that even that would be
> too much exposure.
> 
> I'm not sure, someone should elaborate if they disagree.

I think that the internal discussions should be kept private to
the soc-ctte at least as long as no decision is made. As decisions made
by the comitee will probably quite often involve social behaviour of DDs
I think it's problematic if all DDs can read the internal discussions of
the comitee members. I believe that the comitee members should be able
to discussion various options without the fear that something could be
publicized (probably resulting in a flamewar) before even a discussion
in the comitee is made.

After a decision is made I think it's less problematic to make the
discussion available to all DDs. But still there is the problem, that
offending behaviour would be exposed to all DDs. 

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


pgpdbaHclSjkX.pgp
Description: PGP signature

Re: soc-ctte discussion at DebConf7

[Frank Küster]

Josip Rodin <[EMAIL PROTECTED]> wrote:

>> Sure, there is hopefully no problem to find a replacement.  My point was
>> that we should explicitely name those positions who should not be a member
>> of the soc-ctte.
>
> Okay.
>
> Interestingly enough, we don't have similar provisions in the constitution
> (§6.2) for the technical committee. Apparently, the secretary is
> a long-time member :) and at least a couple of leaders were too.

The tech-ctte is supposed to judge on technical grounds and not consider
merit or power.  The soc-ctte will for sure not exclude merit completely
from their considerations, and - by the nature of their task - are
probable to consider power, too.  And maybe that's not even a bad
thing.  I think this shows that the separation is more important here. 

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Josip Rodin]

On Tue, Jun 26, 2007 at 10:48:51AM +0100, MJ Ray wrote:
> I feel we're really missing most sorely list-admin teams who will take
> care of the social fabric of one list each and are empowered to make
> limited short-term changes to preserve it, including updating the list
> info pages and small posting bans.  We should prioritise those sorts
> of bottom-up change over a top-down soc-ctte.

The problem with that is that nobody is proposing any sort of a model
by which these teams would be composed. I personally can't see such a thing
going far, because that would create various rulesets for various lists,
and require involvement of far too many people to be authoritative.

On the other hand, a single social committee provides for a body which will
be by and large neutral towards all lists (it will apply the same reasoning
towards all).

> Existing high-level posts with a social aspect, such as listmasters and
> DAM both, seem reluctant to wield their power, which is understandable
> because they cannot follow every interaction in detail.

That's not really the only reason - another important reason is that the
people by and large never subscribed to the said teams because they wanted
to mediate social issues, but because they wanted to do the technical tasks.

Another reason is that these teams are inherently an oligarchy, and handing
down social decisions in such a setting can easily be seen as evil, so they
steer clear of it.

A separate group of people who don't mind handling the non-technical tasks
will relieve them of these problems.

> soc-ctte will also have the problem of being unfamiliar with the situation
> - how is it going to solve many problems faster? 

Well, *anything* is faster than a technically-inclined listmaster team
whose average time of handling social problems converges to infinity. :)
(Which in itself is acceptable, really.)

> Will its actions also be heavy, as the "big stick" mentioned in its powers
> suggests it could.

The main point, which apparently eluded you :) was that it needs to be able
to have a big stick simply so that it has tangible authority. For some
people, the authority provided by being a regularly elected body might
not be sufficient to make them respect it.

> [...]
> >   * The communication of soc-ctte members with people about their behaviour
> > which might eventually become a matter of committee deliberation should
> > be kept reasonably private, to prevent unnecessary escalation
> 
> What is "reasonably private"?  Please avoid creating a Star Chamber.
> Also, how will we know which soc-ctte members are naughty or nice,
> or whether we should remove members or terminate the ctte?

See in another part of the thread, regarding our archive on master.

> [...]
> > * The establishment and composition of the actual soc-ctte:
> > [...] delegation [...] voted upon [...]
> 
> Was the jury selection model discussed at all?

I don't think it was. Can you explain a bit?

> If it's all voting-derived, how can we assure there will be any
> debian-minority views represented on soc-ctte at any time?

I don't believe we can assure that any better than we assure right now
that a majority doesn't stomp all over a minority... I think it's an
acceptable compromise.

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Josip Rodin]

On Tue, Jun 26, 2007 at 10:44:28AM +0200, Andreas Tille wrote:
> even if I'm not perfectly decided whether it might be just practical
> because I doubt that there will be enough cronies in the group of
> volunteers.

Like with the cabal - it's not a matter of if they will be there, but
a matter of having a general impression formed that they are there.
We don't need any more of that and we should steer clear of such a thing.

(See also another rationale in my previous message in reply to Raphael.)

> >I don't think that all other methods involving nominations and voting are
> >such an unbearable overhead.
> 
> Running several platforms and doing the usual amount of discussion on
> debian-vote might be some extra burden for those people who are interested.

I'm not sure I understand the concerns with all that. Even our existing
leadership nomination procedure is nowhere near as pointless as real-world
campaigning. We just have people summarize their opinions in one document
(platform), and have one public discussion between them. In the last three
years, the number of nominees for that was 8, 7, 6.

The soc-ctte would probably be up to three times as many people (theoretical
maximum, IMO), but likely considerably smaller platforms (because the
candidates run for a position which has a modicum of specificity, so there's
a decent limit on how many matters they will cover in the platform).

> Sure, there is hopefully no problem to find a replacement.  My point was
> that we should explicitely name those positions who should not be a member
> of the soc-ctte.

Okay.

Interestingly enough, we don't have similar provisions in the constitution
(§6.2) for the technical committee. Apparently, the secretary is
a long-time member :) and at least a couple of leaders were too.

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Steve McIntyre]

On Tue, Jun 26, 2007 at 05:19:27PM +0200, Josip Rodin wrote:
>On Tue, Jun 26, 2007 at 09:19:46AM +0200, Raphael Hertzog wrote:
>> >   * The communication of soc-ctte members with people about their
>> > behaviour which might eventually become a matter of committee
>> > deliberation should be kept reasonably private, to prevent
>> > unnecessary escalation
>> 
>> Basicaly, any communication concerning the "proactive" part shall be
>> private. The person receiving the warning can publicize it by themselves
>> if they so desire (but it's certainly not expected to be the general rule,
>> it's just to avoid the criticism of lack of transparency).
>
>One thing that I hadn't had the chance to mention (because other people were
>simply being louder than me ;) was that the "proactivity" still needs to be
>documented in an internal archive of soc-ctte, so that there is a clear
>record of exactly what was done in the name of the committee and when.
>That is - whenever someone takes such a private action, they don't Cc: the
>public mailing list, but they do Cc: the private archiving alias which
>quietly records the event.

Yup. I made a point of mentioning this private archive at the meeting,
but we were quite busy and maybe not everybody heard/remembered it.

>This archive would obviously be useful for the simple purpose of
>backtracking what went on in case someone complains; but at the same time
>it would be a bare-bone teaching tool for new members of soc-ctte.

Yes, absolutely.



>> So we sort of decided that it should:
>> - make ACL decisions concerning the Debian lists (the listmasters clearly
>>   indicated that they don't want to take those by themselves)
>>   This includes the possibility to decide ML bans for DD as well as
>>   for non-DD.
>
>One thing we didn't mention here was any documented limits to these
>decisions. I guess everyone implied that this would be left to the
>discretion of soc-ctte, hoping that they wouldn't do anything drastic.

Yes, that was my understanding.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
We don't need no education.
We don't need no thought control.


signature.asc
Description: Digital signature

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Josip Rodin]

On Tue, Jun 26, 2007 at 09:19:46AM +0200, Raphael Hertzog wrote:
> >   * The communication of soc-ctte members with people about their
> > behaviour which might eventually become a matter of committee
> > deliberation should be kept reasonably private, to prevent
> > unnecessary escalation
> 
> Basicaly, any communication concerning the "proactive" part shall be
> private. The person receiving the warning can publicize it by themselves
> if they so desire (but it's certainly not expected to be the general rule,
> it's just to avoid the criticism of lack of transparency).

One thing that I hadn't had the chance to mention (because other people were
simply being louder than me ;) was that the "proactivity" still needs to be
documented in an internal archive of soc-ctte, so that there is a clear
record of exactly what was done in the name of the committee and when.
That is - whenever someone takes such a private action, they don't Cc: the
public mailing list, but they do Cc: the private archiving alias which
quietly records the event.

This archive would obviously be useful for the simple purpose of
backtracking what went on in case someone complains; but at the same time
it would be a bare-bone teaching tool for new members of soc-ctte.

> The biggest decisions need to be publicly documented however. I don't
> think we've clearly drawn the line here. I'm also unsure if it's important
> to have a clear line here. We can just let the ctte draw the line where
> it's appropriate given that any communication concerning the ctte should
> ideally be archived on master.d.o just like other aliases are archived
> there ([EMAIL PROTECTED], [EMAIL PROTECTED], etc.) and that DD should be able 
> to
> consult them.

I was going to suggest DDs being able to read it, exactly like that,
but I did get a vibe from Bdale and others that even that would be
too much exposure.

I'm not sure, someone should elaborate if they disagree.

> >   * We seemed to agree that soc-ctte should have the ability to make access
> > control decisions in general, as described by Ian, so that while it
> > would be a soft-speaking body, it could also have a big stick to carry
> > while doing so :)
> 
> We also agreed that the formulation was a bit broad. For instance,
> granting "adm" membership (ie DSA team rights) is also an ACL decision,
> but it's certainly not the resort of the social ctte.

Right, but I don't think that someone would actually argue that.
That's simply not a social issue so by default it's not a soc-ctte issue.

> So we sort of decided that it should:
> - make ACL decisions concerning the Debian lists (the listmasters clearly
>   indicated that they don't want to take those by themselves)
>   This includes the possibility to decide ML bans for DD as well as
>   for non-DD.

One thing we didn't mention here was any documented limits to these
decisions. I guess everyone implied that this would be left to the
discretion of soc-ctte, hoping that they wouldn't do anything drastic.

> - make decision concerning DD's behaviour everywhere where they are acting
>   as member/representative of the project (including #debian* IRC channels).

Also non-DDs in such venues, Sam mentioned something like that.
Sponsored maintainers too, I guess.

> > * The establishment and composition of the actual soc-ctte:
> >   * We seemed to agree that a leader's delegation would be a useful tool to
> > bootstrap the soc-ctte and modify it later (even though it's unclear
> > whether the constitutional barrier to leader messing with the delegates
> > would apply), as opposed to the inclusion in the constitution which
> > would delay the process and make it less modifiable later - a proposed
> > compromise solution is that a general resolution vote should be held,
> > one that would make a formal statement establishing soc-ctte, in order
> > to give the idea full-blown credibility
> 
> Which constitutionnal barrier ? The DPL can modify the team but can't
> overrule decisions of the team.

Well, I think that that's inconsistent. The DPL shouldn't be able to
randomly modify ('undelegate') membership in the soc-ctte once they were
confirmed by the developer body using the normal voting procedure.
An analogous voting procedure should be used for such a thing. It doesn't
make much sense to me for one electee(sp?) to be able to randomly screw
around with other electees :)

> >   * Someone proposed that the leader makes the initial list of members which
> > would then be voted upon, not sure; I would maintain my position that
> > people should be nominating themselves, rather than the leader naming
> > them - I don't believe we clarified this point
> 
> We have decided to have 2 GR at the same time. One deciding the creation
> of the soc-ctte and one deciding its membership.

Yes, but it wasn't clear who would compose the ballot for the membership.

> AFAIR, the consensus was that:
> - whenever a soc-c

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[MJ Ray]

Andreas Tille <[EMAIL PROTECTED]> wrote:
> On Tue, 26 Jun 2007, MJ Ray wrote:
> > If it's all voting-derived, how can we assure there will be any
> > debian-minority views represented on soc-ctte at any time?
>
> What exact minority do you have in mind?

No particular one, but including: racial or ethnic origin, religion
or belief, disability, age, sexual alignment and orientation [list
from EC Employment and Social Affairs].

The voting-derived soc-ctte could meet the definition of "indirect
discrimination" by representing only our majorities - "where an
apparently neutral provision is liable to disadvantage a group of
persons." I guess whether that matters depends whether you think it
matters if the debian project discriminates on the above grounds.

Hope that explains,
-- 
MJR, a White Anglo-Saxon ex-Protestant, so not so worried for himself.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[Kalle Kivimaa]

Kevin Mark <[EMAIL PROTECTED]> writes:
> What is the difference between 'a list admin' and 'a small list admin
> team' in this situation?

Nothing, really, I just believe in teams in volunteer work, because
then it's more likely that somebody in the team has the time and the
energy to do what's needed.

> Also, why wouldn't (it be the duty of a DD/it
> be in the interest of a DD) to make such notification to an offending
> individual in private and to CC another officlal (list admin, DPL,
> soc-ctte leader,etc.) so that the official can be alerted and if
> necessary make the suspension or other appropriate action?

Most people have an innate respect for the authority. If a listmaster
mails me saying that my posts to -project are inappropriate because of
X, I'm more likely to believe him than a random developer saying the
same thing. I'm not a social scientist, though, so I cannot say if my
generalization is valid.

And, having DD's do the step one would just mean that the burden for
making decisions falls again on the listmasters, who have said that
they much rather not have that burden (and I agree, they've signed up
for the technical administration, not social). Also, in that case I
agree with MJ's point that it's better if the decisions are made by
somebody who is familiar with the problem, not by somebody who has to
first study it.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7

[Kevin Mark]

On Tue, Jun 26, 2007 at 01:02:53PM +0300, Kalle Kivimaa wrote:
> MJ Ray <[EMAIL PROTECTED]> writes:
> > I feel we're really missing most sorely list-admin teams who will take
> > care of the social fabric of one list each and are empowered to make
> > limited short-term changes to preserve it, including updating the list
> > info pages and small posting bans.  We should prioritise those sorts
> > of bottom-up change over a top-down soc-ctte.
> 
> I agree. Most of the problems with bad social interaction can be
> solved by quick and non-intrusive private intervention from an
> authoritative party. Small list-admin teams would have the following
What is the difference between 'a list admin' and 'a small list admin
team' in this situation? Also, why wouldn't (it be the duty of a DD/it
be in the interest of a DD) to make such notification to an offending
individual in private and to CC another officlal (list admin, DPL,
soc-ctte leader,etc.) so that the official can be alerted and if
necessary make the suspension or other appropriate action?

-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal |mysite.verizon.net/kevin.mark/|
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
|  my keyserver: subkeys.pgp.net | my NPO: cfsg.org |
|join the new debian-community.org to help Debian!  |
|___  Unless I ask to be CCd, assume I am subscribed ___|


pgp0YLEGECh5U.pgp
Description: PGP signature

Re: soc-ctte discussion at DebConf7

[Kalle Kivimaa]

MJ Ray <[EMAIL PROTECTED]> writes:
> I feel we're really missing most sorely list-admin teams who will take
> care of the social fabric of one list each and are empowered to make
> limited short-term changes to preserve it, including updating the list
> info pages and small posting bans.  We should prioritise those sorts
> of bottom-up change over a top-down soc-ctte.

I agree. Most of the problems with bad social interaction can be
solved by quick and non-intrusive private intervention from an
authoritative party. Small list-admin teams would have the following
"powers" at their disposal:

1. Contact the poster in private and tell him (or her, hate this
   English gender specific stuff) why his post was inappropriate and
   ask him to be more careful in the future.

2. If this doesn't work, warn the poster (again in private) that
   persisting in inappropriate behaviour will result in further
   action.

3. If there's still a problem, warn the poster in public.

4. If that didn't help, apply a temporary ban.

5. If there's still a problem, apply a permanent ban with notification
   to the listmasters and the DAM.

In myy experience most problems would be solved in step one, provided
the list-admins are socially adept.

Of course, this only takes care of the mailing lists. It doesn't
address cases like Sven or Ted, where it probably would have helped to
have a permanent ombudsman team.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Andreas Tille]

On Tue, 26 Jun 2007, MJ Ray wrote:


If it's all voting-derived, how can we assure there will be any
debian-minority views represented on soc-ctte at any time?


What exact minority do you have in mind?

Kind regards

 Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[MJ Ray]

Josip Rodin <[EMAIL PROTECTED]> wrote: [...]
> I was happy to note that there wasn't really any discussion as to whether
> there should be such a thing - the implicit consensus was that we do need
> something, it's just that we need to figure out exactly what and how.

Something is needed, but I'm surprised that there's no dissent with
the idea of the high-level soc-ctte being the next body created.

I feel we're really missing most sorely list-admin teams who will take
care of the social fabric of one list each and are empowered to make
limited short-term changes to preserve it, including updating the list
info pages and small posting bans.  We should prioritise those sorts
of bottom-up change over a top-down soc-ctte.

Existing high-level posts with a social aspect, such as listmasters
and DAM both, seem reluctant to wield their power, which is
understandable because they cannot follow every interaction in detail.
When they do act, it seems to be somewhat heavy, because things reach
that level of severity in the necessary delays.  soc-ctte will also
have the problem of being unfamiliar with the situation - how is it
going to solve many problems faster?  Will its actions also be heavy,
as the "big stick" mentioned in its powers suggests it could.

[...]
>   * The communication of soc-ctte members with people about their behaviour
> which might eventually become a matter of committee deliberation should
> be kept reasonably private, to prevent unnecessary escalation

What is "reasonably private"?  Please avoid creating a Star Chamber.
Also, how will we know which soc-ctte members are naughty or nice,
or whether we should remove members or terminate the ctte?

[...]
> * The establishment and composition of the actual soc-ctte:
> [...] delegation [...] voted upon [...]

Was the jury selection model discussed at all?

If it's all voting-derived, how can we assure there will be any
debian-minority views represented on soc-ctte at any time?

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Andreas Tille]

On Tue, 26 Jun 2007, Josip Rodin wrote:


I have an issue with the leader deciding on the composition of the
committee, in general. I think it could easily create the impression
that they are his cronies, and we have to avoid that.


You are right here - I just wanted to enhance the suggestion about a
"leader picked soc-ctte" where I share your concern up to some point -
even if I'm not perfectly decided whether it might be just practical
because I doubt that there will be enough cronies in the group of
volunteers.


I don't think that all other methods involving nominations and voting are
such an unbearable overhead.


Running several platforms and doing the usual amount of discussion on
debian-vote might be some extra burden for those people who are interested.
It might finally lead to a soc-ctte that is nearly the same as a leader
picked one.  The advantage might be the "prove of legitimation" which
is definitely a plus but it draws time from several people.  I think before
we decide about whether we should elect or not we might beforehand verify
whether we have really a large number of volunteers to elect from or
if the number of volunteers might fit the (not yet decided number of
commity members).


I think that there's plenty of people in Debian for us to have different
people in different positions at all times :) 7/1000 or 15/1000 is tiny.


Sure, there is hopefully no problem to find a replacement.  My point was
that we should explicitely name those positions who should not be a member
of the soc-ctte.  On the other hand - sometimes iot is hard to get a
certain number of people who are able and willing to do real work.  Ask
for instance the DebConf orga team whether they are flooded by volunteers
to help. :)


Obviously, yes. But even then, the people outside might not see things
the same way as the other members of the committee, and they have to have
a method of voicing this opinion other than a rowdy flamewar on the
mailing list or a GR explicitly condemning some member. That's just ugly.


Yes.

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Josip Rodin]

On Tue, Jun 26, 2007 at 09:15:25AM +0200, Andreas Tille wrote:
> > * Someone proposed that the leader makes the initial list of members which
> >   would then be voted upon, not sure; I would maintain my position that
> >   people should be nominating themselves, rather than the leader naming
> >   them - I don't believe we clarified this point
> 
> I don't know who did this proposal but letting the leader pick the soc-ctte
> people out of a number of people that explicitely volunteered to work in the
> soc-ctte (it makes no sense to pick people that do not volunteer to do some
> work) might be a resonable alternative.

I have an issue with the leader deciding on the composition of the
committee, in general. I think it could easily create the impression
that they are his cronies, and we have to avoid that.

I don't think that all other methods involving nominations and voting are
such an unbearable overhead.

> BTW, we did not discuss whether certain positions should exclude that a
> person is a member of the soc-ctte at the same time.  For instance I'm
> unsure whether the leader should be a member at the same time which might
> perfectly happen under some circumstances if we decide that soc-ctte stays
> for two years stable and one of its members is successfully running for DPL.

I think that there's plenty of people in Debian for us to have different
people in different positions at all times :) 7/1000 or 15/1000 is tiny.

> >   The opposition to the idea of not having any vetting of candidates was
> >   that there would be no accountability, no way to remove people who are
> >   perceived to be bad, or inactive.
> >   Proposal to address this was to have yearly approval voting of soc-ctte
> >   members, whereby the developers would be able to tick off a particular
> >   member and remove them that way.
> 
> For these case I'd alternatively suggest kind of a soc-ctte internal voting
> mechanism to sort out those who shouldn't be a member for whatever reason
> quickly.

Obviously, yes. But even then, the people outside might not see things
the same way as the other members of the committee, and they have to have
a method of voicing this opinion other than a rowdy flamewar on the
mailing list or a GR explicitly condemning some member. That's just ugly.

> >   It wasn't particularly clear what would be done after that (mostly by
> >   time constraints during the discussion...); how much non-approval
> >   would the members have to get in order to get removed; whether the
> >   removed members would have to be replaced, when and how would the
> >   replacement be done (appointment by leader? and then voting?). It was
> >   also proposed that only one half of the committee members go up for
> >   this kind of an approval vote each year.
> 
> The reason was that we need some kind of stability.  IMHO we do not have
> such a high frequency of "soc-ctte business cases" (furtunately) that
> members have a chance to gather some experience in this business.

Oh, and I should mention that people seemed to be a bit unaware of
the fact that I had two years set for elections, rather than one,
which is another method to have more stability. Especially if combined
with that half-half rule Andreas mentioned.

(In general, I got the distinct impression that many people couldn't be
bothered to read long threads followed by diffs to the constitution.
Can't blame them, really :)

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Raphael Hertzog]

Hi,

(you could have started a new thread :-))

On Tue, 26 Jun 2007, Josip Rodin wrote:
>   * The initial social committee will have to combine two aspects - one is
> the need to have a body that would judge on disputes (this would be the
> committee as such), and the other is the need to have people who can
> communicate with some authority in order to resolve social matters
> (this would be a 'social team' or something)

Those 2 aspects were:
1/ taking decisions on request of DD who are experiencing/witnessing a social 
problem
2/ being proactive on social behaviour (inform early when people misbehave
on lists, so that they have a chance to correct in order to avoid resorting to 
more
dramatic decisions later)

>   * The communication of soc-ctte members with people about their behaviour
> which might eventually become a matter of committee deliberation should
> be kept reasonably private, to prevent unnecessary escalation

Basicaly, any communication concerning the "proactive" part shall be
private. The person receiving the warning can publicize it by themselves
if they so desire (but it's certainly not expected to be the general rule,
it's just to avoid the criticism of lack of transparency).

The biggest decisions need to be publicly documented however. I don't
think we've clearly drawn the line here. I'm also unsure if it's important
to have a clear line here. We can just let the ctte draw the line where
it's appropriate given that any communication concerning the ctte should
ideally be archived on master.d.o just like other aliases are archived
there ([EMAIL PROTECTED], [EMAIL PROTECTED], etc.) and that DD should be able to
consult them.

> * The extent of soc-ctte powers:
>   * We seemed to agree that soc-ctte should have the ability to make access
> control decisions in general, as described by Ian, so that while it
> would be a soft-speaking body, it could also have a big stick to carry
> while doing so :)

We also agreed that the formulation was a bit broad. For instance,
granting "adm" membership (ie DSA team rights) is also an ACL decision,
but it's certainly not the resort of the social ctte.

So we sort of decided that it should:
- make ACL decisions concerning the Debian lists (the listmasters clearly
  indicated that they don't want to take those by themselves)
  This includes the possibility to decide ML bans for DD as well as
  for non-DD.
- make decision concerning DD's behaviour everywhere where they are acting
  as member/representative of the project (including #debian* IRC channels).
- make recommandation to any other party that defers a judgment to the
  social ctte (example: the OFTC admin defers a dispute on the
  soc-ctte over ownership of a channel #debian*)

Since it's a "delegated body", the DPL can grant additionals powers if
needed.

>   * The phrasing of the access control power should be subtle enough to
> avoid the pitfall of people complaining to the soc-ctte regarding
> political decisions such as who has commit access to a VCS repository,
> because there the distinction between 'political', 'technical' and
> 'social' can be blurry, which might cause problems, and nobody really
> had an answer for that

The answer was the above IIRC.

> * The establishment and composition of the actual soc-ctte:
>   * We seemed to agree that a leader's delegation would be a useful tool to
> bootstrap the soc-ctte and modify it later (even though it's unclear
> whether the constitutional barrier to leader messing with the delegates
> would apply), as opposed to the inclusion in the constitution which
> would delay the process and make it less modifiable later - a proposed
> compromise solution is that a general resolution vote should be held,
> one that would make a formal statement establishing soc-ctte, in order
> to give the idea full-blown credibility

Which constitutionnal barrier ? The DPL can modify the team but can't
overrule decisions of the team.

>   * Someone proposed that the leader makes the initial list of members which
> would then be voted upon, not sure; I would maintain my position that
> people should be nominating themselves, rather than the leader naming
> them - I don't believe we clarified this point

We have decided to have 2 GR at the same time. One deciding the creation
of the soc-ctte and one deciding its membership.

>   * The consensus on later changes to the committee was that it should not
> be done often in general, though we did disagree somewhat regarding the
> method of accomplishing that goal. I had previously proposed that normal
> elections be held every two years; Ian had previously proposed that the
> initial soc-ctte varies its own size and membership.

AFAIR, the consensus was that:
- whenever a soc-ctte member steps down (or is recalled due to the
  reapproval vote), the DPL appoints a new member
  (unless he decided to vary the size

Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Andreas Tille]

On Tue, 26 Jun 2007, Josip Rodin wrote:


Ian said he'll send over his notes, but I'm impatient so I'll have a go :)


Thanks for your impatience. :)


The issues that were touched included:


I found quite similar things in my private log - hoping to review the
recording later to sort out missing ideas.  I'll try to  comment only
on these points which might have taken not completely into account because
of the time limit.


 * Someone proposed that the leader makes the initial list of members which
   would then be voted upon, not sure; I would maintain my position that
   people should be nominating themselves, rather than the leader naming
   them - I don't believe we clarified this point


I don't know who did this proposal but letting the leader pick the soc-ctte
people out of a number of people that explicitely volunteered to work in the
soc-ctte (it makes no sense to pick people that do not volunteer to do some
work) might be a resonable alternative.

BTW, we did not discuss whether certain positions should exclude that a
person is a member of the soc-ctte at the same time.  For instance I'm
unsure whether the leader should be a member at the same time which might
perfectly happen under some circumstances if we decide that soc-ctte stays
for two years stable and one of its members is successfully running for DPL.


   The opposition to the idea of not having any vetting of candidates was
   that there would be no accountability, no way to remove people who are
   perceived to be bad, or inactive.
   Proposal to address this was to have yearly approval voting of soc-ctte
   members, whereby the developers would be able to tick off a particular
   member and remove them that way.


For these case I'd alternatively suggest kind of a soc-ctte internal voting
mechanism to sort out those who shouldn't be a member for whatever reason
quickly.


   It wasn't particularly clear what would
   be done after that (mostly by time constraints during the
   discussion...); how much non-approval would the members have to get in
   order to get removed; whether the removed members would have to be
   replaced, when and how would the replacement be done (appointment by
   leader? and then voting?). It was also proposed that only one half of
   the committee members go up for this kind of an approval vote each year.


The reason was that we need some kind of stability.  IMHO we do not have
such a high frequency of "soc-ctte business cases" (furtunately) that
members have a chance to gather some experience in this business.

Thanks for your summary

  Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

soc-ctte discussion at DebConf7 [was Re: Social committee proposal]

[Josip Rodin]

On Fri, Jun 08, 2007 at 10:42:52PM +0200, Josip Rodin wrote:
> > Well, I don't think it is the best idea to discuss those issues
> > via mail.  I just hope that many people will join
> > 
> > https://penta.debconf.org/~joerg/events/93.en.html
> > 
> > which I registered for an open discussion about this topic.
> 
> I don't see why f2f discussion about this is necessarily better than
> a list discussion. We want to find a way to get along better in list
> discussions, but the way of finding that isn't via list discussions...
> you see where that is going :)

So, anyway, the discussion was had :) it was moved from the afternoon to
the morning, and not many people joined until later in the term, but still,
in the end it was a decent turnout, could be two dozen people.

Ian said he'll send over his notes, but I'm impatient so I'll have a go :)

I was happy to note that there wasn't really any discussion as to whether
there should be such a thing - the implicit consensus was that we do need
something, it's just that we need to figure out exactly what and how.

Sadly, the discussion ended somewhat prematurely, as there was something
else scheduled immediately afterwards in the same room, so we had to wrap
it up before everything was hashed out.

The issues that were touched included:

* The scope and jurisdiction of soc-ctte:
  * We seemed to come to a consensus that soc-ctte and tech-ctte should not
be placed in a position where one is subordinate to the other, rather
jurisdictional disputes should be resolved by the leader
  * Jurisdictional disputes should not be allowed to continue ad nauseam,
and the committees should not defer to each other to prevent any sort
of a ping-pong
  * In case a complainant disagrees with the leader's decision on the
jurisdiction of the dispute, the method of resolution (escalation)
is a General Resolution vote
  * The soc-ctte should not be used as any sort of a vehicle for other
possibly desired changes in Debian governance in general (things that
were discussed in several other panels at DebConf7), and that it should
be a solution only to the social matters, which are a sufficiently huge
and blurry area on their own :)
  * The initial social committee will have to combine two aspects - one is
the need to have a body that would judge on disputes (this would be the
committee as such), and the other is the need to have people who can
communicate with some authority in order to resolve social matters
(this would be a 'social team' or something)
  * The communication of soc-ctte members with people about their behaviour
which might eventually become a matter of committee deliberation should
be kept reasonably private, to prevent unnecessary escalation
* The extent of soc-ctte powers:
  * We seemed to agree that soc-ctte should have the ability to make access
control decisions in general, as described by Ian, so that while it
would be a soft-speaking body, it could also have a big stick to carry
while doing so :)
  * The phrasing of the access control power should be subtle enough to
avoid the pitfall of people complaining to the soc-ctte regarding
political decisions such as who has commit access to a VCS repository,
because there the distinction between 'political', 'technical' and
'social' can be blurry, which might cause problems, and nobody really
had an answer for that
  * soc-ctte should be authorised to discuss matters such as the expelling
of a developer for anti-social behaviour or such, and be able to make
an official recommendation to the same effect to the account managers
(but this would not be a final decision, it would be overridable by
DAM/DPL/whoever)
* The establishment and composition of the actual soc-ctte:
  * We seemed to agree that a leader's delegation would be a useful tool to
bootstrap the soc-ctte and modify it later (even though it's unclear
whether the constitutional barrier to leader messing with the delegates
would apply), as opposed to the inclusion in the constitution which
would delay the process and make it less modifiable later - a proposed
compromise solution is that a general resolution vote should be held,
one that would make a formal statement establishing soc-ctte, in order
to give the idea full-blown credibility
  * The consensus was that the members of the initial soc-ctte all should
be voted upon, possibly together with the vote on the establishment,
depending on the secretary - Manoj, please feel free to interject here :)
  * Someone proposed that the leader makes the initial list of members which
would then be voted upon, not sure; I would maintain my position that
people should be nominating themselves, rather than the leader naming
them - I don't believe we clarified this point
  * The consensus on later changes to the committee was that it should not
be done often in g