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

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

[Michał Górny]

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.

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@gentoo.org>
---
 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.
 * 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

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

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 4294 bytes --]

On Mon, Apr 29, 2019 at 8:07 AM Michał Górny <mgorny@gentoo.org> 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@gentoo.org>
> ---
>  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
>
>
>

[-- Attachment #2: Type: text/html, Size: 5501 bytes --]

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

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 3369 bytes --]

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.

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.
Also, "impacting the work of other developers" is not QA's
responsibility and due to the fact that you cannot really define that
sentences, it could be abused to construct a case against any developer,
QA team wants to get rid of for no real reasons.

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:

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

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


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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

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

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

[Alexis Ballier]

On Mon, 29 Apr 2019 17:53:21 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> > 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 is QA's role to jump and fix it to minimize the impact on other
developers. And because it is not fun to do so if someone is not
cooperating, I believe short bans in the hands of QA's team make sense,
even if I dislike the idea.

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


What's the relation with proctors here?

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

What you're missing here is that repeated uncooperative behavior is no
longer technical, this becomes comrel's grounds.

[..]

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

[Michał Górny]

On Mon, 2019-04-29 at 18:23 +0200, Alexis Ballier wrote:
> On Mon, 29 Apr 2019 17:53:21 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > > 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 is QA's role to jump and fix it to minimize the impact on other
> developers. And because it is not fun to do so if someone is not
> cooperating, I believe short bans in the hands of QA's team make sense,
> even if I dislike the idea.
> 
> [...]
> > > 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.
> 
> What's the relation with proctors here?
> 

This is 'inspired' by Proctors.  Just like Proctors issue short-term
actions for CoC violations, QA issues short-term actions for QA
violations.  In both cases, longer actions are deferred to ComRel.

-- 
Best regards,
Michał Górny

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

[Alexis Ballier]

On Mon, 29 Apr 2019 18:46:29 +0200
Michał Górny <mgorny@gentoo.org> wrote:

[...]
> > [...]
> > > > 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.
> > 
> > What's the relation with proctors here?
> > 
> 
> This is 'inspired' by Proctors.  Just like Proctors issue short-term
> actions for CoC violations, QA issues short-term actions for QA
> violations.  In both cases, longer actions are deferred to ComRel.

This does not imply that the duration should be the same.

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

[Mikle Kolyada]

[-- Attachment #1: Type: text/plain, Size: 5013 bytes --]


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


On 29.04.2019 18:27, 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. Suggestions are welcome.

> We don't have a current problem to solve. I would ask you to refrain from such a vague statement. I expect any
council member to be
aware of historical references that lead to the consequences. As a
member of both ComRel and QA (including leading roles for some terms),
I can state that there is the problem. The more we ignore it the
worse it becomes. Even more, I do not expect a council member to state
something like that just because they think it does not exist.
Especially when the whole team claims the opposite.
> 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. This is irrelevant to the initial changes idea.

> 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. > Also, "impacting the work of other developers" is not QA's >
responsibility and due to the fact that you cannot really define that >
sentences, it could be abused to construct a case against any developer,
> QA team wants to get rid of for no real reasons. True, and if a
developer made a malicious commit that led to the rsync
breakage is about QA.
Otherwise we do not care about overlays, if you want to hear this.

> 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: People asked us to define
the maximum, so we did.
> 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). This only works in theory, not in practice.

> 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). > > 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 Again, QA has had this power for ages,
nothing changed so far. I told
you this at least twice.
Our goal is to document powers and make it clear, so people stop asking
us something like
"why does it work this way??? This is undocumented!"

