Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)

[Dane Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/29/2011 08:07 AM, Fabian Groffen wrote:
> On 28-01-2011 22:11:30 +0100, Tomáš Chvátal wrote:
>> So draft we would like to have implemented as Glep update is this diff:
>> http://dev.gentoo.org/~scarabeus/glep-0048.diff
>>
>> Please comment and help us improve the "english" of the whole document
>> so it gets accepted :)
>
> (:Nread http://dev.gentoo.org/~scarabeus/glep-0048.diff)
>> --- glep-0048.txt	2006-09-05 22:45:04.000000000 +0200
>> +++ glep-0048.new.txt	2011-01-25 13:49:38.525343000 +0100
>> @@ -34,6 +34,20 @@
>>  * The QA team's purpose is to provide cross-team assistance in keeping the
>>    tree in a good state. This is done primarily by finding and pointing out
>>    issues to maintainers and, where necessary, taking direct action.
>> +* The QA team is directed by a lead, chosen yearly by private or
>> +  public election among the members of the team. The QA team lead can
>> +  choose one member as a deputy. The deputy has all of his powers directly
>> +  delegated from the QA team lead and thus his actions and decisions should
>> +  be considered equal to those of the QA team lead. The deputy is directly
>> +  responsible only to the QA team lead.
>
> Since QA is getting lots of powers these days, I strongly object to
> this, see also my comment on becoming a QA member.  I suggest the
> following:
>
> The QA lead is yearly elected by the whole dev-community (active
> developers), same procedure as being used for a council voting.  The
> nomination is also done by developers, but they can only chose from the
> current QA-members.
>
>> +* The QA team lead must approve developers who would like to join the project. The
>> +  applicant must demonstrate a thorough understanding of the duties he would like
>> +  to perform. By accepting the applicant the QA team lead will accept
>> +  the responsibility to direct them as part of the team and will be held
>> +  responsible for any action the team member takes on behalf of the QA team.
>
> Again, I strongly object to this plan.  Instead:
>
> To become a QA member, one must be a current developer, for at least 6
> months, and one must go through a quiz.  The quiz is then evaluated by
> the QA lead or a replacing member from the QA team, in the same way as
> recruiters evaluate new developers.  The outcome of the evaluation is
> signed by the QA lead.  In case of decline of a new member after the
> evalation, the QA lead must be able to provide a written argumentation
> of this decline, which can be requested by said member or by devrel.  If
> providing such argumentation is impossible within a week after
> evaluation, QA must accept said member to the QA team.
>

I whole-heartedly disagree with this. First off, the "line in the sand"
concept is completely unnecessary in this case. It barely makes sense
when it's used on a massive scale (can't drink until 21 in the US), and
it only makes sense there because people could not feasibly be evaluated
on an individual basis. In this case, quite clearly they can. Either
they have the skills and the motivation, or they don't. Some x month
line in the sand makes no difference at all and merely slows people down
who would like to help and contribute. We have enough hurdles around
here. Why add more?

The same can be said for the quiz. If the current QA lead would like to
decide that way, it should be up to him. But on the whole it should be
the QA leads decision. Personally I think the idea is kind of crazy, and
seems like a waste of time. Evaluation can be done quite easily on a
case by case basis. Why bother with quizzes?

