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 (press@d.o, secretary@d.o, 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 of the team)
- 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%.
- the DPL can modify its constitution at any time (which is OK since the
DPL election is the right time to discuss this problematic, and the DPL
should clearly have an opinion on this topic)
> 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?).
Replacements are done by the DPL. So if there's campaigning to do, it must
be directed to the DPL. I don't see the need to have another vote.
Your summary was quite good overall. You spoke of all points where I had
taken some notes. :-)
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: