Social Committee proposal
Hi,
This idea arose from a discussion on the -private mailing list.
Andreas Tille, Gustavo Franco, Manoj Srivastava and Gunnar Wolf all
commented fairly positively on a vague idea of having a social committee
(soc-ctte), different from the technical committee (tech-ctte).
I'm citing their names simply to avoid an issues with taking credit.
I'm re-posting my text to debian-project so that this worthwhile idea is
not kept secret and/or lost in the noise at the other list.
-----
I also think that a social committee would be a good idea.
Even if unrefined and/or undefined, just the notion of having both
a technical and a social committee would indicate major progress in
our way of thinking.
Let me try to shape this idea by citing the constitution and proposing what
the text of the constitution could be with regard to the proposed social
committee.
The Project Leader may:
Appoint Delegates or delegate decisions to the Technical Committee.
Lend authority to other Developers.
The social committee could have its own delegations. The most obvious
example that springs to my mind would be delegating one or more
communications coordinators for this-and-that mailing list, or for this and
that team in Debian. These delegates would have one little bit more of an
authority to talk about those issues; on the other hand, they could be
required to earn this privilege by being entrusted the task of monitoring
all discussions on a list and making sure that no complaint goes unnoticed
or unsolved, be it from a user or between developers.
The committee should have in its charter the demand to avoid appointing such
people out of the blue. Instead, it should by default act only when other
developers request assistance from the committee on a particular matter. It
could choose to intervene in some situation ad hoc, but then the leader
should be allowed to halt such intervention if he decides that the soc-ctte
was being too nosy. (This safeguard could be abused by the leader to
obstruct the work of the soc-ctte, but the veto could easily be worked around
in case of real problems by having other people bring the discussion up with
the soc-ctte.)
The delegation of decisions to the technical committee should also be
included in the charter; if the soc-ctte can't decide (with a majority of
votes) whether an issue is not technical but social, it should defer
judgement.
Continuing with the constitution citation...
Make any decision which requires urgent action.
Make any decision for whom noone else has responsibility.
Propose draft General Resolutions and amendments.
Maybe skip anything like these until we have more experience.
Lead discussions amongst Developers.
The Project Leader should attempt to participate in discussions amongst
the Developers in a helpful way which seeks to bring the discussion to
bear on the key issues at hand. The Project Leader should not use the
Leadership position to promote their own personal views.
This would work for soc-ctte, too.
As far as appointment, we could try all the same for soc-ctte.
Except two things:
* keeping votes secret - maybe they should not be secret.
* soc-ctte members should serve two years or more.
Section 5.3 Procedure should apply, too.
Comparing with section 6., Technical committee, let's see:
Decide on any matter of technical policy.
This includes the contents of the technical policy manuals,
developers' reference materials, example packages and the behaviour of
non-experimental package building tools.
This one could be tricky to phrase. Maybe - "Decide on any social matter,
including social norms and customs, non-technical communication among
developers, and day-to-day organization matters within the Project."
The points 6.1.2. through 6.1.7. should all be included, with
s/technical/social/g or so.
The Chairman can stand in for the Leader, together with the Secretary
As detailed in §7.1(2), the Chairman of the Technical Committee and
the Project Secretary may together stand in for the Leader if there is
no Leader.
Adding this could be postponed for later, or just skipped altogether, to
avoid the impression that soc-ctte election is a shadow leader election or
anything like that.
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.
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).
The rest should be either copy/pasted from tech ctte or omitted for obvious
reasons.
--
2. That which causes joy or happiness.
Reply to: