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 barrier to the leader
messing with the delegates' _decisions_ would apply. The leader would
I think be adequately inhibited from randomly messing with the
committee.
> * 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
I don't think we agreed on this. I think the right approach would
seem to be for people to come forward to the DPL, who would filter the
candidate list and the put it to a vote.
> * The consensus on later changes to the committee was that it should not
> be done often in general,
I think in the end we agreed on:
- approval voting for the whole committee each year
- members thrown out in this way are replaced by straight appointment
by the DPL
- the DPL's replacements will not be voted on that year
Presumably retiring members can be replaced by the DPL in the same
way.
Ian.
Reply to: