Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Wed, Jun 27, 2007 at 10:22:04PM +0100, Ian Jackson wrote:
> > 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).
In the second case, I think it's best that they still Cc: a second private
alias, one kept in a directory that is readable only to soc-ctte members.
That will keep it out of the general view and the view of thousands of
developers, but there will still be a clear record of it.
> > 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
I'm not sure why this flexibility is necessary. Granted, it's a new body
and we don't know if it will implode and take down the universe, but
I really believe that we can set it up sufficiently right from the start
that it doesn't require a 'nuclear button'.
> and 2. a clear backstop limit on the SC's powers
> (which are necessarily derived from the DPL's).
Once the GR approves the committee, the powers are derived from the
developers in general, not just the leader. I argued this before - just
because the leader is theoretically in charge of this stuff right now
under the constitution, that doesn't make it his powers, because they're
not used (for whatever reason).
> > 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.
Erm, excuse me, but my original proposals from months ago were exactly that,
and the people who commented then seemed to like it (at least sufficiently
enough for none of them to actually voice a negative opinion on the whole
concept of voting them!).
Please refer to the earlier threads on this mailing list:
http://lists.debian.org/debian-project/2007/01/msg00063.html
http://lists.debian.org/debian-project/2007/02/msg00055.html
--
2. That which causes joy or happiness.
Reply to: