[gentoo-project] [PATCH v2] glep-0048: Provide clear rules for disciplinary actions

[gentoo-project] [PATCH v2] glep-0048: Provide clear rules for disciplinary actions

[Michał Górny]

Update the wording of GLEP 48 to provide clear information on what kind
of disciplinary actions QA can issue, and in what circumstances they can
be exercised.

According to the old wording, QA could request 're-evaluating commit
rights' from ComRel.  This is very unclear, and has been a source of
confusion more than once.  Firstly, it is unclear whether ComRel merely
serves as a body executing the QA team's decision, or whether it is
supposed to make independent judgment (which would be outside its
scope).  Secondly, it suggests that the only disciplinary action
possible would be 're-evaluating commits rights' which sounds like
an euphemism for removing commit access permanently.

The new wording aims to make things clear, and make QA able to issue
short-term disciplinary actions without involving ComRel, similarly
to how Proctors work.  Explanation for the individual points follows.

Firstly, it aims to clearly define the domain of QA actions, and set
a better distinction between QA and ComRel.  In this context, QA
is concerned whenever the developer's action technically affects Gentoo,
which includes breaking user systems, Infrastructure tooling, other
packages, etc.  ComRel/Proctors on the other hand are concerned
in actions having social consequences rather than technical.

Secondly, it clearly defines the possible disciplinary actions as either
temporary commit access ban, or (in case of repeated offenses) permanent
removal of commit access.

Thirdly, it removes the unnecessary involvement of ComRel in temporary
bans, QA violations being outside of their scope of interest.  Each case
of QA violations is analyzed by QA team individually, and QA team
exercises disciplinary actions independently.  At the same time, appeal
path via Council is left provided.

ComRel stays the body deciding for permanent ban and/or retirement,
in case of repeated offense.

Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
 glep-0048.rst | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

Changes from v1:
- QA issues only short-term bans independently, while ComRel handles
  requests for permanent commit access removal

diff --git a/glep-0048.rst b/glep-0048.rst
index f9773c0..6b5d031 100644
--- a/glep-0048.rst
+++ b/glep-0048.rst
@@ -6,8 +6,8 @@ Type: Standards Track
 Status: Final
 Version: 2
 Created: 2006-04-24
-Last-Modified: 2014-01-25
-Post-History: 2006-04-24, 2006-09-05, 2011-06-08
+Last-Modified: 2018-04-23
+Post-History: 2006-04-24, 2006-09-05, 2011-06-08, 2018-04-12
 Content-Type: text/x-rst
 ---
 
@@ -76,9 +76,14 @@ tree policies are respected.
   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 Comrel re-evaluates that developer's commit rights.
-  Evidence of past breakages will be presented with this request to Comrel.
+* If a particular developer persistently causes QA violations (actions that
+  negatively impact the behavior of Gentoo systems, work of other developers
+  or infrastructure facilities), the QA team may issue a temporary revocation
+  of developer's commit access (ban).  In case of repeated offenses, the QA
+  team may request that ComRel re-evaluates the commit access.  All
+  the evidence of the violation, as well as ban length will be evaluated
+  by the QA team for each case individually.  The disciplinary decisions made
+  by the QA team are subject to appeal via the council.
 * 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
-- 
2.21.0

Re: [gentoo-project] [PATCH v2] glep-0048: Provide clear rules for disciplinary actions

[Alexis Ballier]

On Tue, 23 Apr 2019 19:34:10 +0200
Michał Górny <mgorny@gentoo.org> wrote:
[...]
> Secondly, it suggests that the only disciplinary action
> possible would be 're-evaluating commits rights' which sounds like
> an euphemism for removing commit access permanently.

:=)

politically correct!

[...]
> +  negatively impact the behavior of Gentoo systems, work of other
> developers
> +  or infrastructure facilities), the QA team may issue a temporary
> revocation
> +  of developer's commit access (ban).  In case of repeated offenses,
> the QA
> +  team may request that ComRel re-evaluates the commit access.  All
> +  the evidence of the violation, as well as ban length will be
> evaluated
> +  by the QA team for each case individually.  The disciplinary
> decisions made
> +  by the QA team are subject to appeal via the council.


I would add maximum amounts of time everywhere here: For the QA ban
because this effectively still leaves room for "age of the universe"
long bans and a slightly shorter one for the comrel response to ensure
no important ban is missed due to people being on vacations.

Depending on that maximum, council appeal may not be needed because
it'd take longer than the ban length anyway.

Re: [gentoo-project] [PATCH v2] glep-0048: Provide clear rules for disciplinary actions

[Chí-Thanh Christopher Nguyễn]

Alexis Ballier schrieb:

> I would add maximum amounts of time everywhere here: For the QA ban
> because this effectively still leaves room for "age of the universe"
> long bans and a slightly shorter one for the comrel response to ensure
> no important ban is missed due to people being on vacations.

If we agree that QA bans are emergency powers *only* to avert breakage 
reaching users, and/or causing unreasonable amounts of work for other 
developers to undo, then that would implicitly limit the time of a ban to 
whenever the next ComRel/Council meeting can discuss this incident.

Afterwards it will either be lifted or turned into a ComRel ban.

> Depending on that maximum, council appeal may not be needed because
> it'd take longer than the ban length anyway.

I think that ComRel review of the QA emergency decision should be the default 
unless the disciplinary action has expired or was lifted in the meantime.

But even so, if some QA decision is questionable, bringing it before Council 
is good irrespective of whether it is a past or current matter.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-project] [PATCH v2] glep-0048: Provide clear rules for disciplinary actions

[Raymond Jennings]

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

What about just at first giving QA the authority to unilaterally revert
commits in the event they cause QA violations?

Assuming that a QA violation is clear and evident, it seems reasonable to
allow it to be reverted immediately without further need for deliberation,
since introducing a QA violation could be construed as a regression.

If this is done it has the immediate benefit of prompt limitation of damage
and goes directly towards what I think is QA's mission.

I'm assuming it's implied that an erroneous revert is itself actionable as
dereliction of duty by QA.

Letting QA handle the immediate task of protecting/maintaining quality
standards in the ebuild tree seems the right move.

Whether the offending developer should face disciplinary action for
violating QA in the first place IMO should be a separate issue.

A possible idea is to let QA make a referral to proctors and/or comrel as
necessary.  For example, for the offending developer's actual QA violation
a warning might be issued by proctors.  A developer who shows a pattern of
negligence, or who deliberately overrides a QA revert, or otherwise
aggravates the situation beyond a proctor-level concern could be referred
to comrel.

The general idea is to let QA take preemptive action as necessary to
protect or undo any damage caused by a QA violation, since the tree itself
needs protection that may well not benefit from waiting for social
procedures involving discipline, and have any disciplinary matters handled
as a separate issue possibly with a referral to proctors/comrel.

But the gist is having discipline treated as a separate issue that can be
handled with social procedures and break off the actual QA task so that the
tree's integrity doesn't wait for deliberation.

On Fri, Apr 26, 2019 at 6:21 PM Chí-Thanh Christopher Nguyễn <
chithanh@gentoo.org> wrote:

> Alexis Ballier schrieb:
>
> > I would add maximum amounts of time everywhere here: For the QA ban
> > because this effectively still leaves room for "age of the universe"
> > long bans and a slightly shorter one for the comrel response to ensure
> > no important ban is missed due to people being on vacations.
>
> If we agree that QA bans are emergency powers *only* to avert breakage
> reaching users, and/or causing unreasonable amounts of work for other
> developers to undo, then that would implicitly limit the time of a ban to
> whenever the next ComRel/Council meeting can discuss this incident.
>
> Afterwards it will either be lifted or turned into a ComRel ban.
>
> > Depending on that maximum, council appeal may not be needed because
> > it'd take longer than the ban length anyway.
>
> I think that ComRel review of the QA emergency decision should be the
> default
> unless the disciplinary action has expired or was lifted in the meantime.
>
> But even so, if some QA decision is questionable, bringing it before
> Council
> is good irrespective of whether it is a past or current matter.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>

[-- Attachment #2: Type: text/html, Size: 3637 bytes --]