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

[Michał Górny]

On Mon, 2019-04-29 at 17:27 +0200, Thomas Deutschmann wrote:
> On 2019-04-29 14:07, Michał Górny wrote:
> > +* 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.
>
> My opinion here:
>
> 1) The whole requested GLEP change is wrong. It doesn't take into
> account that from my perspective, disciplinary actions should be last
> resort. We don't have a current problem to solve. I acknowledge that in
> the past there was a problem that a requested ban wasn't executed in
> time. I am fine with updating GLEP to indicate that QA has the power to
> do that so it becomes clear that whoever has to execute the ban has to
> follow if that was the reason why the ban wasn't executed in time...
> nothing more.

We discard anything as 'problem in the past' because obviously every
moment becomes past moment later.  In this case, this 'past' is more
recent than proposed GLEP change, so I don't see how you could claim
that there is no problem when the problem keeps exhibiting itself.

> 2) QA project is only responsible for gentoo.git. That's it. Abusing QA
> project to protect Gentoo infrastructure or any other project is wrong.

Gentoo Infrastructure is also running on gentoo.git.  As I said before,
this simply means that you can't claim your breakage did not affect
users because it destroyed Infra before it was delivered to users.

> Also, "impacting the work of other developers" is not QA's
> responsibility and due to the fact that you cannot really define that

For example, it means that the QA breakage you've introduced and refuse
to fix is preventing other developers from working on their ebuilds.  It
doesn't mean to provide a closed directory of potential problems, it
means to give a feeling when QA violation can be considered a major
breakage that may require rough measures.

In other words, this doesn't try to find excuses to ban people.  It
tries to say 'we will not issue bans because someone misnamed USE flag
or added dot to DESCRIPTION when it's not proper sentence'.  We will
only resort to them when someone's really breaking stuff.

> sentences, it could be abused to construct a case against any developer,
> QA team wants to get rid of for no real reasons.

You know, the problem is, if we don't define it, people complain that's
it not well-defined and open to abuse.  When I try to define it, people
complain the definition may be abused.  So what should I do?  Do you
have a better suggestion?

Also, I would really appreciate if you would refrain from accusing QA of
aiming to immediately abuse stuff.  Again, the same could be said about
ComRel, so I guess we should really ban all disciplinary action whatever
and let the best troll win.

> 3) 30 days is too long. Like said, Gentoo should never be about
> disciplinary actions but it looks like some current QA members want to
> change that. I am against that change:

Tell that to ComRel.  If Proctors reduce their maximum disciplinary
action, I will adjust the spec.  Otherwise, this is moot point.

> If someone is ignoring Gentoo's QA requirements (and not QA project
> rules, remember: QA project is working *for* Gentoo and not
> *against*...) QA project should communicate with that developer. I
> assume that no developer will violate Gentoo's QA requirements on
> purpose. If the developer won't fix/stop violating QA requirements
> (=don't be cooperative with Gentoo) QA project would issue the first ban
> (7d). If developer retains his/her hostile behavior when he/she regains
> commit access, maybe there will be a second ban (this time for 14d). If
> developer still doesn't change behavior and keeps violating rules the
> complete Gentoo project agreed on, ComRel has to take action (and will
> probably have to kick developer out of Gentoo assuming the developer is
> still not cooperating with Gentoo).

So your proposed action is 7d, then 14d, then kick.  Are you really
saying this is better for devs than giving the extra chance of 30d? 
Purely theoretically, I'm not convinced if this will really be used.

> For me the important difference is: Gentoo is not 'real life'. I.e. in
> life you cannot always chose the people you have to deal with. So we
> have laws and policy to be prepared against people we cannot avoid. But
> assuming that everyone in Gentoo is sharing the same goals (for Gentoo)
> and has accepted CoC, a situation like this shouldn't be normal.
> Therefore we don't need to give a project like QA the absolute power to
> protect us just in case of an emergency

This is not to protect anyone in emergencies.  This is to enforce
a clear split between handling of social and technical problems.  ComRel
just isn't the right body to judge technical issues caused by
developers.

I can live with ComRel deciding on the 'kick' action, provided it has
former QA actions to support this decision.  I am against ComRel judging
technical evidence (which, again, is outside its jurisdiction)
and deciding whether the developer violated QA standards.

>  (we don't really have real
> emergencies, and if I for example would just start to delete/manipulate
> all ebuilds in Gentoo repository I am very sure I would be stopped in
> time and nobody would say "Damn! We can't stop him, we first need a GLEP
> allowing us to...").

You, maybe.  If I were to do it, then I'm pretty sure somebody would
point out that I've abused my privileges, did not follow established
policies, etc.  There would be a long bikeshed that while, sure, I've
done the right thing and for the right reason, I certainly shouldn't
have that much power... blah, blah, blah.

-- 
Best regards,
Michał Górny