en/glep/glep-0048.txt

GLEP: 48
Title: QA Team's Role and Purpose
Version: $Revision: 1.4 $
Last-Modified: $Date: 2011/06/08 20:36:38 $
Author: Mark Loeser <halcy0n@gentoo.org>,
Status: Final
Type: Standards Track
Content-Type: text/x-rst
Created: 24 April 2006
Post-History: 24-Apr-2006, 5-Sep-2006, 8-Jun-2011


Abstract
========

This GLEP outlines the abilities and purpose of the Quality Assurance team
for Gentoo.

Motivation
==========

For years now developers have been saying how we need an empowered QA team to
handle problems concerning the tree.  This GLEP provides the structure for
such a team and specifies the roles the team would fulfill.

Specification
=============

The QA team should be given certain abilities to look out for the best
interests of all developers, as well as our users.  The QA team should also
work to ensure developers have the information they need, and that packages
are maintained. The QA team is also tasked with the authority to ensure
tree policies are respected.

* 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.
* 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.
* 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
  wish to do so when the team finds it is in the best interest of users and
  fellow developers to have the issue addressed as soon as possible.
* The QA team may also offer to fix obvious typos and similar minor issues,
  and silence from the package maintainers can be taken as agreement in such
  situations.  Coding style issues fall under this category, and while they
  are not severe, they can make automated checks of the tree more difficult.
* There will be cases when our tools are incapable of handling a certain
  situation and policy must be broken in order to get something working
  completely.  This will hopefully not occur very often but each time it
  does occur, the QA team and the maintainer will come to some agreement on
  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:
  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
  QA standards, an appeal can be made at the next council meeting. The package
  should be dealt with per QA's request until such a time that a decision is
  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.
* 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.
* 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.
* QA will take an active role in cleaning up and removing from the tree
  unmaintained packages as they are found to be broken.  It is also
  encouraged of members of the QA team to assist in mentoring new developers
  that wish to take over unmaintained packages/herds.


Backwards Compatibility
=======================

Not a problem for this GLEP.

Copyright
=========

This document has been placed in the public domain.
1	g2boojum	1.1	GLEP: 48
2			Title: QA Team's Role and Purpose
3	jmbsvicetto	1.4	Version: $Revision: 1.4 $
4			Last-Modified: $Date: 2011/06/08 20:36:38 $
5	g2boojum	1.1	Author: Mark Loeser <halcy0n@gentoo.org>,
6	g2boojum	1.2	Status: Final
7	g2boojum	1.1	Type: Standards Track
8			Content-Type: text/x-rst
9			Created: 24 April 2006
10	jmbsvicetto	1.4	Post-History: 24-Apr-2006, 5-Sep-2006, 8-Jun-2011
11	g2boojum	1.1
12
13			Abstract
14			========
15
16			This GLEP outlines the abilities and purpose of the Quality Assurance team
17			for Gentoo.
18
19			Motivation
20			==========
21
22			For years now developers have been saying how we need an empowered QA team to
23			handle problems concerning the tree. This GLEP provides the structure for
24			such a team and specifies the roles the team would fulfill.
25
26			Specification
27			=============
28
29			The QA team should be given certain abilities to look out for the best
30			interests of all developers, as well as our users. The QA team should also
31			work to ensure developers have the information they need, and that packages
32	jmbsvicetto	1.4	are maintained. The QA team is also tasked with the authority to ensure
33			tree policies are respected.
34	g2boojum	1.1
35			* The QA team's purpose is to provide cross-team assistance in keeping the
36			tree in a good state. This is done primarily by finding and pointing out
37			issues to maintainers and, where necessary, taking direct action.
38	jmbsvicetto	1.4	* The QA team is directed by a lead, chosen yearly by private or
39			public election among the members of the team. The QA team lead can
40			choose one member as a deputy. The deputy has all of his powers directly
41			delegated from the QA team lead and thus his actions and decisions should
42			be considered equal to those of the QA team lead. The deputy is directly
43			responsible only to the QA team lead.
44			* The QA team lead must approve developers who would like to join the project. The
45			applicant must demonstrate a thorough understanding of the duties he would like
46			to perform. By accepting the applicant the QA team lead will accept
47			the responsibility to direct them as part of the team and will be held
48			responsible for any action the team member takes on behalf of the QA team.
49	g2boojum	1.1	* In case of emergency, or if package maintainers refuse to cooperate,
50			the QA team may take action themselves to fix the problem. The QA team
51			does not want to override the maintainer's wishes by default, but only
52			wish to do so when the team finds it is in the best interest of users and
53			fellow developers to have the issue addressed as soon as possible.
54			* The QA team may also offer to fix obvious typos and similar minor issues,
55			and silence from the package maintainers can be taken as agreement in such
56			situations. Coding style issues fall under this category, and while they
57			are not severe, they can make automated checks of the tree more difficult.
58			* There will be cases when our tools are incapable of handling a certain
59			situation and policy must be broken in order to get something working
60			completely. This will hopefully not occur very often but each time it
61			does occur, the QA team and the maintainer will come to some agreement on
62			an interim solution and it is expected that a bug will be opened with the
63			appropriate team to work towards a correct solution.
64			* In the case of disagreement among QA members the majority of established
65			QA members must agree with the action. Some examples of disagreements are:
66			whether the percieved problem violates the policy or whether the solution
67			makes the situation worse.
68			* In the event that a developer still insists that a package does not break
69			QA standards, an appeal can be made at the next council meeting. The package
70			should be dealt with per QA's request until such a time that a decision is
71			made by the council.
72			* Just because a particular QA violation has yet to cause an issue does not
73			change the fact that it is still a QA violation.
74			* If a particular developer persistently causes breakage, the QA team
75			may request that devrel re-evaluates that developer's commit rights.
76			Evidence of past breakages will be presented with this request to devrel.
77			* The QA team will maintain a list of current "QA Standards" with explanations
78			as to why they are problems, and how to fix the problem. The list is not
79			meant by any means to be a comprehensive document, but rather a dynamic
80			document that will be updated as new problems are discovered. The QA team
81			will also do their best to ensure all developer tools are in line with the
82			current QA standards.
83			* The QA team will work with Recruiters to keep related documentation and
84			quizzes up to date, so that up and coming developers will have access to all
85			of the necessary information to avoid past problems.
86			* QA will take an active role in cleaning up and removing from the tree
87			unmaintained packages as they are found to be broken. It is also
88			encouraged of members of the QA team to assist in mentoring new developers
89			that wish to take over unmaintained packages/herds.
90
91
92			Backwards Compatibility
93			=======================
94
95			Not a problem for this GLEP.
96
97			Copyright
98			=========
99
100			This document has been placed in the public domain.