Re: Social Committee proposal
On Fri, Jan 26, 2007 at 09:29:41AM +0100, Raphael Hertzog wrote:
> I like the principle, but IMHO it should just be a DPL board or something
> similar. Otherwise I really don't see the point of the committee.
> A good board would integrate people from the various important offices
> (listmasters, ftpmasters, DSA, security, RM, DAM, ...) but that shouldn't be
> It's much simpler to take important decisions within a board: when you're
> alone as DPL, you fear taking the wrong decision and end up taking no
> decision. Within a board, it only needs one person motivated enough to
> bring an issue to a vote and get a result that is way stronger.
That's tricky when it comes to social relations. It only takes one person
motivated enough to sway opinions in what others may think is the wrong
direction. That would be detrimental - just like the technical committee
doesn't really *lead*, the social committee shouldn't lead, either.
It should offer assistance and guidance, but not too much beforehand.
> With such a team you also have a broader coverage of the Debian community,
> and potential problems can be discovered more quickly.
> I blogged on the topic in the past:
That's interesting, and it's probably worth considering, but again, it deals
more with leadership than anything.
> > As far as 6.2. Composition is concerned, I would think that the soc-ctte
> > should be allowed to be rather large, growing comparably to the growth of
> > the developer body. After all, its emphasis can't really be on leadership, I
> > would think that we would want to have a decent sample of the developer body
> > in it.
> In that case, you need to have decision mechanism that scales accordingly:
> votes are open for a short period of time (let's say 4 days) and the
> quorum for a vote ought to be relatively slow because on a large group,
> you'll have always 1/3rd to 50% who are on business trip, on vacation,
> busy, whatever.
I figured that having the same voting time and quorum as the leadership
election. You are right that it tends to draw out, but it's less of a
problem if the positions last over a year. You want to give people ample
time to get back from whatever distraction and help decide the membership
of the committee for the next two years.
The reason why I think this should last longer than one year is that there
is no need to have yet another yearly election (it would end up just
irritating many people) and since project is already over ten years old, we
are fairly certain :) that it's going to be around in over one year's time
for the next soc-ctte election.
> > Maybe the limit should be a third of the election quorum, or
> > sqrt(number-of-devels)/2? Currently that would be 16 people. I think that's
> > a good sample of people, and a workable audience for a mailing list (of
> > soc-ctte). Even if we expand twice in size, that's still just 23 people
> > (i.e. the ctte would not grow twice as large).
> I find that number rather large. Around ten people ought be enough. But
> then I don't mind trying :)
Yes, I agree it's large for a *team*. Conventional wisdom says 5 or 7 people
are best for teams. However, this is not a team :) It doesn't need to be
streamlined; in fact, it probably *shouldn't* be streamlined, as it is
supposed to cover a wide spectrum of people and opinions.
> I would like if we could bring such a proposition to vote before the DPL
> election of this year (because of the obvious consequences on the election
You mean, we couldn't elect one person for both positions?
2. That which causes joy or happiness.