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

[Alec Warner]

Just as a frame, I'm not on QA.

On Fri, Apr 12, 2019 at 10:40 AM Michał Górny <mgorny@g.o> wrote:

> 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.  Remove the unclear reference to ComRel that is either
> meaningless or violation of scope.
>

Is there a particular driver for this change? E.g. have you been
dissatisfied with the current procedure, or perhaps Comrel is not acting on
your referrals?

In general I perceive the QA organization as an educational / enabling
organization (it trains people and writes tools) and not as a
punishment-based organization (where it shames people for their mistakes
and removes commit access from people who make too many.) This isn't to say
there isn't room for removing access for committers who routinely make
mistakes, I just think it ends up supporting this underlying narrative
about the project that (and I'm framing this here) "Gentoo should be
smaller and only composed of elite committers who understand all the
complex stuff required to not break things." This type of change was
previously discussed on the project list.

If the goal is to move the project in that direction I'd rather see a
vision document or similar ratified by the council to support that
direction than this slow boiling of a frog.


>
> 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 disciplinary
> actions independent of ComRel.  Explanation for the individual points
> follow.
>
> 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 on the other hand is concerned in actions having
> social consequences rather than technical.
>

Previous QA teams would often take unilateral action against individual
developers, often for problems that were poorly or under-documented[0]. The
infrastructure teams in the past had similar issues (e.g. removing commit
access of individual developers on a whim) and part of the reason that
Comrel is slower to act is to prevent this type of activity. Hence my
question above: Is Comrel not doing the right thing here? Why do we need to
delegate this ability directly with the QA team?

[0] This is again my thrust that QA is a enabling team, not a punishment
team. Tools to prevent commits that are bad. Tools to find bad commits
post-commit. Tools to roll-back or revert bad commits. More stuff like "two
branches of ::gentoo "master" and "ci" and maybe rsync / users should
consume the CI'd branch. I don't expect that all developers understand
everything.


>
> 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.
>

This part seems fine, I think we should have a clearer idea of punishments.


>
> Thirdly, it removes the unnecessary involvement of ComRel, 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
> defined.
>

I see the QA organization as having one primary mission "making sure that
Gentoo users can install and use Gentoo packages". I see the team
supporting that in four key areas:
 - Education: this is content like the devmanual.
 - Prevention: Tools like repoman (to prevent bad commits from being
committed) or a CI branch (to prevent users from seeing bad commits.)
 - Mitigation: The CI branch again here, helps us quickly find bad commits,
and mitigates any bad commit because only the passing CI branch is made
available to users, so bad commits are lower impact.
 - Punishment: If people don't use the tools, or consistently don't take
feedback, we should probably not trust them to commit.

I find punishment the least effective thing QA can do; the QA organization
is an *enabling* organization that enables people to be effective. Removing
commit access is not really enabling anyone and unlike focusing on the
other three areas (whose impact is multiplied by the number of
contributors) removing commit access only affects 1 person at a time.




> ---
>  glep-0048.rst | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/glep-0048.rst b/glep-0048.rst
> index f9773c0..55a27a2 100644
> --- a/glep-0048.rst
> +++ b/glep-0048.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 issue a permanent removal of the commit access (retirement).
> All
> +  the evidence of the violation, as well as ban lenght 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
>
>
>