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.
Reply to: