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 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]