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 [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]

Fwd: Social committee proposal: mediation or repression ?

[Robert Millan]

On Thu, Jun 28, 2007 at 08:03:09AM +0200, [EMAIL PROTECTED] wrote:
> On Thu, Jun 28, 2007 at 07:32:15AM +0200, Josip Rodin wrote:
> > 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.
> 
> In all the discussion i have seen about the social comittee, which i
> have, as you can imagine, followed with interest, there is something
> that disturbs me most.
> 
> All the  talks have been about how to elect members, and giving the SoC
> individual members the power to quickly take action (suposedly by
> warning or temporarily banning folk from lists).
> 
> This is indeed also how most DDs have seen the problem i was involved
> with over the last year, and some remarks, particularly those of Anthony
> Town about "definitive measures that cannot be contested" are indeed
> very disturbing.
> 
> Now, if your governement would be proposing a proposal like what is
> currently being proposed, many of you would be off screaming about
> police state and repression before prevention, not to mention attacks on
> freedom of speach over the censorship powers which have nothing to envy
> to the russian governement closing up news agencies or even repression
> and censorship from darker times.
> 
> I understand that most of us DDs don't really have much political
> conciousness, or most probably don't want to see their own dealings as
> being politically dubious, but this is indeed a very very disturbing
> path to walk.
> 
> In order to solve social dispute, the first step should always be
> mediation, and no, mediation is not trying to talk to the party you
> already judged guilty in order to make him be silent, and if this fails
> pass out punishement and unilateral judgements.
> 
> The first order of business in a social dispute is communication and
> negotiation. If a complaints arise, then the social comittee should
> investigate it, speak with both parties involved in the dispute, verify
> the veracity of those claims with facts and independent third parties,
> and try to discuss.
> 
> Hearing both parties is important, understanding what their grief are,
> and trying to find a middle ground acceptable to both. And only if this
> really fails, should action be taken. 
> 
> Furthermore, the social committee needs to be impartial, which i know
> can be difficult, and hiding their discussions in private channels is
> not going to help there, and brings again up the ghost of shady dealings
> and cabal decision.
> 
> So, what i believe is important in this, is for the social committee to
> have a clear mandate to negotiate and mediate first, before using
> repressive means, and maybe for each social committee member to take an
> oath of impartiality, fairness and will to solve issues in negotiation and
> mediation, just like real world judges do.
> 
> This is the only way to bring debian back again on the way to fun and
> friendliness, and the way to a police state that ian is proposing,
> altough nearer to the habits of DDs, is definitively not the way to go.
> 
> Friendly,
> 
> Sven Luther
> 

-- 
Robert Millan

My spam trap is [EMAIL PROTECTED]  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.


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

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

Re: Social committee proposal

[Manoj Srivastava]

On Fri, 8 Jun 2007 09:11:42 +0200 (CEST), Andreas Tille <[EMAIL PROTECTED]> 
said: 

> On Thu, 7 Jun 2007, Andreas Barth wrote:

>> every years for a two years time (and doing the elections at the same
>> time as the DPL)?

> I think only voting in he same ballot will find wide acceptance
> amongst the DDs (provided that devotee is able to process to different
> ballots in one mail).

Sorry, no, not as currently implemented.  Two different ballots
 for different votes currently need to go to different addresses.

manoj
-- 
Convention is the ruler of all. Pindar
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: Social committee proposal

[Josip Rodin]

On Fri, Jun 08, 2007 at 01:07:54PM +0200, Andreas Tille 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 :)

-- 
 2. That which causes joy or happiness.


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

Re: Social committee proposal

[Andreas Tille]

On Fri, 8 Jun 2007, Andreas Barth wrote:


Eh, why don't do it in the discussion about Debian governance?


You know the principle: we need Gnome AND KDE, Emacs AND Vim, ... ;-)
Or rather: It was kind of hard to find out which events were
submitted when there was time for submissions.  So well, I
think we should make the best of it and should focus on the
event which is first in time (damn, you beat me ;-) according
to https://penta.debconf.org/~joerg/events/59.en.html ).  Then
lets see whether we were able to solve all our problems in
this event.  If so we should just party on the second - if
not we might perhaps use this slot to discuss new knowledge
that we might have gained at DebConf.

I'm happy that I was not the only one who tried to apply for
such a session which is IMHO quite important.

See you in Edinburgh

 Andreas.

--
http://fam-tille.de


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

Re: Social committee proposal

[Andreas Barth]

* Andreas Tille ([EMAIL PROTECTED]) [070608 13:08]:
> On Fri, 8 Jun 2007, Andreas Barth wrote:
> 
> >I don't get the problem. We have two sets of people there in:
> >- people elected in even years
> >- people elected in uneven years
> 
> 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.

Eh, why don't do it in the discussion about Debian governance?


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


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

Re: Social committee proposal

[Andreas Tille]

On Fri, 8 Jun 2007, Andreas Barth wrote:


I don't get the problem. We have two sets of people there in:
- people elected in even years
- people elected in uneven years


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.

BTW, I would be happy if some interested people would
join before ths panel discussion to prepare this discussion.

Kind regards

Andreas.

--
http://fam-tille.de


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

Re: Social committee proposal

[Andreas Barth]

* Andreas Tille ([EMAIL PROTECTED]) [070608 09:12]:
> On Thu, 7 Jun 2007, Andreas Barth wrote:
> 
> >I think it would be better if the committee is re-elected from the
> >developers at large - perhaps half of their size
> 
> I see no chance to define half of their size precisely.  It immediately
> opens a lot of question.  One of these questions is "Which half?".
> So either re-electing all or nobody is an option.

I don't get the problem. We have two sets of people there in:
- people elected in even years
- people elected in uneven years


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


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

Re: Social committee proposal

[Andreas Tille]

On Thu, 7 Jun 2007, Andreas Barth wrote:


I think it would be better if the committee is re-elected from the
developers at large - perhaps half of their size


I see no chance to define half of their size precisely.  It immediately
opens a lot of question.  One of these questions is "Which half?".
So either re-electing all or nobody is an option.


every years for a two
years time (and doing the elections at the same time as the DPL)?


I think only voting in he same ballot will find wide acceptance amongst
the DDs (provided that devotee is able to process to different ballots
in one mail).

BTW, I think the leader should not be a member of the soc-ctte.
So in case a member of the soc-ctte is elected as leader somebody
else has to step in.  For simplification of voting process I think
the next highest ranked for the soc-ctte should become a member
instead somebody who won the leader election.

While I'm not convinced that the soc-ctte has really to be
reelected on a regular basis (read: I'm undecided between Ian's
and Josip's proposal concerning this point) we would have to
find a method to substitute a soc-ctte member that might have
become leader in any other way if we do no regular elections.

Kind regards

  Andreas.

--
http://fam-tille.de


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

Re: Social committee proposal

[Andreas Barth]

* Ian Jackson ([EMAIL PROTECTED]) [070601 11:59]:
>  7. The initial Social Committee will consist of of five elected
> Developers.  The Project Secretary is requested to organise and
> hold an election, in a manner similar to that for Project Leader.
> 
>  8. The Committee shall be responsible for appointing new members,
> removing existing members, and varying its size, as and when it
> sees fit.

I think it would be better if the committee is re-elected from the
developers at large - perhaps half of their size every years for a two
years time (and doing the elections at the same time as the DPL)?


Cheers,
Andi


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

Re: Social committee proposal

[Stefano Zacchiroli]

On Fri, Jun 01, 2007 at 10:39:53AM +0100, Ian Jackson wrote:
> So let me make a concrete proposal for a DPL delegation which I hope
> will be adapted and adopted by Sam.

As a general comment I like the idea of having such a committee and
welcome your proposal.

To the details ...

> (5) Decide Its Own Procedure
> 
>   Provided the decisions are consistent with the above, and
>   provided that the Project Leader does not object, the Social
>   Committe may decide on:
> (a) its own size,
> (b) its own composition and manner of appointment,
> (c) its own procedures for for decisionmaking, including
> (d) how many of its members are required to agree on
> which kinds of decisions, including
> (e) whether to initially assign and empower a single committee
> member to deal with each enquiry, and of course
> (f) any appeals procedure(s) short of overturn via General
> Resolution, and finally
> (g) any similar matters regarding its own operation.

I think we should mention here as an additional point "how to deal with
conflict of interests", in case that one of the members of the committee
is involved in a matter to be decided upon. Don't know if the TC has
faced similar issues, but I think here is compelling.

Cheers.

-- 
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: Social Committee proposal text (diff), updated

[Kalle Kivimaa]

Josip Rodin <[EMAIL PROTECTED]> writes:
> I see little to support the notion of a) preemptive action b) private
> interventions being something the community would instantly start preferring.

Maybe it should. In social disagreements the fastest way to resolve
problems is if the problem is privately resolved before it gets out of
hand. Let's face it, all of us want to save face in public, and if
we're given a public reprimand that hurts. If a delegate contacts us
privately and discusses our behaviour, we're much more likely to
accept the issues and try to modify them.

-- 
* 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: Social Committee proposal text (diff), updated

[Josip Rodin]

On Tue, Jun 05, 2007 at 07:38:24PM +0100, Ian Jackson wrote:
>  * Josip models the SC's powers on those of the TC.  This is wholly
>inappropriate because the questions that the SC is required to deal
>with are very different.

I guess it doesn't make sense to argue much about this, but I have to point
out that that's tech-ctte is the best example we've got so far. Maybe it's
not perfect, but it's a start. The social committee shouldn't start off
being particularly radical.

>  * Josip's text emphasises the SC's role as a writer of policies.
>We do not need policies, we need admonishment and if necessary
>enforcement of good conduct.

Uhh, I am not sure where you got that. Did you miss the part that said:

+No detailed mediation or policy-making.
+
+The Social Committee does not engage in design of new
+proposals and policies.  Such design work should be carried out
+by individuals discussing in ordinary social forums.

Like you said yourself, this is modelled after tech-ctte.

>  * Josip's text depends heavily on the meaning of the word `social'
>which I think is vague to the point of uselessness and will
>lead to jurisdictional disputes.

Jurisdictional disputes between whom? And, given my proposed rules for
deference, exactly how bad can they be? At least if we get to see such
a dispute, then we can resolve it and clarify the vague terms.
Right now we have... nothing.

> The answer is obvious: we want the SC to impose mailing list bans (and
> IRC bans and wiki bans and so forth).  That single power is enough to
> do everything that is lacking, because together with the threat and
> expectation of its exercise, the SC can enforce good behaviour.

There's a subtle point we're glossing over here - we don't need a body
whose ultimate purpose would be to enforce good behaviour. Enforcing good
behaviour, once "good behaviour" is defined, is not a particularly
contentious idea, it's something we can leave that task to the teams that
administer services (public forums in this case). We need a body which
considers arguments and decides which nuances of behaviour are acceptable.
Or it *doesn't* decide on some nuances. The social committee has to assist
in building a consensus, because too much strict delineation doesn't
necessarily do much to help the society. It shouldn't be a priori limited
in scope (to mere production of decisions and their enforcement).

> For these reasons, the powers and processes adopted by the SC and
> those adopted by the TC ought to be very different.  The SC should be
> able to intervene in a public conversation even if neither participant
> is upset - because the SC is supposed to be keeping the venues useable
> for everyone.  The SC should usually be able to act informally, and it
> should normally do so privately and quietly.

I see little to support the notion of a) preemptive action b) private
interventions being something the community would instantly start preferring.

We can't go from public flamewars to private pats on the back.
I doubt that this would have worked ten years ago, let alone today.

> Now, onto the question of policy.  Josip's draft suggests that the SC
> should be in charge of writing social policies and seems to me to read
> as if that is going to be a primary activity of the SC.

Again with this suggestion... how did you get to that conclusion, and at
the same time point out that it's a search&replace on tech-ctte text? :)

> We don't need a definition of arseholeness.

Oh, yes we do. There isn't a single definition of arseholeness that all one
thousand developers will agree upon. (There is barely a single definition
of *anything* that covers all 1k developers, and more in the future.)

> The problem of argumenents in the TC about whether something is
> `technical' or not is already bad enough (although this is partly
> because we don't have a way not to have the rudeness arguments come to
> the TC).  But at least `technical' actually means something.  It will
> be impossible to agree what `social' means.

I can't say I see a notable difference in vagueness between the adjectives
'technical' and 'social'. In our context, the former refers to applied
sciences, and the latter refers to the association of humans. Both of these
are fairly general ideas.

-- 
 2. That which causes joy or happiness.


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

Re: Social committee proposal

[Andreas Tille]

On Tue, 5 Jun 2007, MJ Ray wrote:


If the developers elected the five, how could they be fired without a
big shift of opinion?


I'm personally more concerned how to find these five people in the
first place before I think about how I could get rid of them.

Perhaps I'm to naive

  Andreas.

--
http://fam-tille.de


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

Re: Social Committee proposal text (diff), updated

[Ian Jackson]

Josip Rodin writes ("Social Committee proposal text (diff), updated"):
> [stuff]

Josip's proposal is radically different from mine in two orthogonal
ways.  The first one, which we have been arguing about a bit so far,
is that he proposes that we establish the SC as a constitutional body.

However, there is another perhaps even more important class of
differences: his proposed SC's powers and processes are completely
different from mine.

The main differences, with which I strongly disagree, are:

 * Josip models the SC's powers on those of the TC.  This is wholly
   inappropriate because the questions that the SC is required to deal
   with are very different.

 * Josip models the SC's procedures on those of the TC.  Again, this
   is not appropriate.

 * Josip's text emphasises the SC's role as a writer of policies.
   We do not need policies, we need admonishment and if necessary
   enforcement of good conduct.

 * Josip's text depends heavily on the meaning of the word `social'
   which I think is vague to the point of uselessness and will
   lead to jurisdictional disputes.


The most important question is: what should the SC to ultimately _do_ ?
What the TC ultimately does is authorise an NMU, if a maintainer won't
cooperate, or even to decree a new maintainer.  If the SC gives advice
and is ignored, what _power_ should it have ?

The answer is obvious: we want the SC to impose mailing list bans (and
IRC bans and wiki bans and so forth).  That single power is enough to
do everything that is lacking, because together with the threat and
expectation of its exercise, the SC can enforce good behaviour.  At
the moment the DPL and the mailing list admins have that power but
usually decline to exercise it (because they have other fish to fry).
The power to ban (temporarily or permanently) is what should be
spelled out in the SC's charter.


The next most obvious thing I wanted is to demolish the analogy
between the TC and the SC.  The job of the TC and that of the proposed
SC are quite different.

Technical disagreements are objective and can be clearly explained.
It is often possible for people to retain clear respect for each other
even as they disagree vigorously on some technical matter.  Bringing a
matter to the TC is much less of an accusation of wrongdoing: even
bright, reasonable and well-informed people may discuss a matter and
find themselves at ultimately odds over how something shoudl be done;
if the question is nontrivial then they might each amicably agree to
bring it to the TC.  If you `lose' during a TC arbitration that
doesn't necessarily imply that you did anything wrong.  On-topic
discussions of technical questions are productive and useful, and a
narrow field of contributors to such a question is harmful.  Part of
the purpose of Debian is to allow such conversations to flower.
Developers should not feel inhibited about disagreeing with each other
in public on a technical level.  It is universally acknolwedged that
voting on technical questions is a bad way of making decisions and
also widely believed that popularity of a developer is not a good
guide to technical excellence.

`Social' disagreements are quite different.  They are subjective and
sometimes difficult to explain.  Normal and reasonable people should
generally be able to get along without the intervention of the SC; so
the intervention of the SC (whether necessarily requested or not) is
always a rebuke, if the SC decides against you.  Vigorous and strong
disagreement about matters of appropriate behaviour usually lead to
strong negative opinions on both sides.  Public discussions of
disagreements about standards of conduct are nearly always fruitless
if at all extended.  Debian's purposes do not include experimentation
with and development of standards of behaviour.  Widening the
participation in a dispute about conduct normally generates heat
rather than light.  Voting on a matter of appropriate conduct is a
reasonable way forward (if overly heavyweight and overly public way)
and a popularity contest is a good way to select an arbiter of good
manners.

For these reasons, the powers and processes adopted by the SC and
those adopted by the TC ought to be very different.  The SC should be
able to intervene in a public conversation even if neither participant
is upset - because the SC is supposed to be keeping the venues useable
for everyone.  The SC should usually be able to act informally, and it
should normally do so privately and quietly.


Now, onto the question of policy.  Josip's draft suggests that the SC
should be in charge of writing social policies and seems to me to read
as if that is going to be a primary activity of the SC.

But that's not what's needed.  We don't need a policy, we need
enforcement of civilised norms of behaviour.

We don't need a definition of arseholeness.  What we need is someone
who 

Re: Social committee proposal

[MJ Ray]

Andreas Tille <[EMAIL PROTECTED]> wrote:
> On Sun, 3 Jun 2007, MJ Ray wrote:
> > I feel that this would probably entrench any majority views,
> > particularly with only five members.  Replace with:
> >
> > 7. The initial Social Committee will consist of eleven Developers
> > drawn by random selection from all Developers.
>
> Are there any statistics from which number of members on a
> commitee stops working effectively? [...]
> Chances are good that at least half of the members is either
> not interested or MIA.

I suspect it's difficult to gather many general statistics, because
the size of uselessness will vary with the personalities of the
members and how likely they are to disagree.  I've seen hundreds of
people be an effective meeting, with dozens of them speaking in turn
and AFAICT everyone who wanted to put their questions could, but that
was a group with strong common aims and fairly relaxed social
attitudes.

The number of *active* members is what will make most difference, not
just the number of members, so the size is going to be larger than one
would guess.  Charities are better-documented than many groups and
it's easy to find info like:

  "The average size of boards increases with organisation size, going
   from under 9 in the smallest charities, up to almost 21 for the
   largest."

Source: summary of research by Chris Cornforth at Open University
Business School in 'Recent Trends in Charity Governance and
Trusteeship' published May 2001 by National Council for Voluntary
Organisations, ISBN 0719915910, seen at
http://www.volresource.org.uk/briefing/govern.htm#picture

> > 8. Should any appointed Developer be unwilling to serve, unwilling to
> > serve any longer, or fail to answer three requests from the Project
> > Leader within a month without warning, they will be replaced by
> > another Developer drawn in the same manner.
>
> I wonder how long it will take to finally get a working committee
> by using this procedure.

Me too, but I feel it's more important to get a broad, tolerant
cross-section than to make the decision-making artificially quick by
limiting to five elected politicians.  The project has tolerated
deteriorating behaviour without effective sanctions for years, so is
taking a few months to get a better social-committee a big problem?

Anyway, random selection works for juries.

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: Social committee proposal

[MJ Ray]

Ian Jackson <[EMAIL PROTECTED]> wrote:
> MJ Ray writes ("Re: Social committee proposal"):
> > I feel that this would probably entrench any majority views,
> > particularly with only five members.  Replace with:
>
> Do you mean entrench the views about reasonable behaviour held by the
> majority of Developers ?  The whole purpose of this exercise is to
> give effect to the views about reasonable behaviour held by the
> majority of Developers.

I do not share the above-implied faith that the majority of Developers
would respect reasonable socail behaviours when they are practised by
certain identifiable minorities.  The debian project seems to be
socially dysfunctional in several ways and handing an elected gang of
five this responsibility is dangerous and unnecessary.  I respect the
technical judgement of Developers, but we have clearly not been
selected for social skills for years (maybe this is another problem
with the exam-style NM) and that won't change overnight.

> It's not entrenched because the DPL and/or the Developers can fire the
> committee or individual members at will.

A good DPL maybe could save it, but that would be a very active DPL
and would they be following consensus?

If the developers elected the five, how could they be fired without a
big shift of opinion?

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]

Social Committee proposal text (diff), updated

[Josip Rodin]

Hi,

I went back and examined the thread that started with
Message-ID: <[EMAIL PROTECTED]> in February, and
came up with the following diff at the Constitution.

The changes from the last version include:
* replaced the somewhat confusing 'day-to-day' reference
* added section 'Intervene in communication processes in matters of common
  interest.', summing up Ian's recent proposal, but genericized, and
  linked (warning must precede action), with the primary example
* noted joint technical+social disputes in relation to tech-ctte and leader
* added example for lending authority
* added example for overriding a developer
* limited nomination period repetition
* postponed publicizing votes
* clarified that there is a list of winners, removed confusing NOTA
  requirement (it was in the wrong section)
* allowed the list to be smaller than sqrt(N)/2
* limited senior criterion, both relative and absolute
* slightly reduced the senior quota
* described multiple winners procedure in the Standard Resolution Procedure,
  with the handling of multiple winners being inclusive

The diff is attached (for the benefit of those like me who have syntax
highlighting :).

-- 
 2. That which causes joy or happiness.
--- constitution.wml	2007-02-12 01:49:13.0 +0100
+++ constitution+soc-ctte.wml	2007-06-05 01:08:50.0 +0200
@@ -34,6 +34,8 @@
 
   The Technical Committee and/or its Chairman;
 
+  The Social Committee and/or its Chairman;
+
   The individual Developer working on a particular task;
 
   Delegates appointed by the Project Leader for specific
@@ -64,7 +66,8 @@
 
   
 A person may hold several posts, except that the Project Leader,
-Project Secretary and the Chairman of the Technical Committee must
+Project Secretary, the Chairman of the Technical Committee
+and the Chairman of the Social Committee must
 be distinct, and that the Leader cannot appoint themselves as their
 own Delegate.
   
@@ -142,6 +145,11 @@
 Committee, provided they agree with a 2:1 majority.
   
 
+  
+Make or override any decision authorised by the powers of the
+Social Committee.
+  
+
   
 Issue, supersede and withdraw nontechnical policy documents and
statements.
@@ -193,7 +201,8 @@
 
 
   If the Project Leader or their Delegate, or the Technical
-  Committee, has made a decision, then Developers can override them
+  Committee, or the Social Committee, has made a decision,
+  then Developers can override them
   by passing a resolution to do so; see §4.1(3).
 
   If such a resolution is sponsored by at least 2K Developers,
@@ -203,7 +212,8 @@
 
   If the original decision was to change a discussion period or
   a voting period, or the resolution is to override the Technical
-  Committee, then only K Developers need to sponsor the resolution
+  Committee, or the resolution is to override the Social Committee,
+  then only K Developers need to sponsor the resolution
   to be able to put the decision immediately on hold.
 
   If the decision is put on hold, an immediate vote is held to
@@ -263,11 +273,11 @@
 
   
 Appoint Delegates or delegate decisions to the Technical
-Committee.
+Committee, or delegate decisions to the Social Committee.
 
 The Leader may define an area of ongoing responsibility or a
-specific decision and hand it over to another Developer or to the
-Technical Committee.
+specific decision and hand it over to another Developer, or to the
+Technical Committee, or to the Social Committee.
 
 Once a particular decision has been delegated and made the
 Project Leader may not withdraw that delegation; however, they may
@@ -737,6 +747,246 @@
 that includes the commitments those organisations have made as
 to how those assets will be handled.
 
+10. Social committee
+
+10.1. Powers
+
+The Social Committee may:
+
+
+  
+Decide on any matter of social policy.
+
+This includes social norms and customs, non-technical communication
+among developers, and general matters of organization within the Project.
+
+  
+
+  
+Decide any social issue where Developers' jurisdictions
+overlap.
+
+In cases where Developers need to implement compatible
+social policies or stances, the social committee may decide the
+matter.
+  
+
+  
+Make a decision when asked to do so.
+
+Any person or body may delegate a decision of their own to the
+Social Committee, or seek advice from it.
+  
+
+  
+Offer advice.
+
+The Social Committee may make formal announcements about its
+views on any matter.
+Individual members may of course make informal statements about
+their views and about the likely views of the committee.
+  
+
+  
+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. Such requests, exp

Re: Social Committee proposal text (diff)

[Josip Rodin]

On Tue, Feb 13, 2007 at 11:26:58PM +0100, Josip Rodin wrote:
> > > Having a record of who voted for whom is a good default. Since we don't
> > > have any typical real-world election abuses in Debian (e.g. intimidation
> > > or harming of people who voted for someone you don't like), I see no
> > > serious negative consequences to publishing the votes.
> > 
> > "I don't like this person, but I have to work with him in this project,
> > so I would like to hide that fact from him/her. I don't want to rank
> > him/her above NOTA, but I also don't want to have to explain that"
> 
> Okay, that's a good point. I'm not automatically convinced that it's a
> seriously negative thing, however. This kind of openness can obviously
> cause some friction, but do we have any real evidence that says it's
> an insurmountable obstacle?

Resurrecting this old thing for another question that came to me now -
would it make sense to postpone the publication of votes in soc-ctte
elections? Like, publish the list of voters after a year or two?

By that time, time itself should have eroded much of the problem...

-- 
 2. That which causes joy or happiness.


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

Re: Social committee proposal

[Josip Rodin]

On Mon, Jun 04, 2007 at 11:05:02AM +0100, Ian Jackson wrote:
> > I don't quite get the idea of having a delegation where delegates are
> > voted upon. Imagine a conflict situation later - the leader can veto
> > their decisions, change charter, or even undelegate the whole thing.
> 
> Yes.  But in practice the DPL rarely exercises that authority.  This
> puts the SC on the same footing as the ftpmasters, release managers,
> etc. etc. etc.

Well, if you imply that the DPL wouldn't use that authority to curb
an SC which was once elected but has since run amok, isn't that an even
worse? :)

> This latter is an important point: if the SC members are elected,
> their mandate - ie, their support from the Developers - is clearly
> established.
> 
> People could complain that their robust style was being stifled by the
> majority but after all that is the whole point: to `stifle' the
> `excessively robust style' (ie, flames and other crap).  At least they
> won't be able to claim `the lurkers support me in email', `it's only a
> junta which is deciding this' and so on.

Good. Now that you have established all these reasons why the soc-ctte
members should be properly elected, why not have their legitimate election
be their right to exist, rather than the DPL's delegation? :)

> It seems to me that one election will probably be sufficient to make
> the general views of developers clear.  But if not the SC has the
> ability to request further elections, and if the DDs think it should
> but the SC won't then a DPL decision or GR can force an election or
> abolish it.

Having regular elections would greatly contribute to a sense of
accountability, and it would be a decent guarantee that the clarity of the
general views of developers is maintained over time. That's both among the
soc-ctte members and among the rest of the developers.
For these reasons, I think it's best if it's set up like that in the first
place, rather than having later elections optional.

> > I still think that we should organize a proper GR to put a basic framework
> > into the constitution, and then vote on the members regularly.
> 
> Firstly, the SC is an experiment.  It should be able to change the way
> it works in response to how things go - and the DPL should be able to
> do likewise.
> 
> Secondly, entrenching the SC is daft.  The SC has no powers that the
> DPL already doesn't.  Do you think that the DPL and Delegates' power
> to (for example) ban people from mailing lists should be abolished ?
> Are you proposing that the DPL and and the SC should have overlapping
> powers ?

If you go back to the original soc-ctte thread, you will notice that we
already discussed the extent of the soc-ctte powers. Nobody actually
proposed measures as concrete (or as harsh) as you did, to be put into
the constitution. It was fairly clear that there would be multiple options
on the ballot, for people to choose between several options of various
'softness'.

> Note that the existing arrangements for dividing jurisdiction between
> the TC and the DPL don't always work very well.  Often we end up
> arguing about jurisdiction, although this may be because the TC is the
> only non-dysfunctional mechanism we have for resolving general
> disputes between developers, so it gets the social disputes as well as
> technical ones.

Yeah. (Would you mind quoting an example or two, so that we're in the
clear about what exactly is meant?)

> > Social committee would deal with "mere" social matters, but we appear to
> > have ample precedent by now to indicate that such matters are sensitive
> > enough to need checks and balances.
> 
> The SC has _fewer_ checks and balances if it is entrenched in the
> constitution.  With my proposal, the SC can be overruled by the DPL or
> GR.  This means that if the SC is going off-course the DPL can have a
> quiet word.

I'm not sure that I like the idea of solving matters by having a quiet
word between someone who was elected but has a stick, and people who are
just elected.

And the prospect of leader intervening into the committee certainly won't
help with all the Cabal(TM) talk...

> If the SC is entrenched then (a) how do you divide controversies
> between DPL and SC and (b) who can overrule the SC ?

Well, I guess I have to refer you to the previous long thread, the one
started on January 25th with Message-ID: <[EMAIL PROTECTED]>

In short, and if I remember correctly, the previous proposal was that the
soc-ctte first decides whether a matter is a social matter, i.e. whether
they feel they should deliberate on it. If they decide so (and there was
an internal voting mechanism specified), they take on the issue; if they
can't decide if it's technical or social, they defer judgement to the
technical committee. I don't think anyone seriously recommended that a
social matter can be better decided by the leader, do you think we could
have such matters? Note that we could still have that by way of soc-ctte
asking the leader to decide inste

Re: Social committee proposal

[Francesco P. Lovergine]

On Fri, Jun 01, 2007 at 10:30:24PM +0200, Josip Rodin wrote:
> I still think that we should organize a proper GR to put a basic framework
> into the constitution, and then vote on the members regularly.

I agree. I always wonder why the project, like any other association of 
individuals instead, 
misses a regular board of voted members for standard governance and has instead
a single DPL. 

-- 
Francesco P. Lovergine


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

Re: Social committee proposal

[Ian Jackson]

Josip Rodin writes ("Re: Social committee proposal"):
> I don't quite get the idea of having a delegation where delegates are
> voted upon. Imagine a conflict situation later - the leader can veto
> their decisions, change charter, or even undelegate the whole thing.

Yes.  But in practice the DPL rarely exercises that authority.  This
puts the SC on the same footing as the ftpmasters, release managers,
etc. etc. etc.

> Doesn't that contradict with the idea that those five people were elected
> to do the said job? What's the point of electing people if they're not
> going to be allowed to do anything that the leader doesn't like? Why not
> just let the leader name them himself, and be done with it?

Because (a) the leader probably doesn't want that poisoned chalice and
(b) if they are elected their legitimacy is clear.

This latter is an important point: if the SC members are elected,
their mandate - ie, their support from the Developers - is clearly
established.

People could complain that their robust style was being stifled by the
majority but after all that is the whole point: to `stifle' the
`excessively robust style' (ie, flames and other crap).  At least they
won't be able to claim `the lurkers support me in email', `it's only a
junta which is deciding this' and so on.

It seems to me that one election will probably be sufficient to make
the general views of developers clear.  But if not the SC has the
ability to request further elections, and if the DDs think it should
but the SC won't then a DPL decision or GR can force an election or
abolish it.

> I still think that we should organize a proper GR to put a basic framework
> into the constitution, and then vote on the members regularly.

Firstly, the SC is an experiment.  It should be able to change the way
it works in response to how things go - and the DPL should be able to
do likewise.

Secondly, entrenching the SC is daft.  The SC has no powers that the
DPL already doesn't.  Do you think that the DPL and Delegates' power
to (for example) ban people from mailing lists should be abolished ?
Are you proposing that the DPL and and the SC should have overlapping
powers ?

Note that the existing arrangements for dividing jurisdiction between
the TC and the DPL don't always work very well.  Often we end up
arguing about jurisdiction, although this may be because the TC is the
only non-dysfunctional mechanism we have for resolving general
disputes between developers, so it gets the social disputes as well as
technical ones.

> Social committee would deal with "mere" social matters, but we appear
> to have ample precedent by now to indicate that such matters are sensitive
> enough to need checks and balances.

The SC has _fewer_ checks and balances if it is entrenched in the
constitution.  With my proposal, the SC can be overruled by the DPL or
GR.  This means that if the SC is going off-course the DPL can have a
quiet word.

If the SC is entrenched then (a) how do you divide controversies
between DPL and SC and (b) who can overrule the SC ?

Ian.


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

Re: Social committee proposal

[Ian Jackson]

MJ Ray writes ("Re: Social committee proposal"):
> Ian Jackson <[EMAIL PROTECTED]> wrote: [...]
> >  7. The initial Social Committee will consist of of five elected
> > Developers.  The Project Secretary is requested to organise and
> > hold an election, in a manner similar to that for Project Leader.
> > 
> >  8. The Committee shall be responsible for appointing new members,
> > removing existing members, and varying its size, as and when it
> > sees fit.
> 
> I feel that this would probably entrench any majority views,
> particularly with only five members.  Replace with:

Do you mean entrench the views about reasonable behaviour held by the
majority of Developers ?  The whole purpose of this exercise is to
give effect to the views about reasonable behaviour held by the
majority of Developers.

It's not entrenched because the DPL and/or the Developers can fire the
committee or individual members at will.

> >   There is no requirement for the Social Committee to publish
> >   requests made to it, its decisions or requests, or its
> >   deliberations except that access control decisions it makes
> >   under (4) above shall be public.
> 
> I don't think we should hide these problems.  Replace with:

I think that it would be better to allow people to contact the
committee in confidence, secure in the knowledge (for example) that if
the SC thinks they're being an arsehole no-one else is going to know.

Ian.


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

Re: Social committee proposal

[Anthony Towns]

On Sun, Jun 03, 2007 at 10:56:32PM +0100, Mark Brown wrote:
> On Fri, Jun 01, 2007 at 10:30:24PM +0200, Josip Rodin wrote:
> > Also, I can already see opposition to a committee which is only elected
> > once, and can then change its own membership at will, while retaining
> > all of its the powers that the originally elected members were given.
> > That simply sounds evil.
> It does mirror the arrangements for the TC.

Is that meant to be a good thing? :)

Cheers,
aj



signature.asc
Description: Digital signature

Re: Social committee proposal

[Andreas Tille]

On Sun, 3 Jun 2007, MJ Ray wrote:


I feel that this would probably entrench any majority views,
particularly with only five members.  Replace with:

7. The initial Social Committee will consist of eleven Developers
drawn by random selection from all Developers.


Are there any statistics from which number of members on a
commitee stops working effectively?  IMHO, a committee of
five members is able to work effectively - a commettee of
eleven is not.  At least this is my personal experience and
I wonder whether there is some research done that reflects
this personal observation.

Moreover I wonder what sense a random selection should make.
Chances are good that at least half of the members is either
not interested or MIA.


8. Should any appointed Developer be unwilling to serve, unwilling to
serve any longer, or fail to answer three requests from the Project
Leader within a month without warning, they will be replaced by
another Developer drawn in the same manner.


I wonder how long it will take to finally get a working committee
by using this procedure.

Kind regards

Andreas.

--
http://fam-tille.de


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

Re: Social committee proposal

[MJ Ray]

Ian Jackson <[EMAIL PROTECTED]> wrote: [...]
>   There is no requirement for the Social Committee to publish
>   requests made to it, its decisions or requests, or its
>   deliberations except that access control decisions it makes
>   under (4) above shall be public.

I don't think we should hide these problems.  Replace with:

The Social Committee will publish requests made to it and optionally
any statements of its members about the request after three years.

[...]
>  7. The initial Social Committee will consist of of five elected
> Developers.  The Project Secretary is requested to organise and
> hold an election, in a manner similar to that for Project Leader.
> 
>  8. The Committee shall be responsible for appointing new members,
> removing existing members, and varying its size, as and when it
> sees fit.

I feel that this would probably entrench any majority views,
particularly with only five members.  Replace with:

7. The initial Social Committee will consist of eleven Developers
drawn by random selection from all Developers.

8. Should any appointed Developer be unwilling to serve, unwilling to
serve any longer, or fail to answer three requests from the Project
Leader within a month without warning, they will be replaced by
another Developer drawn in the same manner.


Hope that helps,
-- 
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: Social committee proposal

[Mark Brown]

On Fri, Jun 01, 2007 at 10:30:24PM +0200, Josip Rodin wrote:

> Also, I can already see opposition to a committee which is only elected
> once, and can then change its own membership at will, while retaining
> all of its the powers that the originally elected members were given.
> That simply sounds evil.

It does mirror the arrangements for the TC.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Re: Social committee proposal

[Josip Rodin]

On Fri, Jun 01, 2007 at 10:39:53AM +0100, Ian Jackson wrote:
> NB that such a committee does not need to be consititutionally
> established.  The DPL's existing powers are sufficient to establish
> it.  A big advantage to not establishing the committee
> constitutionally is that we don't need to worry so much about it
> overstepping the mark, so we do away with the checks and balances that
> hedge (for example) the TC's powers and processes.  After all, as the
> DPL's delegates, the social committee can be overruled by a GR if it
> were necessary.
[...]

I don't quite get the idea of having a delegation where delegates are
voted upon. Imagine a conflict situation later - the leader can veto
their decisions, change charter, or even undelegate the whole thing.
Doesn't that contradict with the idea that those five people were elected
to do the said job? What's the point of electing people if they're not
going to be allowed to do anything that the leader doesn't like? Why not
just let the leader name them himself, and be done with it?

Also, I can already see opposition to a committee which is only elected
once, and can then change its own membership at will, while retaining
all of its the powers that the originally elected members were given.
That simply sounds evil.

I still think that we should organize a proper GR to put a basic framework
into the constitution, and then vote on the members regularly.
Social committee would deal with "mere" social matters, but we appear
to have ample precedent by now to indicate that such matters are sensitive
enough to need checks and balances.

-- 
 2. That which causes joy or happiness.


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

Social committee proposal

[Ian Jackson]

Recent events have shown us again that we need an advisory and
disciplinary process short of expulsion.  I think a social committee
is roughly the right answer.

NB that such a committee does not need to be consititutionally
established.  The DPL's existing powers are sufficient to establish
it.  A big advantage to not establishing the committee
constitutionally is that we don't need to worry so much about it
overstepping the mark, so we do away with the checks and balances that
hedge (for example) the TC's powers and processes.  After all, as the
DPL's delegates, the social committee can be overruled by a GR if it
were necessary.

So let me make a concrete proposal for a DPL delegation which I hope
will be adapted and adopted by Sam.


 SUGGESTED DELEGATION BY THE PROJECT LEADER
 ESTABLISHING A SOCIAL COMMITTEE

 RUBRIC

 A. I consider it necessary that it would be beneficial to formally
establish a Social Committee for resolving nontechnical disputes.

 B. I hereby establish such a Committee as Delegates of the Project
Leader, using the Leader's powers in Constitution 5.1(1).

 CHARTER OF THE SOCIAL COMMITTEE

 1. The Social Committee's purpose is to promote constructive and
agreeable relations between Debian Developers and others involved
with Debian.

 2. To this end the Social Committee may:

(1) Make a decision when asked to do so.

  Any person or body may delegate a decision of their own to the
  Social Committee, or seek advice from it.

(2) Offer advice.

  The Social Committee may make formal announcements about its
  views on any matter.  This includes but is not limited to both
  statements about particular cases and documents giving general
  guidance.  (Individual members may of course make informal
  statements about their views and about the likely views of the
  committee.)

(3) Request Cease and Desist

  Where the Committee thinks it necessary to avoid serious
  hindrance to constructive and agreeable relations, the Committee
  may request that a person to refrain from certain acts and
  communications.  The nature of the acts to be avoided should be
  clearly stated in the Committee's request.

  For example, the Committee might ask a Developer not to NMU a
  particular package, not to contact a particular other Developer,
  or not to post to a particular mailing list or not to post
  discussing particular topics.

(4) Make Access Control Decisions

  Provided at least two thirds of the Committee positively agree,
  instruct Debian's mailing list administrators, archive
  administrators, and other persons in similar positions to make
  or remove access control arrangements which allow or prevent a
  person from posting to certain mailing lists, making certain
  kinds of uploads, or doing other specified acts.

  Where the access-controlled resource is a not one maintained for
  and by the project as a whole, but is instead a private resource
  (including private resources hosted on project systems), the
  Social Committee may only make requests rather than giving
  instructions.

  For the avoidance of doubt no-one (the Social Committee not
  excepted) is permitted to prevent a Developer from posting to
  the formal decisionmaking mailing list mentioned in Constitution
  4.2(5).

(5) Decide Its Own Procedure

  Provided the decisions are consistent with the above, and
  provided that the Project Leader does not object, the Social
  Committe may decide on:
(a) its own size,
(b) its own composition and manner of appointment,
(c) its own procedures for for decisionmaking, including
(d) how many of its members are required to agree on
which kinds of decisions, including
(e) whether to initially assign and empower a single committee
member to deal with each enquiry, and of course
(f) any appeals procedure(s) short of overturn via General
Resolution, and finally
(g) any similar matters regarding its own operation.

  These procedural decisions should be published by the committee,
  in the form of a revised edition of the Appendix to this
  Charter.

  There is no requirement for the Social Committee to publish
  requests made to it, its decisions or requests, or its
  deliberations except that access control decisions it makes
  under (4) above shall be public.

 5. The Project Leader (and hence the Developers via General
Resolution) are entitled to vary this Charter or the Appendix, or
the composition of the committee, at any time, as an exercise
of Constitution 5.1(1).

 6. Future Project Leaders are specifically encouraged to delegate
additional powers to the Committee whenever it seems appropriate,
especially if the Committee itself requests additional powers.

 APPENDIX

 7. 

Re: Social Committee proposal text (diff)

[Wouter Verhelst]

On Tue, Feb 13, 2007 at 10:59:00PM +, MJ Ray wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > "I don't like this person, but I have to work with him in this project,
> > so I would like to hide that fact from him/her. I don't want to rank
> > him/her above NOTA, but I also don't want to have to explain that"
> 
> So, what can one conclude about debian from the above justification?

Nothing. This isn't about Debian specifically, it's about voting in
general. There will *always* be people who will consider this kind of
thing when they vote, and they should not be compromising their vote in
the off chance that someone *might* be offended by their it if they vote
the way they really want to. It's about safeguarding the integrity of
individual votes, and the voting system in general.

Personally, I think that's a good enough reason to make *all* votes in
Debian be secret, but, well -- I don't expect that to happen anytime
soon.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: Social Committee proposal text (diff)

[gregor herrmann]

On Thu, 15 Feb 2007 10:52:12 +0100, Josip Rodin wrote:

> > > (Just a note - my S2 boundary isn't really arbitrary, it's basically a
> > > function of the quorum.)
> > (Point taken but it's still a deliberate decision to say
> > count($members_of_soc_ctte)=round(Q).)
> (I was just correcting the adjective used - "arbitrary" isn't the same as
> "deliberate" :)

(Debian is a great place for learning for me ;-))
 
> > I guess at the end the size of the committee should:
> > * depend on its goals and tasks
> > * allow the group to work as a _group_
> > 
> > (The other question is of course what happens if there are not enough
> > candidates/winners. Maybe an (equally arbitrary) minimum size for a
> > second round could be defined?)
> I've discussed in the previous thread why I thought 1000->16 or 2000->23
> were decent; but that was more in light of an upper limit, rather than a
> lower limit. Only when I started writing the exact rule into the
> constitution text did I realize that there lower limit needs to be
> thought about :)

As long as we discover this issue in time ... :-)
 
> If there is a serious doubt whether we would be able to elect that many
> people in less than two rounds of elections (a second round would be
> bearable; a third would be a real bother) 

Agreed.

> then I would have to be leaning
> towards either:
> * Allowing a variable number of members, to a point. I was originally
>   thinking that a fixed size needs to be set in order to have a clear
>   understanding of what the membership in the ctte means; also adding
>   variability adds more nuance into the constitution definition so it's
>   harder to write.
> * Or cutting the fixed size further down, but that sounds like a workaround.

I too think the first possibility is better; and I think adding a
minimum size shouldn't make the definition too complicated.

Cheers,
gregor
 
 
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian: the universal operating system - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-NP: Die Tontauben: jonny


signature.asc
Description: Digital signature

Re: Social Committee proposal text (diff)

[Josip Rodin]

On Tue, Feb 13, 2007 at 11:59:06PM +0100, gregor herrmann wrote:
> > > > Do you think it's likely for it to go on for more than one repetition?
> > > I've no real idea but it might lead to a dead end. And having
> > > infinite nominations/elections because there are e.g. "only" 10 and
> > > not 16 persons seems to defeat the whole idea.
> > (Just a note - my S2 boundary isn't really arbitrary, it's basically a
> > function of the quorum.)
> 
> (Point taken but it's still a deliberate decision to say
> count($members_of_soc_ctte)=round(Q).)

(I was just correcting the adjective used - "arbitrary" isn't the same as
"deliberate" :)

> > I have pondered this previously, but I decided to have a try like that
> > still. If we allow the bar to be dropped arbitrarily down from the
> > quorum-based quota, then how do we decide how many are sufficient and
> > how many are not?
> 
> I don't have an answer ready but IMO S2 (or Q) is not more magical
> then 5 or 13 or 42.
> 
> I guess at the end the size of the committee should:
> * depend on its goals and tasks
> * allow the group to work as a _group_
> 
> (The other question is of course what happens if there are not enough
> candidates/winners. Maybe an (equally arbitrary) minimum size for a
> second round could be defined?)

I've discussed in the previous thread why I thought 1000->16 or 2000->23
were decent; but that was more in light of an upper limit, rather than a
lower limit. Only when I started writing the exact rule into the
constitution text did I realize that there lower limit needs to be
thought about :)

If there is a serious doubt whether we would be able to elect that many
people in less than two rounds of elections (a second round would be
bearable; a third would be a real bother) then I would have to be leaning
towards either:
* Allowing a variable number of members, to a point. I was originally
  thinking that a fixed size needs to be set in order to have a clear
  understanding of what the membership in the ctte means; also adding
  variability adds more nuance into the constitution definition so it's
  harder to write.
* Or cutting the fixed size further down, but that sounds like a workaround.

-- 
 2. That which causes joy or happiness.


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

Re: Social Committee proposal text (diff)

[Andreas Schuldei]

* Wouter Verhelst ([EMAIL PROTECTED]) [070213 17:18]:
> "I don't like this person, but I have to work with him in this project,
> so I would like to hide that fact from him/her. I don't want to rank
> him/her above NOTA, but I also don't want to have to explain that"


that problem can easily be avoided by running for office
yourself. everyone will understand that you rank yourself
highest!



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

Re: Social Committee proposal text (diff)

[MJ Ray]

Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> "I don't like this person, but I have to work with him in this project,
> so I would like to hide that fact from him/her. I don't want to rank
> him/her above NOTA, but I also don't want to have to explain that"

So, what can one conclude about debian from the above justification?
Are candidates petty and personal enough to wage vendettas if you
don't vote for them?  Do voters think that enough candidates are that
crass that it would be a problem?  Are voters unwilling to take a full
part in democracy and face being asked to justify their vote?

In short, do debian voters not have the courage to stand up and be
counted?  Actually, I believe some haven't: one who told me in private
mail that they would vote to recall the DPL didn't do so, after it
became obvious it was a public vote.

I think the vote should be public, but there should also be harsh
penalties for anyone acting on those votes outside the election.
If there's no good way to do that, then allow it to be secret, but
that's about the only valid reason to me.

Regards,
-- 
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Somerset, England. Work/Laborejo: http://www.ttllp.co.uk/
IRC/Jabber/SIP: on request/peteble.


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

Re: Social Committee proposal text (diff)

[gregor herrmann]

On Tue, 13 Feb 2007 23:46:10 +0100, Josip Rodin wrote:

> > > Do you think it's likely for it to go on for more than one repetition?
> > I've no real idea but it might lead to a dead end. And having
> > infinite nominations/elections because there are e.g. "only" 10 and
> > not 16 persons seems to defeat the whole idea.
> (Just a note - my S2 boundary isn't really arbitrary, it's basically a
> function of the quorum.)

(Point taken but it's still a deliberate decision to say
count($members_of_soc_ctte)=round(Q).)

> I have pondered this previously, but I decided to have a try like that
> still. If we allow the bar to be dropped arbitrarily down from the
> quorum-based quota, then how do we decide how many are sufficient and
> how many are not?

I don't have an answer ready but IMO S2 (or Q) is not more magical
then 5 or 13 or 42.

I guess at the end the size of the committee should:
* depend on its goals and tasks
* allow the group to work as a _group_

(The other question is of course what happens if there are not enough
candidates/winners. Maybe an (equally arbitrary) minimum size for a
second round could be defined?)

I hope that these technicalities can be better worked out if the
issued for the ctte are a little clearer.

Cheers,
gregor 
 
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian: the universal operating system - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-BOFH excuse #138:  BNC (brain not connected) 


signature.asc
Description: Digital signature

Re: Social Committee proposal text (diff)

[Josip Rodin]

On Tue, Feb 13, 2007 at 07:39:12PM +0100, gregor herrmann wrote:
> > > > + If there are fewer than S2 candidates
> > > > +  at the end of the nomination period, then the nomination period is
> > > > +  extended for two further weeks, repeatedly if necessary.
> > > > +  If "None Of The Above" wins the election, or if fewer than S2
> > > > +  candidates win over "None of the Above", the election process is
> > > > +  repeated.
> > > How often should the nomination period and the election process be
> > > repeated? I'd suggest to include some maximum otherwise they could go
> > > on ad infinitum.
> > You can see similar rules in other parts of the constitution, see 5.2.4,
> > 5.2.6.
> 
> I think there's a huge difference between "no candidates" (5.2.4) and
> "fewer than S2 candidates" in your proposal, and between "NOTA wins"
> (5.2.6) vs. "fewer than S2 candidates over NOTA".
> 
> In other words: The threshold is much higer (16 vs. 1 AIUI) and it's
> much easier that it won't be reached.
> 
> And the regulations in the Constitution seem logically necessary: If
> there is not a single candidate or a single winner there has to be
> some "else case" whereas your S2 boundary is arbritary (which is not
> bad in itself but it could be any other value too).
>  
> > Do you think it's likely for it to go on for more than one repetition?
>  
> I've no real idea but it might lead to a dead end. And having
> infinite nominations/elections because there are e.g. "only" 10 and
> not 16 persons seems to defeat the whole idea.

(Just a note - my S2 boundary isn't really arbitrary, it's basically a
function of the quorum.)

I have pondered this previously, but I decided to have a try like that
still. If we allow the bar to be dropped arbitrarily down from the
quorum-based quota, then how do we decide how many are sufficient and
how many are not?

E.g. most people will think that a re-vote isn't worth it if we get 15
rather than 16, many will think it's not worth it if it's 10 rather than 16,
but what if one day it's 10 rather than 23, and at the same time we get a
three times as large a turnout, meaning we are sampling a much larger
interested population?

Where do we put the threshold?

-- 
 2. That which causes joy or happiness.


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

Re: Social Committee proposal text (diff)

[Josip Rodin]

On Tue, Feb 13, 2007 at 09:14:27PM +0100, Alexander Schmehl wrote:
> > You are aware that most of our elections are done this way,
> 
> Yes, I know.
> 
> > we only use hashes in the tally sheet for leader elections?
> 
> Or in other words:  I 100% of the votes regarding persons, we have a
> secret vote.

Yes, but the sample is still just 1. (Also I don't know the rationale for
that, so it's hard to judge it - it could have been fully intentional, it
could have been some sort of a CYA measure that was grandfathered in.)

Anyway. Let's take any other election as an example. What do we do with
people who intensely dislike the option X in an election and takes each vote
to the contrary as an insulting statement from those voters, or just takes
it personally? One could make the argument that keeping the tally sheet
obfuscated is good for any election, because we want to avoid fussing over
*anything*.

In the end, does it really avoid people fussing over things, or does it
really just obfuscate the fussing, from 'evil people A,B,C voted against me!'
to 'three evil people voted against me!'?

-- 
 2. That which causes joy or happiness.


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

Re: Social Committee proposal text (diff)

[Josip Rodin]

On Tue, Feb 13, 2007 at 05:17:43PM +0100, Wouter Verhelst wrote:
> > Having a record of who voted for whom is a good default. Since we don't
> > have any typical real-world election abuses in Debian (e.g. intimidation
> > or harming of people who voted for someone you don't like), I see no
> > serious negative consequences to publishing the votes.
> 
> "I don't like this person, but I have to work with him in this project,
> so I would like to hide that fact from him/her. I don't want to rank
> him/her above NOTA, but I also don't want to have to explain that"

Okay, that's a good point. I'm not automatically convinced that it's a
seriously negative thing, however. This kind of openness can obviously
cause some friction, but do we have any real evidence that says it's
an insurmountable obstacle?

-- 
 2. That which causes joy or happiness.


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

Re: Social Committee proposal text (diff)

[Sam Hocevar]

On Tue, Feb 13, 2007, Alexander Schmehl wrote:

> > we only use hashes in the tally sheet for leader elections?
> 
> Or in other words:  I 100% of the votes regarding persons, we have a
> secret vote.

   Not quite 100%. A DPL recall vote is about a person.

Cheers,
-- 
Sam.


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

Re: Social Committee proposal text (diff)

[Alexander Schmehl]

Hi!

Sorry, forgot to mention one thing:

* Josip Rodin <[EMAIL PROTECTED]> [070213 11:54]:

> You are aware that most of our elections are done this way,

Yes, I know.


> we only use hashes in the tally sheet for leader elections?

Or in other words:  I 100% of the votes regarding persons, we have a
secret vote.


Yours sincerely,
  Alexander


signature.asc
Description: Digital signature

Re: Social Committee proposal text (diff)

[Alexander Schmehl]

Hi!

* Josip Rodin <[EMAIL PROTECTED]> [070213 11:54]:

> I don't think I want anyone who fears the idea of public disagreement to
> sit two years in a committee that arbitrates social conflicts. [..]

Neither do I.  That's why I want it to be possible to not vote for such a
candidate without him knowing it.


Yours sincerely,
  Alexander



signature.asc
Description: Digital signature

Re: Social Committee proposal text (diff)

[gregor herrmann]

On Tue, 13 Feb 2007 11:42:50 +0100, Josip Rodin wrote:

> > > + If there are fewer than S2 candidates
> > > +  at the end of the nomination period, then the nomination period is
> > > +  extended for two further weeks, repeatedly if necessary.
> > > +  If "None Of The Above" wins the election, or if fewer than S2
> > > +  candidates win over "None of the Above", the election process is
> > > +  repeated.
> > How often should the nomination period and the election process be
> > repeated? I'd suggest to include some maximum otherwise they could go
> > on ad infinitum.
> You can see similar rules in other parts of the constitution, see 5.2.4,
> 5.2.6.

I think there's a huge difference between "no candidates" (5.2.4) and
"fewer than S2 candidates" in your proposal, and between "NOTA wins"
(5.2.6) vs. "fewer than S2 candidates over NOTA".

In other words: The threshold is much higer (16 vs. 1 AIUI) and it's
much easier that it won't be reached.

And the regulations in the Constitution seem logically necessary: If
there is not a single candidate or a single winner there has to be
some "else case" whereas your S2 boundary is arbritary (which is not
bad in itself but it could be any other value too).
 
> Do you think it's likely for it to go on for more than one repetition?
 
I've no real idea but it might lead to a dead end. And having
infinite nominations/elections because there are e.g. "only" 10 and
not 16 persons seems to defeat the whole idea.

Cheers,
gregor
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian: the universal operating system - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-NP: Bob Dylan: Absolutely sweet Marie


signature.asc
Description: Digital signature

Re: Social Committee proposal text (diff)

[Wouter Verhelst]

On Tue, Feb 13, 2007 at 11:54:04AM +0100, Josip Rodin wrote:
> I don't think I want anyone who fears the idea of public disagreement to
> sit two years in a committee that arbitrates social conflicts.

That's turning the problem upside-down. It's not about avoiding fears
for people who are running for a position; it's about avoiding fears for
those who are actually voting.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: Social Committee proposal text (diff)

[Wouter Verhelst]

On Tue, Feb 13, 2007 at 12:07:34PM +0100, Josip Rodin wrote:
> Having a record of who voted for whom is a good default. Since we don't have
> any typical real-world election abuses in Debian (e.g. intimidation or
> harming of people who voted for someone you don't like), I see no serious
> negative consequences to publishing the votes.

"I don't like this person, but I have to work with him in this project,
so I would like to hide that fact from him/her. I don't want to rank
him/her above NOTA, but I also don't want to have to explain that"

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: Social Committee proposal text (diff)

[Josip Rodin]

On Tue, Feb 13, 2007 at 11:25:09AM +0100, Stefano Zacchiroli wrote:
> No matter what's my opinion on whether fresh blood is good or bad for
> the social ctte, I doubt it would make any difference to state a rule
> like that. The committee will be elected and I seriously doubt any
> "fresh blood" DD will be elected in such a position by the DD body.
> 
> Sure there's no warranty that this is the cause, but I'm confident
> enough in it to prefer not to write down such a rule.

I suppose we could do that, too. I would not be opposed to that.

On the other hand, we could also go middle ground and lower the threshold
to something that is guaranteed to avoid re-votes. 20%?

-- 
 2. That which causes joy or happiness.


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

Re: Social Committee proposal text (diff)

[Josip Rodin]

On Tue, Feb 13, 2007 at 11:17:52AM +0100, Alexander Schmehl wrote:
> > > > +  The next two weeks are the polling period during which
> > > > +  Developers may cast their votes.  Votes in social committee elections
> > > > +  are made public after the election is finished.
> > > And why shall votes become public?  What's voting about, if not done in
> > > secret?
> > The secrecy is not the point - the point is that we make a cross-section of
> > society, a sample of people who are at least vaguely representative.
> 
> And how will a public election help us having at least vaguely
> representative?

I assume that the emphasis was on *public* election, not on public *election*.

Having a record of who voted for whom is a good default. Since we don't have
any typical real-world election abuses in Debian (e.g. intimidation or
harming of people who voted for someone you don't like), I see no serious
negative consequences to publishing the votes.

The voters can compare notes about who they voted, the candidates can see
who voted for them and who voted for someone else, and all can learn from
the process. In the real-world, this might lead to a surge in populism -
candidates would start appealing to the largest demographics in an effort to
garner more votes; but here, the effect of that would easily be diminished
as soon as people saw through it and started ranking such candidates down;
the election method doesn't give much hope to candidates who are intensely
disliked as well as intensely liked.

We also don't have trivial mass-communication problems as the real world,
and instead have numerous forums and ways of normal voters to communicate
their thoughts with hundreds of others, so opinions are shared much more
easily and you don't get stuck without a relevant information just because
the editor at the TV station didn't think it was cool enough to report.

Maybe there's something that I didn't notice - please do share your
thoughts.

-- 
 2. That which causes joy or happiness.


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

Re: Social Committee proposal text (diff)

[Josip Rodin]

On Tue, Feb 13, 2007 at 11:14:40AM +0100, Alexander Schmehl wrote:
> > >> + The next two weeks are the polling period during which
> > >> + Developers may cast their votes.  Votes in social committee
> > >>elections
> > >> + are made public after the election is finished.
> > > And why shall votes become public?  What's voting about, if not done
> > > in secret?
> > I think we should default to open and transparent processes
> >  as far as possible. And people should be willing to take public
> >  stances on matters of policy, even social policy.  It is not like you
> >  are voting for a human who might have his feeling s hurt. 
> 
> I read the cited paragraph as exactly that:  The votes of DDs in the
> election for the members of the social ctte will be made public.  I
> agree that the internal soc ctte votes are a different thing; but as I
> understood it, they are not the topic of that paragraph.
> 
> So it is exactly about "voting for a human who might have his feelings
> hurt".  And it is all about possibly voting differently while the public
> is looking over your shoulder.  
> 
> I just don't see, how that will help to get a better soc ctte.

You are aware that most of our elections are done this way, we only use
hashes in the tally sheet for leader elections? I suppose we could also
obfuscate the tally sheet for soc-ctte elections, too, but I would really be
interested to see who would get offended at the votes, and particularly why
they think that they should sit on a social committee if they can't handle
social differences.

I don't think I want anyone who fears the idea of public disagreement to
sit two years in a committee that arbitrates social conflicts. How can I be
sure that the same person won't act improperly when it comes to resolving
other people's issues, if they can't handle their own issues gracefully?

Maybe it's asking too much, but I really hope we that can find sixteen
level-headed people among a thousand who can handle negative votes...

-- 
 2. That which causes joy or happiness.


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

Re: Social Committee proposal text (diff)

[Josip Rodin]

On Mon, Feb 12, 2007 at 05:08:09PM +0100, gregor herrmann wrote:
> > + If there are fewer than S2 candidates
> > +  at the end of the nomination period, then the nomination period is
> > +  extended for two further weeks, repeatedly if necessary.
> [..]
> > +  If "None Of The Above" wins the election, or if fewer than S2
> > +  candidates win over "None of the Above", the election process is
> > +  repeated.
> > +
> > +  At least one third of all elected candidates should have been
> > +  members of the project for at least Y/2 years, where Y is the age
> > +  of the Project in years. If fewer than one third of candidates meet
> > +  this requirement, the election process is repeated.
> 
> How often should the nomination period and the election process be
> repeated? I'd suggest to include some maximum otherwise they could go
> on ad infinitum.

You can see similar rules in other parts of the constitution, see 5.2.4,
5.2.6.

Do you think it's likely for it to go on for more than one repetition?

-- 
 2. That which causes joy or happiness.


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

Re: Social Committee proposal text (diff)

[Josip Rodin]

On Mon, Feb 12, 2007 at 12:44:40PM -0500, Joe Smith wrote:
> >>and I would think that social problems / discussions should be considered
> >>even more private.
> >
> >I disagree - if a problem is severe enough to get brought before soc-ctte,
> >it's out in the open already, and needs to be dealt with transparently.
> 
> Not nessesarally. A nasty non-technical dispute could occur on -private.
> I belive that the soc-ctte could be asked to deal with this. It may not be
> public, and it is possible that it should not be public.
> That is especially true if the issue is privacy related.

Well, the soc-ctte will function like tech-ctte. If a developer, be they a
member of the ctte or not, screws up and posts sensitive info to soc-ctte
public list - I'm not really sure that's something that can be regulated.

Anyway, things can be discussed on debian-private and then people can decide
what to do. I could imagine a situation where the leader delegates it to the
soc-ctte to consider a particular issue behind closed doors. It wouldn't be
"normal", but this should be an exception rather than a rule.

-- 
 2. That which causes joy or happiness.


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

Re: Social Committee proposal text (diff)

[MJ Ray]

Manoj Srivastava <[EMAIL PROTECTED]> wrote: [...]
> A social committee needs demosntrated judgement.  People new,
>  and inexperienced in the ways of Debian, might not really be better
>  fit. [...]

Is soc-ctte about preserving the current/recent-past majority view, or
correcting the majority social dysfunctions, or something else?

I suggest that everyone who joined debian while it was a social
basket-case should be disqualified from soc-ctte membership!

I agree with the arguments for openness FWIW.

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: Social Committee proposal text (diff)

[Stefano Zacchiroli]

On Mon, Feb 12, 2007 at 11:38:12AM +0100, Alexander Schmehl wrote:
> > +  At least one third of all elected candidates should have been
> > +  members of the project for at least Y/2 years, where Y is the age
> > +  of the Project in years. If fewer than one third of candidates meet
> > +  this requirement, the election process is repeated.
> And why that rule?  I would think in a social ctte, fresh blood is very
> welcome, because they (probalbly) haven't taken part in any flamewar and
> therefore are the best to choice for a ctte, that should be as objective
> and neutral as possible?

No matter what's my opinion on whether fresh blood is good or bad for
the social ctte, I doubt it would make any difference to state a rule
like that. The committee will be elected and I seriously doubt any
"fresh blood" DD will be elected in such a position by the DD body.

Sure there's no warranty that this is the cause, but I'm confident
enough in it to prefer not to write down such a rule.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[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: Social Committee proposal text (diff)

[Alexander Schmehl]

Hi!

* Josip Rodin <[EMAIL PROTECTED]> [070212 12:17]:

> > > +  The next two weeks are the polling period during which
> > > +  Developers may cast their votes.  Votes in social committee elections
> > > +  are made public after the election is finished.
> > And why shall votes become public?  What's voting about, if not done in
> > secret?
> The secrecy is not the point - the point is that we make a cross-section of
> society, a sample of people who are at least vaguely representative.

And how will a public election help us having at least vaguely
representative?


> I don't see any reason against disclosure.

And I don't see any reason for it.


Yours sincerely,
  Alexander


signature.asc
Description: Digital signature

Re: Social Committee proposal text (diff)

[Alexander Schmehl]

Hi!

* Manoj Srivastava <[EMAIL PROTECTED]> [070213 04:28]:

> >> + The next two weeks are the polling period during which
> >> + Developers may cast their votes.  Votes in social committee
> >>elections
> >> + are made public after the election is finished.
> > And why shall votes become public?  What's voting about, if not done
> > in secret?
> I think we should default to open and transparent processes
>  as far as possible. And people should be willing to take public
>  stances on matters of policy, even social policy.  It is not like you
>  are voting for a human who might have his feeling s hurt. 

I read the cited paragraph as exactly that:  The votes of DDs in the
election for the members of the social ctte will be made public.  I
agree that the internal soc ctte votes are a different thing; but as I
understood it, they are not the topic of that paragraph.

So it is exactly about "voting for a human who might have his feelings
hurt".  And it is all about possibly voting differently while the public
is looking over your shoulder.  

I just don't see, how that will help to get a better soc ctte.


> > Why not some kind of "draft resolutions and amendments, and votes by
> > members of the committee, are made public on the Social Committee
> > public discussion list. Discussion is made public to those the
> > parties involved or at their unison request to all."?
> Again, the default should be open processes, with the
>  possibility of taking it behind closed doors [..]

I think having the possibility of taking it behind closed doors would
do.


Yours sincerely,
  Alexander


signature.asc
Description: Digital signature

Re: Social Committee proposal text (diff)

[Manoj Srivastava]

On Mon, 12 Feb 2007 11:38:12 +0100, Alexander Schmehl
<[EMAIL PROTECTED]> said:  

> Hi!
> * Josip Rodin <[EMAIL PROTECTED]> [070212 03:32]:

>> + The next two weeks are the polling period during which
>> + Developers may cast their votes.  Votes in social committee
>>elections
>> + are made public after the election is finished.

> And why shall votes become public?  What's voting about, if not done
> in secret?

I think we should default to open and transparent processes
 as far as possible. And people should be willing to take public
 stances on matters of policy, even social policy.  It is not like you
 are voting for a human who might have his feeling s hurt. 

> And why that rule?  I would think in a social ctte, fresh blood is
> very welcome, because they (probalbly) haven't taken part in any
> flamewar and therefore are the best to choice for a ctte, that
> should be as objective and neutral as possible?

A social committee needs demosntrated judgement.  People new,
 and inexperienced in the ways of Debian, might not really be better
 fit.

> Why not some kind of "draft resolutions and amendments, and votes by
> members of the committee, are made public on the Social Committee
> public discussion list. Discussion is made public to those the
> parties involved or at their unison request to all."?

Again, the default should be open processes, with the
 possibility of taking it behind closed doors (like happens in court
 systems here).  Closed star chambers are not what we are shooting for
 here.

manoj
-- 
[He] took me into his library and showed me his books, of which he had
a complete set. -- Ring Lardner
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: Social Committee proposal text (diff)

[Joe Smith]

"Josip Rodin" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Mon, Feb 12, 2007 at 11:38:12AM +0100, Alexander Schmehl wrote:


and I would think that social problems / discussions should be considered
even more private.


I disagree - if a problem is severe enough to get brought before soc-ctte,
it's out in the open already, and needs to be dealt with transparently.


Not nessesarally. A nasty non-technical dispute could occur on -private.
I belive that the soc-ctte could be asked to deal with this. It may not be
public, and it is possible that it should not be public.
That is especially true if the issue is privacy related.



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

Re: Social Committee proposal text (diff)

[gregor herrmann]

On Mon, 12 Feb 2007 03:32:52 +0100, Josip Rodin wrote:

> + If there are fewer than S2 candidates
> +  at the end of the nomination period, then the nomination period is
> +  extended for two further weeks, repeatedly if necessary.
[..]
> +  If "None Of The Above" wins the election, or if fewer than S2
> +  candidates win over "None of the Above", the election process is
> +  repeated.
> +
> +  At least one third of all elected candidates should have been
> +  members of the project for at least Y/2 years, where Y is the age
> +  of the Project in years. If fewer than one third of candidates meet
> +  this requirement, the election process is repeated.

How often should the nomination period and the election process be
repeated? I'd suggest to include some maximum otherwise they could go
on ad infinitum.

And count me in to the group of people asking for examples - I'm
following this proposal with interest but still I don't really know
what those social issues are this committee should decide about.

Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian: the universal operating system - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-NP: Simon and Garfunkel


signature.asc
Description: Digital signature

Re: Social Committee proposal text (diff)

[Josip Rodin]

On Mon, Feb 12, 2007 at 01:22:41PM +0100, Josip Rodin wrote:
> > In your suggestion the first three people to be elected would be a1,
> > a2 and a3, as they all beat all B candidates. In a representative
> > election a1, a2 and b1 should be elected, instead.
> 
> Er, I don't think I modified the election method in that way by including
> that sentence. I thought I said - follow section A.6, which determines the
> ranking, and then take the list and pick the top X people who are above NOTA.

Actually, upon closer inspection, I see now that A.6 is actually not
completely accurate for this case. It has this:

8. If there are no defeats within the Schwartz set, then the winner is
   chosen from the options in the Schwartz set. If there is only one such
   option, it is the winner. If there are multiple options, the elector with
   the casting vote chooses which of those options wins.

We need to skip that in case of soc-ctte elections. The list that I
mentioned previously would be referred to as a 'Schwartz set', if I get this
right.

-- 
 2. That which causes joy or happiness.


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

Re: Social Committee proposal text (diff)

[Josip Rodin]

On Mon, Feb 12, 2007 at 01:50:35PM +0200, Kalle Kivimaa wrote:
> One question related to the Concordet method: does it fullfill the
> representative criteria?
> 
> AFAIUI the Concordet method allows this (please correct me if I'm
> wrong):
> 
> We have two groups of people, A and B. A has 20 people, B 10. A fields
> candidates a1, a2 and a3, and B fields b1, b2 and b3. We are about to
> elect three people.
> 
> All A people post ballots a1,a2,a3,NOTA,b1,b2,b3, and all B people
> post ballots b1,b2,b3,NOTA,a1,a2,a3.
> 
> In your suggestion the first three people to be elected would be a1,
> a2 and a3, as they all beat all B candidates. In a representative
> election a1, a2 and b1 should be elected, instead.

Er, I don't think I modified the election method in that way by including
that sentence. I thought I said - follow section A.6, which determines the
ranking, and then take the list and pick the top X people who are above NOTA.

-- 
 2. That which causes joy or happiness.


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

Re: Social Committee proposal text (diff)

[Kalle Kivimaa]

Josip Rodin <[EMAIL PROTECTED]> writes:
> Think of scale - right now we need 16 people to 'win' the election, and
> the seats last twice as long as the leadership seat. It made sense to me -
> please say if it doesn't to you.

One question related to the Concordet method: does it fullfill the
representative criteria?

AFAIUI the Concordet method allows this (please correct me if I'm
wrong):

We have two groups of people, A and B. A has 20 people, B 10. A fields
candidates a1, a2 and a3, and B fields b1, b2 and b3. We are about to
elect three people.

All A people post ballots a1,a2,a3,NOTA,b1,b2,b3, and all B people
post ballots b1,b2,b3,NOTA,a1,a2,a3.

In your suggestion the first three people to be elected would be a1,
a2 and a3, as they all beat all B candidates. In a representative
election a1, a2 and b1 should be elected, instead.

-- 
* 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: Social Committee proposal text (diff)

[Josip Rodin]

On Mon, Feb 12, 2007 at 11:11:16AM +, MJ Ray wrote:
> The above power seems daft.  soc-ctte deciding that farting loudly in
> DebConf dinner attendees' faces is a social norm would not make it so.
> This power needs omitting or rewriting to be much closer to the
> equivalent tech-ctte one, so it does not permit contradicting reality.

Er, did you notice the part where it (copied and pasted from tech-ctte) says
that it only chooses from available solutions already thoroughly discussed?

So if developers were actually seriously arguing whether farting loudly in
DebConf dinner attendees' faces is a good idea, and they decided to bring it
to the consideration of the soc-ctte, the committee should be able to decide
on that :)

Note that someone could also submit the opinion that such an opinion is
daft, and then the soc-ctte could decide so.

-- 
 2. That which causes joy or happiness.


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

Re: Social Committee proposal text (diff)

[Josip Rodin]

On Mon, Feb 12, 2007 at 11:38:12AM +0100, Alexander Schmehl wrote:
> * Josip Rodin <[EMAIL PROTECTED]> [070212 03:32]:
> 
> > +  During the following month, any Developer may nominate
> > +  themselves as a candidate member of the Social Committee.
> > +  Every such nomination must be seconded by one other developer.
> 
> Any specific reason for having a full month as nomination period?

Think of scale - right now we need 16 people to 'win' the election, and
the seats last twice as long as the leadership seat. It made sense to me -
please say if it doesn't to you.

> > +  The next two weeks are the polling period during which
> > +  Developers may cast their votes.  Votes in social committee elections
> > +  are made public after the election is finished.
> 
> And why shall votes become public?  What's voting about, if not done in
> secret?

The secrecy is not the point - the point is that we make a cross-section of
society, a sample of people who are at least vaguely representative.

I don't see any reason against disclosure.

> > +  At least one third of all elected candidates should have been
> > +  members of the project for at least Y/2 years, where Y is the age
> > +  of the Project in years. If fewer than one third of candidates meet
> > +  this requirement, the election process is repeated.
> 
> An native english speaker may corect me, but "should" is normaly used in
> a kind of "would be very fine if, but not strictly necessary" meaning,
> isn't it?  So why first using "should" and later "if not, then we do it
> again"?

Well, it's just a matter of wording. (This is not an RFC, BTW.)
Many other sentences just use 'is', and I think that's a bit strange :)
But I should probably make it consistent, you're right.

> And why that rule?  I would think in a social ctte, fresh blood is very
> welcome, because they (probalbly) haven't taken part in any flamewar and
> therefore are the best to choice for a ctte, that should be as objective
> and neutral as possible?

Yes, and they can very well occupy the other 66% of the committee :)

And I disagree that someone like that is inherently a best choice, because
they might also not have any experience. Experience is generally a good
thing.

> > +  
> > +Public discussion and decision-making.
> > +
> > +Discussion, draft resolutions and amendments, and votes by
> > +members of the committee, are made public on the Social Committee
> > +public discussion list.
> > +There is no separate secretary for the Committee.
> > +  
> 
> So a member of the social ctte may not talk to an other member of the
> social ctte about topics of the social ctte?  Even if they meet in
> person?
> 
> An other point, where I fail to see the reason for it.  AFAIK the tech
> ctte has private list for discussion,

Umm, no. This is copy & paste from the Technical Committee section.
Their discussion list is (also) public.

> and I would think that social problems / discussions should be considered
> even more private.

I disagree - if a problem is severe enough to get brought before soc-ctte,
it's out in the open already, and needs to be dealt with transparently.

-- 
 2. That which causes joy or happiness.


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

Re: Social Committee proposal text (diff)

[MJ Ray]

Josip Rodin <[EMAIL PROTECTED]> wrote:
>The Technical Committee and/or its Chairman;
>  
> +  The Social Committee and/or its Chairman;
[+ many similar additions]

Alternatively, just s/The Technical Committee/A constitution-defined
committee/ where applicable.  I think adding soc-ctte analogues to
most mentions of tech-ctte makes the constitution significantly less
readable.

[...]
> +  
> +Decide on any matter of social policy.
> +
> +This includes social norms and customs, non-technical communication
> +among developers, and day-to-day organization matters within the Project.
> +
> +  

The above power seems daft.  soc-ctte deciding that farting loudly in
DebConf dinner attendees' faces is a social norm would not make it so.
This power needs omitting or rewriting to be much closer to the
equivalent tech-ctte one, so it does not permit contradicting reality.

[...]
> +  At least one third of all elected candidates should have been
> +  members of the project for at least Y/2 years, where Y is the age
> +  of the Project in years. If fewer than one third of candidates meet
> +  this requirement, the election process is repeated.

Repeated an infinite number of times?  Cool DoS.

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: Social Committee proposal text (diff)

[Josip Rodin]

On Mon, Feb 12, 2007 at 10:49:51AM +0200, Kalle Kivimaa wrote:
> > +The Social Committee may ask a Developer to take a particular
> > +social course of action even if the Developer does not wish to;
> > +this requires a 3:1 majority.
> 
> OK, what happens if the Developer doesn't take the required course of
> action? With the ctte it is easy, somebody does an NMU, but I don't
> see how you can do something similar in social situations.

Well, the short answer is, we deal with it the way we deal with it right
now, just with some official approval.

But, this is a reiteration of the desire for examples, which is
understandable. Here's one that I can think of - soc-ctte could be asked to
rule on whether some developer should be gentler on bug report submitters
without closing bugs immediately, or without yelling at them, or something
like that. In that case, the overriding mechanism would be for people to
reopen such bugs, but the committee could still issue a formal request that
the said developer refrains from being trigger-happy, and perhaps authorize
the BTS admins to freely lock out the 'close' function for that person if
they transgress.

I could also imagine how a similar dispute would be handled with regard to
mailing list abuse - someone could petition the soc-ctte to have a couple of
conflicting developers take a never-ending flamewar off-list.

> > +  At least one third of all elected candidates should have been
> > +  members of the project for at least Y/2 years, where Y is the age
> > +  of the Project in years. If fewer than one third of candidates meet
> > +  this requirement, the election process is repeated.
> 
> Like Lars already said, this becomes an impossible requirement sooner
> or later.

(Replying to both) Right. I didn't remember to consider that.

Maybe change to:

+  PY is the age of the Project in years. SY is PY/2 or 10,
+  whichever is smaller.
+  At least one third of all elected candidates should have been
+  members of the project for at least SY years.
+  If fewer than one third of candidates meet this requirement,
+  the election process is repeated.

> A five year rule would be better, but even then this rule may result in an
> impasse, if we don't have enough qualified candidates who fullfil the
> requirement.

I pondered this a bit. In the current setting, it would require six out
of sixteen seats to be filled that way. I don't think it should become a
problem, but if you think it will, maybe the ratio should be reduced to 25%
or something like that.

I actually think that getting 16 candidates over 'none of the above' marker
might be a bigger problem :)

-- 
 2. That which causes joy or happiness.


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

Re: Social Committee proposal text (diff)

[Josip Rodin]

On Sun, Feb 11, 2007 at 10:59:15PM -0600, Manoj Srivastava wrote:
>  1) When do developers need to implement social stances or policies?
> Can you give an example of the kinds of things the constitution
> may be talking about here?

While copying and pasting :) I was actually puzzled at the amount of
examples that were cited for the technical committee. I admit I don't have
any so straightforward examples, but then, it was pretty late when I wrote
that.

I'll have to ponder on it before suggesting an example, because it would
have to be worthy of being cemented into the constitution :)

>  2) What happens  if only some  of the paticipants in a social, umm,
> tussle, want to submit the affair to the soc ctte?  Once referred,
> are all other parties now subject to the soc ctte rule?

Hm. I have no idea. What happens in the case of the technical committee?
I don't think I changed anything with regard to issue scope.

>  3) When a developer is over ruled on a technical matter, the tech
> ctte can not force a developer to do something they do not want to
> do (the developer can't stop other people from doing the task --
> no active work against, etc).  Do similar clauses apply to the soc
> ctte?

Yeah, but this is governed by the same general rules section, 2.1.1.

-- 
 2. That which causes joy or happiness.


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

Re: Social Committee proposal text (diff)

[Alexander Schmehl]

Hi!

* Josip Rodin <[EMAIL PROTECTED]> [070212 03:32]:

> +  During the following month, any Developer may nominate
> +  themselves as a candidate member of the Social Committee.
> +  Every such nomination must be seconded by one other developer.

Any specific reason for having a full month as nomination period?


> +  The next two weeks are the polling period during which
> +  Developers may cast their votes.  Votes in social committee elections
> +  are made public after the election is finished.

