Markos Chandras schrieb:
> On 08/14/2011 01:15 PM, Thomas Sachau wrote:
>> Markos Chandras schrieb:
>>> 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.
>> My first question: Why is your proposal restricted to QA and DevRel?
> Cause I believe these teams are crucial to the continuity of Gentoo
How do you weight one project against another one? I see it the other way round: QA and DevRel are
only important, if there is some issue not resolved otherwise. But many other projects are always
important, since they have to maintain things continuously.
While the council could still decide, if DevRel or QA are gone (they just take some workload away),
you wont be able to get the council to e.g. maintain our infrastructure, ebuilds or docs.
>>> 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.
>> If there is noone active in a team, noone prevents other devs to join
>> the team and vote themselves for the lead. So even if there is no
>> activity, it should be no problem to get activity, if someone is
>> interested to do the work.
> Right now, you can't join any of these teams unless a lead approves you.
> Have a look at gentoo-qa ML.
Please re-read my lines. I talked about _noone being active_. The QA team is not empty/inactive,
neither is DevRel team empty/inactive, so this does not apply to the current situation.
>> If the team is inactive and noone interested, the Council wont be able
>> to create any activity either, since they cannot force anyone to do
> You can't just join a dead team and become a lead :). There are some
> bureaucracy procedures to follow.
You cant? who prevents you from doing so? And if there are just some procedures to follow, this just
means some initial activity/workload to do so, but again: If the team is dead, who could prevent you
from joining it and then becoming the lead?
>>> 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. Membership and voting actions should not be
>>> related in these teams.
>> How is this specific to those 2 projects? Other projects do work the
>> same way, so if you argument this way, you should extend your
>> proposal to all projects, not just QA and DevRel.
> Like I said, these are the crucial projects. This is because they manage
> procedures affecting inter-project related issues etc.
I have to disagree about the importance of those 2 projects. The most important work done by those
teams is fixing minor issues, being either technical issues or inter-personal issues. While those
teams can make a decision, this is never final, you always have the option to go to the council,
which is elected by the dev community and has the final decision. So i would see those projects more
like some delegation of work to people interested in doing the work in that area, while the council
still has the last word.
And, as a side note: Only a very small minority of devs is even willing and able to do the work of
those projects, so a regular council voting would effectively change nothing beside adding some more