Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
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]
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]
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]
On Wed, Jun 27, 2007 at 01:27:00PM +0200, Jacobo Tarrio wrote: > > Just nitpicking, but is our Condorcet method for running election > > suitable for voting when an (ordered) set of result is expected? Isn't > > it targeted at finding only one winner (if it exists)? Not a big > > It's targeted to finding the one winner, but it's easy to adapt to finding > a list: get the winner, then remove it from the list of options and get the > new winner, then remove it from the list of options and get the new winner, > etc. I never proposed that, for reasons made obvious by other people in the thread. My ammendment to the standard resolution procedure was this: +If the election requires multiple winners, the list of winners is +created by sorting the list of options by ascending strength. Instant disclaimer - I don't know if this is clear enough, I don't know voting method syntax. The point is that the list of options is *sorted*, and then N are taken as winners. It's not run in a loop of N iterations. And by "sorted" I mean the thing we get from the beat matrix, such as in: http://www.debian.org/vote/2007/vote_001#outcome If for example in that outcome we wanted to pick four candidates, it seems to me that they would be Hocever, McIntyre, Herzog, Verhelst. If for example we wanted to pick seven, we couldn't go past the first six. In that graph, no two options happened to be at the same horizontal level. If by any chance we got that situation, my ammendment further stated: +If there are multiple winners with the same ranking which exceed +the desired length of the list, the length of the list is extended +to include the entire last set of multiple winners. I thought that that made sense. Others? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
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]
* 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]
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]
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]
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]
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]
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]
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 resolution vote should be held,
> one that would make a formal statement establishing soc-ctte, in order
> to give the idea full-blown credibility
We agreed, I think, that the constitutional
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
