Hi André, all,
First I would like to thanks Michael for his proposal and Cor for the
summary here.
André Schnabel wrote:
Hi Cor, *,
Cor Nouws schrieb:
....
The original proposal can be found in the archives: see
http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=22513
...
The current structure of the CC, voting and so on, is explained on the
OOo website. See: http://council.openoffice.org/CouncilProposal.html
chapter IV
The major difference between the current en proposed structure is that
currently voting for the most seats is done by project leads and in
the proposed structure can be done by all members who contribute
code/art/translations to CVS.
I'd like to make some comments on the current situation (and derive a
modified proposal from this).
- At the moment eligibilty is to much limited to a set of formal
terms (like project-lead) .. also see request from Charles (make
cathegory leads eligible)
- Active project leads have hardly time to do both: maintain a project
and do a good job at the council (see discussion at [EMAIL PROTECTED] and
John's comments)
both leads to a situation where it is hard to find candidates for the
council. And if we have candidates, it is hard to find deputies (who
should per defintion be eligible for the same seat).
The problems I see in MM's proposal:
- the mentioned metrics for the voter register is very unclear (and I
don't think, we would find a good metric that is fair for all parts of
the community)
I agree with Michael for more openness, what is disturbing me is this
relying on cvs commit. Lot of contributing members are not committers to
cvs and I even don't know how this metric could be evaluated.
- I don't like to have the voting scheme written in the charter - this
can go to the bylaws (and therefore could be more easily adopted or
modified)
agreed
So .. my proposal:
- leave the structure of the council as it is (1 CCR, 2 NL, 5 Project
Leads, 1 Sun)
- Structure is not defined by "who is eligible" but "who can vote"
- every project member is eligible (where project member is "Observer" -
we may restrict this to "developer in one project")
- elections willl mostly stay the same with following modifications:
- call for candidates needs to be on a public list (discuss@ for CCR,
[EMAIL PROTECTED] for NL, dev@ for Project Leads)
- anyone who is eligible can nominate herself and should introduce
herself (and why she thinks she should sit at the council) on the above
named list
- CCR is elected by all Community members,
- NLs are elected by Native Lang leads (+NL cathegory lead),
- PLs are elected by Project Leads (accepted + incubator + resp.
cathegory leads - native lang)
- other details about voting scheme are written in the bylaws, not in
the charter (so remove statements about quorum from current charter or
number of candidates)
I don't see any difference if we leave the structure of the Council as
it is currently or do you mean that roles from developers to leads are
eligible? In that last case, the structure is changed?
That leave also a large part of the contributors out of the scheme (I'm
thinking about QA members or Documentation members for example), but it
will be more open than at the moment.
goals of this proposal:
- make the council more like a bazar,not like a cathedral - what
hopefully makes the Council work more interesting for each community member
- grow the number of possible candidates (spread the "management" work
across more community members and reduce workload for single members)
- make the election pocess more open and transparent
- respect merits of contributing members (project leads)
I second all this points, the CC really needs more life from the community.
The flaws of the proposal are, that there is still much power granted to
project leads. So before electing a candidate, project leads should get
(and respect) comments from project members.
At the end, it underlines again that we don't know who are our
contributors. CVS is one metric, but we should have others.
looking forward to reading other people's ideas.
+1 ;)
Kind regards
Sophie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