>  (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..."). > > -----BEGIN PGP
SIGNATURE-----

iQEzBAEBCAAdFiEEWmyBGnI+Eihw6dN8HICQJIqVl8cFAlzII1EACgkQHICQJIqV
l8deowf/SDVY+rGiPuntqTgh4YzEdNC6PFCedqGUdT+pqbW11V4+bL6nMWTKL8FJ
CmwHlPddwmcjm7vciINZeDjxAR+Zu0Ijy0S5I9TnOH1rjPmUIYpAMZbuepPzVE/8
IGTLKTCDaxkskbCAY6GP5Jdy9skq3WTT+7fhhKe1tBnp+XDQ62y9eO+WZCruMkNy
o506ldmxlcaeXWj+lQcvhA2TN0kLjvF13AFxxnWNsHjloOafu+Qn9kVXF58hHC5p
LF5LwyReidpy1xHZodoRIVYyJNieREBxRSgw/PB6K1Bw8vA4P0wtJowhjYCU+kZo
/vU4ZWuXwCt12SHaaniBEJJNOqhCwQ==
=4C4c
-----END PGP SIGNATURE-----


[-- Attachment #2: Type: text/html, Size: 6240 bytes --]

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

[Michael Everitt]

[-- Attachment #1.1.1: Type: text/plain, Size: 4768 bytes --]

On 30/04/19 11:28, Mikle Kolyada wrote:
>
>
> On 29.04.2019 18:27, 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.
> Suggestions are welcome.
>
> > We don't have a current problem to solve.
> I would ask you to refrain from such a vague statement. I expect any
> council member to be
> aware of historical references that lead to the consequences. As a
> member of both ComRel and QA (including leading roles for some terms),
> I can state that there is the problem. The more we ignore it the
> worse it becomes. Even more, I do not expect a council member to state
> something like that just because they think it does not exist.
> Especially when the whole team claims the opposite.
> > 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.
> This is irrelevant to the initial changes idea.
>
> > 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.
> > Also, "impacting the work of other developers" is not QA's
> > responsibility and due to the fact that you cannot really define that
> > sentences, it could be abused to construct a case against any developer,
> > QA team wants to get rid of for no real reasons.
> True, and if a developer made a malicious commit that led to the rsync
> breakage is about QA.
> Otherwise we do not care about overlays, if you want to hear this.
>
> > 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:
> People asked us to define the maximum, so we did.
> > 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).
> This only works in theory, not in practice.
>
> > 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).
>
> > 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
> Again, QA has had this power for ages, nothing changed so far. I told
> you this at least twice.
> Our goal is to document powers and make it clear, so people stop asking
> us something like
> "why does it work this way??? This is undocumented!"
>
> >  (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...").
>
>
>
Please can you reformat your mail to make it readable. Thanks.

[-- Attachment #1.1.2: Type: text/html, Size: 6316 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Mikle Kolyada]

[-- Attachment #1.1.1: Type: text/plain, Size: 4398 bytes --]



On 30.04.2019 13:28, Mikle Kolyada wrote:
[snip]

re-send due to enigmail spoiled up on sending.



On 29.04.2019 18:27, 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. 

Suggestions are welcome.

> We don't have a current problem to solve. 

I would ask you to refrain from such a vague statement. I expect any
council member to be
aware of historical references that lead to the consequences. As a
member of both ComRel
and QA I can state that there is the problem. The more we ignore it the
worse it becomes.

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

This is irrelevant to the initial changes idea.

> 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.
> Also, "impacting the work of other developers" is not QA's
> responsibility and due to the fact that you cannot really define that
> sentences, it could be abused to construct a case against any developer,
> QA team wants to get rid of for no real reasons.

True, and if a developer made a malicious commit that led to the rsync
breakage is about QA.
Otherwise we do not care about overlays, if you want to hear this.

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

People asked us to define the maximum, so we did.

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

This only works in theory, not in practice.

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

Again, QA has had this power for ages, nothing changed so far. I told
you this at least twice.
Our goal is to document powers and make it clear, so people stop asking
us something like
"why does it work this way, this is undocumented!"

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

[-- Attachment #1.1.2: Type: text/html, Size: 6474 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]