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

[Alec Warner]

On Tue, Apr 23, 2019 at 2:13 PM Thomas Deutschmann <whissi@g.o>
wrote:

> Hi,
>
>
This is my third draft, I'm trying to keep things concise.


> according to the answer to antarus' question, I understand that in the
> past there were Gentoo developers violating Gentoo QA standards.
>
> There must be a clear process how to deal with such a situation:
>

I agree there needs to be a process. I also tend to agree the current
process is not working (based on mgorny's comments above.)
My guidance is mostly around guardrails; I care less about the specifics
and more about getting the project to be run in reasonable way.


>
> - Which kind of QA violation can cause a ban? At no time should a single
> QA violation allow whoever is current QA lead or QA team to issue a ban.
> I am not saying that current QA team wants to do something like that but
> we need clear rules everyone can understand.
>

> - It must be clear that a ban is the last resort. I.e. the process must
> define something like a warn system so that the developer violating
> Gentoo QA standards knows that he/she has been warned and if he/she
> won't change his/her behavior, a ban (commit bit will flip) will follow.
>

I'm not convinced bans do anything, but I'll elaborate below.


>
> - However, disciplinary actions must happen in time. I.e. you cannot
> silently watch and just complain on IRC for x months and suddenly decide
> to issue a ban because QA team just lost patience. That said, an issued
> warning will time out. If the developer in question stops violating QA
> rules for $time, he/she is back at level 0 so that a new issue won't
> trigger an action (keep in mind: We assume that we all share the same
> goals; if there's a hostile developer causing problems all the time this
> is a Gentoo problem, not a QA problem).
>

I agree that its important not to hide problems. We should have some kind
of data collection that tracks defects, and be able to identity patterns.
If we want to depreciate items (so e.g. mistakes 90d ago mean less) that
also seems relevant. Remember that behind this is the idea that everyone
will make mistakes; so some background level of defects is expected.


>
> - It must be clear that QA can take actions as last resort. Let's say
> developer X received first strike, don't change behavior, maybe will
> receive second strike and still keep violating QA standards, QA has the
> power to remove commit bit.
>
> BUT:
>
> QA actions must be limited in time. After 1 or 2 weeks, commit bit must
> be restored. If the developer in question will keep behavior causing the
> disciplinary action, we can assume that he/she is a hostile developer
> for Gentoo and this will become topic of ComRel.
>

I think this is all about intent right.

- All developers will make mistakes.
- Some mistakes are caught by tools, and some are not.
- Developers who make more mistakes than expected (because again, everyone
makes some) should have more review.
 - Developers under review who violate policies *deliberately* should not
remain committers.

I'm not sure bans really help with any of this. The challenge is "which
developers deliberately violate policy" and which ones violate it because
"there are a lot of ways to screw up and everyone screws up sometimes."
This is why I think discussion and transparency help.

 - If a committer is committing without repoman for example, its a pretty
deliberate step.
 - If a committer has made some mistake often, and we provided guidance to
them (improve documentation, mentorship, etc) and they don't show
improvement, we might count that as deliberate.

I don't think committers who violate policy will be changed by a ban.
Certainly not a ban that is time-delimited (it means I get a 2 week gentoo
vacation!) I'd consider alternatives like:
 - A period where the commits need review.
 - A ban followed by retraining on specific topics.
 - A period where the developer is required to build / patch a CI tool to
catch the bug before getting to commit without review again.

These are all things that enable. Time passing is not an enabler, IMHO.

-A


> Based on this, I cannot vote for
>
> https://archives.gentoo.org/gentoo-project/message/548d9c439a73ae38756c0b92a28137ea
> :
>
> The changed text grants too much power to QA project. As said, QA
> project is responsible for QA in Gentoo (technical things in
> ebuilds/eclass in most cases). QA should never have the privileges to
> decide to forcefully retire a developer or should take actions for
> others (like infra, work of others).


>
> --
> Regards,
> Thomas Deutschmann / Gentoo Linux Developer
> C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
>
>