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

[Alec Warner]

On Mon, Apr 29, 2019 at 8:07 AM Michał Górny <mgorny@g.o> wrote:

> Update the wording of GLEP 48 to provide clear information on what kind
> of disciplinary actions can be issued by QA and under what circumstances
> they can be exercised.
>
> According to the old wording, QA could only request 're-evaluating
> commit rights' from ComRel.  This is very unclear, and has been a source
> of confusion.  Firstly, it is unclear whether ComRel merely serves
> as a proxy 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.
>

I agree re-evaluating commit rights is weird, we should just strike it.


> 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 that the QA team can issue a temporary ban
> (with the upper limit of 30 days, same as Proctors) via an internal team
> vote.  In this case there is no necessity of involving ComRel, and QA
> can request executing this disciplinary decision straight from Infra.
>
> Thirdly, the old policy is clarified as applying to permanent bans.
> In case of repeated offenses, QA requests ComRel to evaluate the case.
>
> Signed-off-by: Michał Górny <mgorny@g.o>
> ---
>  glep-0048.rst | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
> Changes in v3:
> * improved the commit message to remove v1 cruft
> * specified upper limit of ban length to 30 days
>   (lack of this was pointed out by ulm)
> * removed duplicate notion of Council appeal
>
> diff --git a/glep-0048.rst b/glep-0048.rst
> index f9773c0..8625b6f 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: 2019-04-29
> +Post-History: 2006-04-24, 2006-09-05, 2011-06-08, 2019-04-12
>  Content-Type: text/x-rst
>  ---
>
> @@ -76,9 +76,13 @@ 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), up to 30 days.  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
> +  and voted on by the QA team for each case individually.
>

"In the case of repeated offenses, the QA team may request that ComRel take
appropriate disciplinary action against the developer."

The "re-evaluates the commit access line" is ..weird, so I suggest
replacing it.


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