>> +* Any QA team lead decision can be revoked by a major opposing vote from
>> +  all current QA members. Given the nature of this action new elections
>> +  should be held within 1 month to elect a new QA team lead.
>>  * In case of emergency, or if package maintainers refuse to cooperate,
>>    the QA team may take action themselves to fix the problem.  The QA team
>>    does not want to override the maintainer's wishes by default, but only
>> @@ -50,7 +64,7 @@
>>    an interim solution and it is expected that a bug will be opened with the
>>    appropriate team to work towards a correct solution.
>>  * In the case of disagreement among QA members the majority of established
>> -  QA members must agree with the action.  Some examples of disagreements are:
>> +  QA members must agree with the action. Some examples of disagreements are:
>
> sentences are separated by double spaces, nevertheless, this doesn't
> belong in this patch
>
>>    whether the percieved problem violates the policy or whether the solution
>>    makes the situation worse.
>>  * In the event that a developer still insists that a package does not break
>> @@ -59,17 +73,23 @@
>>    made by the council.
>>  * Just because a particular QA violation has yet to cause an issue does not
>>    change the fact that it is still a QA violation.
>> -* If a particular developer persistently causes breakage, the QA team
>> -  may request that devrel re-evaluates that developer's commit rights.
>> -  Evidence of past breakages will be presented with this request to devrel.
>> +* In case a particular developer persistently causes breakage, the QA
>> +  lead may request commit rights of given developer to be suspended by
>> +  the Infra team. Devrel should then proceed to evaluate the situation, by
>> +  finding a compromise or permanently revoking those rights.
>> +* Should a situation arise where a developer causes breakage to the point
>> +  that it cannot be ascribed to bona-fide mistake, either the QA lead or two
>> +  members of the QA team can require the Infra team to temporarily suspend
>> +  access to said developer, pending analysis of the causes and resolution
>> +  to be provided by the QA team within 14 days of said suspension.
>> +  Resolution for this kind of issue is completely in hands of the QA team
>> +  and only the Gentoo Council can revisit the case.
>
> It seems I feel the same as Rich here.  I object against this policy,
> instead:
>
> After QA suspension, resolution must go through devrel with QA lead as the
> party that sets up the argumentation/evidence for said actions, and
> suggested resolution.  However, devrel will evaluate and perform the
> final statement/actions here.
>
>>  * The QA team will maintain a list of current "QA Standards" with explanations
>>    as to why they are problems, and how to fix the problem.  The list is not
>>    meant by any means to be a comprehensive document, but rather a dynamic
>>    document that will be updated as new problems are discovered.  The QA team
>>    will also do their best to ensure all developer tools are in line with the
>>    current QA standards.
>> -* In order to join the QA team, you must be a developer for at least 4 months
>> -  and must ask the current lead for approval.
>>  * The QA team will work with Recruiters to keep related documentation and
>>    quizzes up to date, so that up and coming developers will have access to all
>>    of the necessary information to avoid past problems.
>
>

I also 100% agree with Paweł. This diff should probably be separated
into 2 different diffs. One with the general structure, one with the
very controversial bit.

Personally, I think the debate on the teams day to day magic is more or
less unnecessary. Every team gets to make decisions on its day to day
management without having to jump through hoops (provided they are still
in line with the teams mission/purpose). I do not feel it is necessary
to add more bureaucracy than is 100% necessary into any teams day to day
activities. As long as a team is in line with its mission and isn't
causing any problems, they should be left alone. If they begin to cause
issues, then it is time for discussion.


Regards,
- -- 
Dane Smith (c1pher)
Gentoo Linux Developer -- Crypto / Sunrise / x86
RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531&op=index
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNRhe4AAoJEEsurZwMLhUxhEEQAL/DoHNnGkouR1NAd/FQndcs
/DlPGnyZIoD/62qCw7C/3+eDIaqwjgGNGB3lArSLiOheUINu5Jm2P7zlX6cdiPr5
M6M8wGsLJDhyvnN4EL+b+REqSUYbhW61e5uEt3IPRcaibtp4YwbBb2PdDKkl9fDH
/j2GgqkXUWdVGjOZp/vgpkiyFg9HJm1XrEy/rkRAaPdJlV5rJuqZH9h1TNmY8oeh
eiC7oaNiFBY/ibuGNYD9lklyP72ooN2gCESXiQuq/+1e13b+DwqOl1nZmABKIIWH
tSptWdP5ikhlITLqjsaHJyqeL37EH/R4Jsf/sms2qhGWOh2hi7xUznlOcXFetN9B
CJF8E/FWtmDmJkwBnkGsE++ASokbxB9w0m0krmjhXKuHZRzO2VrnjYpr4LiJOFd2
j+vCygpqnMrktC7sDAabKkuuJzZuinQ5dRZnQ6NLnTQ3UB4rMbqeC1djwC0hkSJV
uh4+idnZywj1D71OW4r6kw2gRUBS04C/KfNJgKx65dTEF5oYsQaJihh7Vad7YBQE
EPvugUaLui5qtX1+tvbIMIJUN+018uaa9idakAfjLxAJb1tqjvRMPTGoS1D/NLDM
S7kaXzJTIKhDA6OI/ugtyTHSs/IizTjdIWn58RlZbiMvSZki7x2xbRUDB0Fegwk9
Z2q3xp2RmGLxI8iel+r0
=8SID
-----END PGP SIGNATURE-----