-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 08/14/2011 02:07 PM, Thomas Sachau wrote:
> 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 project.
> 
> 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.
> 
1) If another project slacks, then bad luck for you. Just mask and
remove the ebuilds ( see recent zope thread ). There is nothing we can
do about that.
2) Infrastructure is a sensitive team, and does not deal with ebuild
maintenance and portage directly.
3) I am not sure what is the problem with docs. There are understaffed
since I remember but it is not crucial to project continuity since most
projects maintain docs on their spaces as well.

>> 
>> 
>>>> 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.
Well, clearly we have a different definition for the word "active". If
you think that QA is active then there is no reason for me to try to
convince you for the opposite.

> 
>>> 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 something.
>> 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?
Existing members, who claim to be active, may prevent you. Remember what
happened last time Patrick tried to resurrect GMW, and all of a sudden,
Joshua claimed that he can't do that because he wasn't the lead.
Unless I misunderstand your definition for "dead" word. You mean empty
project pages? Or just pages with 14 members and 0 commits/year?

> 
>>>> 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.
If you have a dead QA team, then you suck as a project. If you have a
dead recruitment team then you such as a project. But if you have a e.g.
deal perl team, then you just can't support perl, which is bad, but not
as bad as not having QA/Devrel up and running.
> 
> 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 bureaucracy.
> 
Bringing council to the game, ensures that these projects will be active
and managed at a senior level. Right now, there is no recovery plan if
these teams do not function properly.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJOR8/nAAoJEPqDWhW0r/LCLroP/0C73ckKNUZtuZKuoxzOp2o9
yY6IkTyfAbUkI4TI7Y5LV2AAkWEw9SxPFBZPZBQfbdCGTD4L5CuFzMz0CHKynMMm
yKZxTjgoKCXOVCgDJX3QVH3K220ydtpWyYShjnd5zm1S+u52cKADXW1B5x643WTX
2Eb9BZEd23tjkccXqZW1bHRVP+FbtTB5rrmozF3cRxQUOyCKtyRVlmWBfvvOKelc
2hFfKGyj2kvkSjrmM4zTUS+nw3EEXBzq3DRMWqa6adyC1o9urnkHNuls0CQhuS2Q
7NiyfK4vRM3mmXZ/Ay5gFjPldZKVaufnIDXmVmOxT2opK6dcw3dFRZZArRlalqcH
F8iHQbEAc1aRqhdHjarqjEHAQ9uO5WhK5Jch4afSEEBP7LQDp5aU1dt4mDFc5h1n
ls+oF7Vru6/Do1+p5+6XkDwFniMMmA/gZ7f8rgk+uNGSK+6nAuNNjEaEmbvyj0Ok
XGdlr/Z++8vhjcEj6QbPWe4I51i7hVUhfLV8nlIGb1z1ZCDweka7wGQQVxHu7zKk
Sfj+UffCOKBbJdj+zvMvD/X9AKJ2VL0zJD4TpEY7tgYLZV7xxF7bWEj3ZWTLpzyg
MQodaZ+U+UWgW7s6WOP0YeRz1IHyCUjlIg1P+E7qGlHNP3Ly7e3I87KzNRMIs0nK
MYnN9li08SvXi00PD+Gh
=EUFy
-----END PGP SIGNATURE-----