Re: [gentoo-project] Council appointed leaders for QA and DevRel

[Markos Chandras]

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

On 08/14/2011 05:07 PM, Thomas Sachau wrote:
> Markos Chandras schrieb:
>> 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.
>
> If QA or DevRel slacks, this causes even less work, since they dont
> even maintain ebuilds to mask and remove. It may result in less QA
> fixes or less mediation between developers, but in any case, where
> you need a decision, you could always call for the council. Those
> projects do just some delegated work, which is of course nice, if it
> comes to the daily work and also, because it reduces the work, that
> needs to be done by the council. But neither is unreplaceable and the
> decisions of both teams can already be checked by the council, so i
> see no real requirement for additional bureaucracy for those 2
> specific teams.

I am not talking ajust about decisions. If QA slacks then will then
Council step up and maintain the QA in the portage? If devrel slacks
then will the Council do all the recruitment/retirement? These projects
are vital for the project. I don't know how to explain that in more details.

>
> Either you want to move more control to the council, then it should
> do the checks and votes for all teams or you leave it like now, where
> the teams do decide themselves.
>
>> 2) Infrastructure is a sensitive team, and does not deal with
>> ebuild maintenance and portage directly.
>
> And if infra slacks? Bad luck for you, just mask and remove the
> hardware? :-)
Like I said, this is not related to portage QA. I only care about the
/usr/portage/* parts and what users see from "outside"

>
>>>>>> 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.
>
> Maybe you should first tell me, how you define activity for QA (and
> DevRel)?
Ok, and active QA team is a team that fixes severe and other QA problems
within 24 hours. Moreover, an active QA team should be there 24/7 for
someone who needs an advice for them or needs to complain about a
developer that broke portage. If QA was active the breakages from
Arfrever's commits would have been spotted months before a severe
incident occurs.

An active devrel, means fast procedures on conflict resolutions (
yngwin's case took 14 months and the decision was made after he was
retired ), continuous retirement process, etc
>
>>>>> 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?
>
> I would see a project as "dead", if there is no activity at all, also
> there is a need for activity (like open bugs for an ebuild, which
> never get processed or no newsletter sent out at all).
 This goes a bit OT, but if a project is dead the council MUST find a
solution to that problem. Creating activity is not the only solution.
Announcing the removal of dead projects along with their packages is a
more realistic solution. Recent example, the zope herd that nobody
notice they were dead until 2 days ago. Ugh...
GWM, zope, media-optical, etc etc[1] are dead long time ago.

http://www.gentoo.org/proj/en/metastructure/herds/herds.xml

We need to come up with a solution for dead projects, but this is OT to
the current thread. If someone wants to discuss this further please
change the title and split the threads.

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

iQIcBAEBCgAGBQJOR/WkAAoJEPqDWhW0r/LCJncQALJh9TJ/lPnl6yUkPS17Gxri
kOpQRyOjYmlTpHBZe/hVsJ65Cj0n7H1t3/rjDIOfLMZQgiRUzK+s5AW03SjfNMwP
w0W3SHGAZsYYXxQ3mX5zk8/JtV3LMWhG4JTNC4Set07PVqQQBN5Ky6w8h2fP8Ho5
sG4ZShVeXJtBMKwFyutB5Wjc67THxE+Hn5l8pOOvth+/rKbsnkue+mYvkIP+sicW
kZukdyW66lclS0reTtOjqxHuvCI1nSiv/3lXZi7BiK/6b6TwBfTZL6BDlNgikBJe
EoMF1SZrljbXYb7zhgpISC2ihuQAH3aMC7Nrr9NUuGVBUGZnJ9WFkiO7CTwGZ4Rn
fB7fr1jlagSdzsjaf12VFKLjVS5fUNSQ6wK+pNY/lrmdNO8ioh1QPKmwrz11VT1H
NCKOrMIzmRIa05dV9AIm6tx1174EnVpxopVlS11oGkKyWujPRxOimd8BzS7xZHTc
nGVrktKXc3vLq/NAcYBpYZtYhvojZsJW7JR27h5GYYn6xh8Q4z4iL+6yRo3SmFCO
9FYjIidZVcRK1zIF/e+B02peMgUJPLRIyxpV+LZgR2pQAOTRIePWjLr7tLfSMCnP
iQjy4el/HjyHPfwhNETVDaKAoKLUwRM3teE2295z9ZlZ1k6Dh/IpZG1kOa1eszBf
+uvke5EX06QtuPFGC3ah
=D4Yx
-----END PGP SIGNATURE-----