[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 (press@d.o, secretary@d.o, 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-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.

In the case of the technical committee, the leader serves as a
democratically elected person who can veto prospective members
which are proposed by the existing committee itself (those oligarchs! :).
In the case of the social committee, we don't need that democratic
influence, because the members are already democratically elected.

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

Now, there's a problem - while social issues are definitely a matter for
which we *previously* used the leader debates and elections and all that,
that doesn't have to be that way. We simply had no other democratic venue
for them.

The social issues (as in, how people get along) should be handled through
the committee which will have its own democratic venue(s).

Whereas, the leader should be left with issues more relevant to that
position - leadership, governance, management, etc.

The leader can still participate in the resolving of matters though the
social committee, he just doesn't have to be an authority on them.

(Indeed, there is no explicit basis in the constitution to give the leader
such authority over these issues, only the implicit basis through §5.1.4).)

-- 
     2. That which causes joy or happiness.



Reply to: