Hi,

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:

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

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

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

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