-----BEGIN PGP SIGNED MESSAGE-----
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
>> 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.
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
-----END PGP SIGNATURE-----