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

[Michał Górny]

On Fri, 2019-04-12 at 11:30 -0400, Alec Warner wrote:
> 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?

Yes, I am dissatisfied.  I am especially dissatisfied by the absurd
bureaucracy and unclear jurisdiction.  I've seen QA claiming we don't
have authority and sending me to ComRel, and being sent back to QA
because 'it's QA business'.

Furthermore, even if we can get this bureaucracy to work, we end up with
absurd delays because of two teams taking vote on the same issue
in series.  Do you really think it's good to ban someone *now* because
he did something two weeks earlier?

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

I think you're insulting QA's competence here.  The goal is not to ban
people for making mistakes.  The goal is to be able to actually act when
all less invasive measures fail.

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

This sounds like we're creating unjustified bureaucracy just because we
had some social problem with some people in the past.  Why do you
presume that ComRel will never abuse its power, and at the same time
presume QA will kick people 'on a whim'?

I'm not sure if I'm supposed to answer the same question twice.
The point is, in my opinion the current procedure is unjustified
and there is a simpler procedure that should work here.

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

I agree.  However, there are valid cases when the three first areas just
don't solve the problem.  We can educate, we can put a lot of effort
into making things more 'fool-proof' but in the end, it doesn't stop
developers from breaking stuff.  Or turns Gentoo into a unmaintainable
mess where every developer suffers because of few making mistakes.

The point is, that if a developer keeps breaking stuff and doesn't
listen to reminders to be more careful, there is a point when QA should
be able to issue a ban to make the developer realize he can't go on like
this.

-- 
Best regards,
Michał Górny