And why shall votes become public?  What's voting about, if not done in
secret?


> +  At least one third of all elected candidates should have been
> +  members of the project for at least Y/2 years, where Y is the age
> +  of the Project in years. If fewer than one third of candidates meet
> +  this requirement, the election process is repeated.

An native english speaker may corect me, but "should" is normaly used in
a kind of "would be very fine if, but not strictly necessary" meaning,
isn't it?  So why first using "should" and later "if not, then we do it
again"?

And why that rule?  I would think in a social ctte, fresh blood is very
welcome, because they (probalbly) haven't taken part in any flamewar and
therefore are the best to choice for a ctte, that should be as objective
and neutral as possible?


> +  
> +Public discussion and decision-making.
> +
> +Discussion, draft resolutions and amendments, and votes by
> +members of the committee, are made public on the Social Committee
> +public discussion list.
> +There is no separate secretary for the Committee.
> +  

So a member of the social ctte may not talk to an other member of the
social ctte about topics of the social ctte?  Even if they meet in
person?

An other point, where I fail to see the reason for it.  AFAIK the tech
ctte has private list for discussion, and I would think that social
problems / discussions should be considered even more private.

Why not some kind of "draft resolutions and amendments, and votes by
members of the committee, are made public on the Social Committee public
discussion list. Discussion is made public to those the parties involved
or at their unison request to all."?


I'm still not sure, if I like the idea, and how a social ctte should
work... but that are the points I would to see adressed before
considerering not to vote against such a change ;)


Yours sincerely,
  Alexander



signature.asc
Description: Digital signature

Re: Social Committee proposal text (diff)

[Kevin Mark]

On Mon, Feb 12, 2007 at 10:49:51AM +0200, Kalle Kivimaa wrote:
> Josip Rodin <[EMAIL PROTECTED]> writes:
> > +The Social Committee may ask a Developer to take a particular social
> > +course of action even if the Developer does not wish to; this requires
> > +a 3:1 majority.
> 
> OK, what happens if the Developer doesn't take the required course of
> action? With the ctte it is easy, somebody does an NMU, but I don't
> see how you can do something similar in social situations.
Begin a member of the Debian project is a privilege. In the US, having a
drivers license is also a privilege. If you do something wrong, the can
be given a 'warning', you can have 'points' added to your driving
record, you can be temporarily suspended, etc. In most cases, there
may be a person in the project to continue work on a persons package or
even a maintainer outside the project who can be sponsored to continue
work. So a persons work on a package can be restricted if someone
wished. I could site a certain person who shall be nameless as an
example. But there is a certain reluctance to do this in a volunteer
project because you'd be restricing someone's volunteer time activity
which is something that has a certain scarcity to it and not to be
wasted. Not to mention the effect it could have on their future
participation. So when is Debian willing to take any action in regards
to limiting someones involvment? It seems certain volunteer organization
like say the Red Cross have a clearer idea of this. Debian less so.
-- 
|  .''`.  == 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 keysever: subkeys.pgp.net | my NPO: cfsg.org |


signature.asc
Description: Digital signature

Re: Social Committee proposal text (diff)

[Kalle Kivimaa]

Josip Rodin <[EMAIL PROTECTED]> writes:
> +The Social Committee may ask a Developer to take a particular social
> +course of action even if the Developer does not wish to; this requires
> +a 3:1 majority.

OK, what happens if the Developer doesn't take the required course of
action? With the ctte it is easy, somebody does an NMU, but I don't
see how you can do something similar in social situations.

> +  At least one third of all elected candidates should have been
> +  members of the project for at least Y/2 years, where Y is the age
> +  of the Project in years. If fewer than one third of candidates meet
> +  this requirement, the election process is repeated.

Like Lars already said, this becomes an impossible requirement sooner
or later. A five year rule would be better, but even then this rule
may result in an impasse, if we don't have enough qualified candidates
who fullfil the requirement.

-- 
* 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: Social Committee proposal text (diff)

[Lars Wirzenius]

On ma, 2007-02-12 at 03:32 +0100, Josip Rodin wrote:
> +  At least one third of all elected candidates should have been
> +  members of the project for at least Y/2 years, where Y is the age
> +  of the Project in years. If fewer than one third of candidates meet
> +  this requirement, the election process is repeated.

When Y=300, we need at least S2/3 people who have been members of the
Project for 150 years. At some point, this paragraph needs to be
amended.

Personally, I would rephrase it as "- - - for at least 5 years. If fewer
than - - -".

The rest I do not comment on at this time.

-- 
The difference between appealing and appalling is very small.


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

Re: Social Committee proposal text (diff)

[Manoj Srivastava]

Hi,

I have a few questions about this proposal.

 1) When do developers need to implement social stances or policies?
Can you give an example of the kinds of things the constitution
may be talking about here?

 2) What happens  if only some  of the paticipants in a social, umm,
tussle, want to submit the affair to the soc ctte?  Once referred,
are all other parties now subject to the soc ctte rule?

 3) When a developer is over ruled on a technical matter, the tech
ctte can not force a developer to do something they do not want to
do (the developer can't stop other people from doing the task --
no active work against, etc).  Do similar clauses apply to the soc
ctte? (If not, this is a significantly stronger power)

manoj
-- 
How many WASPs does it take to change a light bulb? Two.  One to
change the bulb and one to mix the drinks.
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]