[gentoo-qa] Proposed changes to GLEP48

[gentoo-qa] Proposed changes to GLEP48

[Diego Elio Pettenò]

[-- Attachment #1.1: Type: text/plain, Size: 368 bytes --]

Hi all,

since we've been having a bit of a scratch again regarding the extension
of details defined by GLEP48, I'm trying to edit it a bit to make it
work a bit more smoothly for our needs.

I'm attaching the diff I'd like to propose the council; please let me
know your comments.

Thanks,
-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

[-- Attachment #1.2: glep-48-changes.patch --]
[-- Type: text/x-patch, Size: 3099 bytes --]

? glep-48-changes.patch
Index: glep-0048.txt
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/glep/glep-0048.txt,v
retrieving revision 1.3
diff -u -B -r1.3 glep-0048.txt
--- glep-0048.txt	5 Sep 2006 20:36:38 -0000	1.3
+++ glep-0048.txt	20 Jan 2011 02:36:49 -0000
@@ -34,6 +34,14 @@
 * 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 deputy, whose decisions should be considered as
+  they were made by the lead in case he (or she) is not available.
+* The QA team lead approves applicant developers as team members.  By
+  doing this he (or she) will accept to direct them as part of the team
+  and will be held responsible for their actions, as taken on behalf
+  of the QA team.
 * 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
@@ -59,17 +67,21 @@
   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 his (or her) commit rights to be suspended.  Devrel
+  should then proceed to evalute the situation, by finding a
+  compromise or definitely revoking those rights.
+* Should a situation arise where a developer causes breakage to the
+  point it cannot be ascribed to bona-fide mistake, either the 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 within a week of said suspension.
 * 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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-qa] Proposed changes to GLEP48

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

On Sat, Jan 22, 2011 at 10:07:18PM +0100, Diego Elio Pettenò wrote:
> Hi all,
> 
> since we've been having a bit of a scratch again regarding the extension
> of details defined by GLEP48, I'm trying to edit it a bit to make it
> work a bit more smoothly for our needs.
> 
> I'm attaching the diff I'd like to propose the council; please let me
> know your comments.
> 
> Thanks,
> -- 
> Diego Elio Pettenò — Flameeyes
> http://blog.flameeyes.eu/

Hi Diego,

Looks good to me.

Regards,
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Key ID: B4AFF2C2
Key FP: 660A 0742 84EC 26F1 9EDB  F00A FA83 5A15 B4AF F2C2

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-qa] Proposed changes to GLEP48

[Luca Barbato]

On 01/22/2011 10:07 PM, Diego Elio Pettenò wrote:
> Hi all,
> 
> since we've been having a bit of a scratch again regarding the extension
> of details defined by GLEP48, I'm trying to edit it a bit to make it
> work a bit more smoothly for our needs.
> 
> I'm attaching the diff I'd like to propose the council; please let me
> know your comments.

Fine for me

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

[gentoo-qa] Re: Proposed changes to GLEP48

[Torsten Veller]

* Diego Elio Pettenò <flameeyes@gmail.com>:

The current "QA team's role and purpose" (GLEP 48) always talks about
the QA TEAM -- and I think this is good: QA needs a leader who can build
a team IMHO.
(Only once the lead is mentioned: New team members have to be approved
by the lead.)

> +* 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 deputy, whose decisions should be considered as
> +  they were made by the lead in case he (or she) is not available.

"[Projects] may have one or many leads, and the leads are selected by
the members of the project. This selection must occur at least once
every 12 months, and may occur at any time." [GLEP 39]

Why did you drop the "any time" rule?
"not available" -- within two hours, two days or two weeks, or devaway
or until the end of the fixed one-year-term (instead of running a new
election)? Or: How can the other teams know that the deputy takes the
lead role?

> +* The QA team lead approves applicant developers as team members.  By
> +  doing this he (or she) will accept to direct them as part of the team
> +  and will be held responsible for their actions, as taken on behalf
> +  of the QA team.

Here you wanted to drop the developer-for-four-months requirement. Ok.

"the lead will be held responsible for their actions"
I think this can be dropped: the team is responsible for its actions anyway
(whatever that means) and the lead will be replaced soon too.

> -* 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 his (or her) commit rights to be suspended.  Devrel
> +  should then proceed to evalute the situation, by finding a
> +  compromise or definitely revoking those rights.

What do you mean by "Devrel should then proceed to evalute the
situation, by finding a compromise or definitely revoking those
rights"?
Two points:
- QA specifies how Devrel is supposed to work in this case?
- Compromise between the particular developer and QA?
  So if the QA team doesn't want to find a compromise, the developer
  will have his commit bit definitely revoked?

> +* Should a situation arise where a developer causes breakage to the
> +  point it cannot be ascribed to bona-fide mistake, either the lead or

"be ascribed to bona-fide mistake" --
how can we evaluate this?

Do you think this rule would have been used in the past?

> +  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 within a week of said suspension.

And then? Appeal to the council? Will unjustified decisions by the QA
team lead or the two members be investigated too?
-- 
Regards Torsten

Re: [gentoo-qa] Re: Proposed changes to GLEP48

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]

Il giorno dom, 23/01/2011 alle 10.00 +0100, Torsten Veller ha scritto:
> 
> The current "QA team's role and purpose" (GLEP 48) always talks about
> the QA TEAM -- and I think this is good: QA needs a leader who can
> build
> a team IMHO. 

I'd be all for not having to specify so much the presence of the QA
lead, but the problem lies in what the past year taught us: devrel will
refuse to cooperate to anybody on the QA team but the lead.

With "cooperate" here I don't only mean "listen to the requests for
suspension"; devrel refused to keep the team as a whole in the loop of
pending requests, as well as ignoring any evidence/suggestion coming
from single team members.

Which is why they "force" us to actually specify a lead in our very
definition.


> "the lead will be held responsible for their actions"
> I think this can be dropped: the team is responsible for its actions
> anyway
> (whatever that means) and the lead will be replaced soon too.

It's a matter of bringing some balance in the game; if we drop the four
months rule, one could expect that the lead could call in his cronies
just to take over QA. By forcing a lead to take direct responsibility
for the people he or she let join the team.

Maybe I should specify it better, but it was intended as implicitly not
making the lead be directly responsible for the members that were on the
team _before_.

> "be ascribed to bona-fide mistake" --
> how can we evaluate this?
> 
> Do you think this rule would have been used in the past?

This would be easy to pass under the "it's just common sense" idea, but
I wanted to have it in anyway. If a developer ends up breaking the tree
by simply not thinking about the effects of his or her action, that's
bad, but it's one thing.

When a developer knows very well what his or her actions imply but still
applies them without caring about the repercussions, that cannot be
ascribed to bona-fide.

As an example, think about a developer committing a non-masked package,
the installation of which prevents Portage from completing its tasks
correctly. By default it's just a mistake, but if said developer
actually provided the fix beforehand to the Portage team but then didn't
wait for it to be deployed before committing the package, then it cannot
be a mistake in good faith.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-qa] Proposed changes to GLEP48

[Tomáš Chvátal]

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

Dne 22.1.2011 22:07, Diego Elio Pettenò napsal(a):
> Hi all,
> 
> since we've been having a bit of a scratch again regarding the extension
> of details defined by GLEP48, I'm trying to edit it a bit to make it
> work a bit more smoothly for our needs.
> 
> I'm attaching the diff I'd like to propose the council; please let me
> know your comments.
> 
> Thanks,
"The QA team lead can choose one member as deputy, whose decisions
should be considered as they were made by the lead in case he (or she)
is not available."
"The QA team lead can choose one member as deputy. Deputy has all his
powers directly delegated from the QA team lead and so his actions and
decisions should be considered equal the QA team lead. Deputy is
directly responsible only to the QA team lead."

NEW:
"Any QA team lead decision can be rewoked by major opposing vote from
all current QA members. Given the nature of this action new elections
should be held within 1 month to elect new QA team lead."

"In case a particular developer persistently causes breakage, the QA
lead may request his (or her) commit rights to be suspended.  Devrel
should then proceed to evalute the situation, by finding a compromise or
definitely revoking those rights."
"In case a particular developer persistently causes breakage, the QA
lead may request commit rights of given developer to be suspended by
Infra team. Devrel should then proceed to evaluate the situation, by
finding a compromise or definitely revoking those rights."

Reworded a bit:
"Should a situation arise where a developer causes breakage to the point
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 QA team within a 14 days of said suspension.
Resolution for this kind of issues is completely in hands of the QA team
and only the Gentoo Council can revisit the case."

Cheers
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk08GIIACgkQHB6c3gNBRYfw1QCdERvoGS321L4VuD4dYJEQxDUk
ewIAnjUQShytmgZEsI+01xIXn60gnm9N
=CzxW
-----END PGP SIGNATURE-----

Re: [gentoo-qa] Proposed changes to GLEP48

[Tomáš Chvátal]

[-- Attachment #1.1: Type: text/plain, Size: 243 bytes --]

Ok for final diff please see the attachment.
Please let me know if you would like something changed more.
I am nominating this thing for next council meeting so i need to have
final by tomorow evening (talking about UTC).

Cheers

Tom

[-- Attachment #1.2: glep-0048.diff --]
[-- Type: text/plain, Size: 3405 bytes --]

diff --git a/glep-0048.txt b/glep-0048.new.txt
index c894556..9711797 100755
--- a/glep-0048.txt
+++ b/glep-0048.new.txt
@@ -34,6 +34,19 @@ are maintained.
 * 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 deputy. The deputy has all 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. Deputy is directly
+  responsible only to the QA team lead.
+* The QA team lead may approve developers who apply to be team members.  By
+  doing this he (or she) will accept responsibility to direct them as part
+  of the team and will be held responsible for any actions the team member
+  takes on behalf of the QA team.
+* Any QA team lead decision can be revoked by 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
@@ -59,17 +72,23 @@ are maintained.
   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 pernamently 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 QA team within 14 days of said suspension.
+  Resolution for these kind of issues is completely in hands of the QA team
+  and only the Gentoo Council can revisit the case.
 * 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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-qa] Proposed changes to GLEP48

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

On Mon, Jan 24, 2011 at 09:59:17PM +0100, Tomáš Chvátal wrote:
> Ok for final diff please see the attachment.
> Please let me know if you would like something changed more.
> I am nominating this thing for next council meeting so i need to have
> final by tomorow evening (talking about UTC).
> 
> Cheers
> 
> Tom

Looks good

Regards,
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Key ID: B4AFF2C2
Key FP: 660A 0742 84EC 26F1 9EDB  F00A FA83 5A15 B4AF F2C2

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-qa] Proposed changes to GLEP48

[Peter Volkov]

В Пнд, 24/01/2011 в 21:59 +0100, Tomáš Chvátal пишет:
> +* 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 QA team within 14 days of said suspension.
> +  Resolution for these kind of issues is completely in hands of the QA team
> +  and only the Gentoo Council can revisit the case.

The last sentence makes QA behave in role of devrel. 

QA and devrel teams have quite different roles: QA team deals with
technical side while devrel works with humans. Different subjects make
big difference in methods (how issues should be handled) and results
(what is resolved issue). Technical issues should be fixed technically
and the result of QA team's work can be commit to fix issue or policy
for all developers to follow. That is why QA team is allowed to touch
any package package in the tree and QA maintains developer
documentation. Devrel team handles issues by communication with other
developers and result should be the change in developer's behavior ("to
make sure the Gentoo developer community is a pleasant environment for
everyone involved to participate in").

So although QA should be able to revoke commit access in emergency cases
still it's devrel job to work with human explain issues and either
revoke commit permanently or return commit rights.

-- 
Peter.