-----BEGIN PGP SIGNED MESSAGE-----
On 08/14/2011 03:19 PM, Roy Bamford wrote:
> I'll stir the pot a little. No flames please, after all, we are just
> brainstorming, or to be PC having an idea shower.
Nobody is flaming :)
> On 2011.08.14 12:06, Markos Chandras wrote:
>> Hi all,
>> This is the first of the items I would like to discuss for the
>> next Council agenda (or a later one).
>> Some time ago, few people proposed to have Council appointed
>> leaders for QA and DevRel. I like the idea because this way the
>> Council can ensure that the team is active or either force some
>> activity in case the current leader slacks big time.
> The concepts of appointing leaders and monitoring activity are not
> linked. In my view a council appointed team lead is unlikely to do a
> better job than one elected by the team. Choice of leader is
> therefore no different to any other project.
This should be the case, but what happens when the leader is inactive?
Nobody is there to control the team or to force elections. Moreover, who
is eligible to decide whether a lead is slacking or not. There is no
definition for "slacker". With my proposal, the council will avoid all
the chit-chatting ("are you active?", "yet I am", "no, it doesn't seem
so" etc ) and bureaucracy that is required before someone takes action.
> Council may want to have some documented authority to take drastic
> action in the case of slacking but that's separate again from
> appointments and monitoring. Council would need to monitor to know
> when drastic action was required.
> In short, --Routine_Appointments, ++Monitoring ++AuthortyToAct
Well, what would that authority do? Report slacking teams? And then
what? We still need some drastic action from the Council.
>> Furthermore, right now there is the potential problem for the
>> leader to only allow new members that he likes so they can vote for
>> him on next elections.
> We already have an appeal to council process that should be used.
> I've formed the impression that these teams are as understaffed as
> any other area of Gentoo, so no *competent* help should be refused.
projects relations are not only horizontal but vertical as well. You
can't possibly claim that the e.g virtualization@ project is as
important as the QA team is.
> How competent is judged needs to be documented by the teams - e.g. a
> quiz and a practical under supervision before volunteers are turned
>> Membership and voting actions should not be related in these teams.
>> The leader will still have control over the new members but
>> Council will do the voting (community will provide feedback ofc )
> What do you mean by control ?
Which members can join the project and which can't
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
-----END PGP SIGNATURE-----