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

[gentoo-project] [PATCH] 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 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.

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.

Secondly, it clearly defines the possible disciplinary actions as either
temporary commit access ban, or (in case of repeated offenses) permanent
removal of commit access.

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.
---
 glep-0048.rst | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/glep-0048.rst b/glep-0048.rst
index f9773c0..55a27a2 100644
--- a/glep-0048.rst
+++ b/glep-0048.rst
@@ -76,9 +76,14 @@ 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).  In case of repeated offenses, the QA
+  team may issue a permanent removal of the commit access (retirement).  All
+  the evidence of the violation, as well as ban lenght will be evaluated
+  by the QA team for each case individually.  The disciplinary decisions made
+  by the QA team are subject to appeal via the council.
 * 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

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

[Ulrich Mueller]

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

>>>>> On Fri, 12 Apr 2019, Michał Górny 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.

Comrel is about disciplinary actions, while QA is about the status of
the tree. IMHO we should keep that distinction, and not try to transform
QA into a second Comrel. This has been discussed several times in the
past, and the outcome always was that QA doesn't need such additional
superpowers.

Also in my role as deputy QA lead, I find it strange that you post a
patch to the mailing list, without first discussing your proposal within
the QA team.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Alec Warner]

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

Just as a frame, I'm not on QA.

On Fri, Apr 12, 2019 at 10:40 AM Michał Górny <mgorny@gentoo.org> 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?

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.

If the goal is to move the project in that direction I'd rather see a
vision document or similar ratified by the council to support that
direction than this slow boiling of a frog.


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

[0] This is again my thrust that QA is a enabling team, not a punishment
team. Tools to prevent commits that are bad. Tools to find bad commits
post-commit. Tools to roll-back or revert bad commits. More stuff like "two
branches of ::gentoo "master" and "ci" and maybe rsync / users should
consume the CI'd branch. I don't expect that all developers understand
everything.


>
> Secondly, it clearly defines the possible disciplinary actions as either
> temporary commit access ban, or (in case of repeated offenses) permanent
> removal of commit access.
>

This part seems fine, I think we should have a clearer idea of punishments.


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




> ---
>  glep-0048.rst | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/glep-0048.rst b/glep-0048.rst
> index f9773c0..55a27a2 100644
> --- a/glep-0048.rst
> +++ b/glep-0048.rst
> @@ -76,9 +76,14 @@ 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).  In case of repeated offenses, the
> QA
> +  team may issue a permanent removal of the commit access (retirement).
> All
> +  the evidence of the violation, as well as ban lenght will be evaluated
> +  by the QA team for each case individually.  The disciplinary decisions
> made
> +  by the QA team are subject to appeal via the council.
>  * 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: 7984 bytes --]

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

[Mikle Kolyada]

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



On 12.04.2019 18:19, Ulrich Mueller wrote:
>>>>>> On Fri, 12 Apr 2019, Michał Górny 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.
> Comrel is about disciplinary actions, while QA is about the status of
> the tree.

So you always need ComRel now to confirm obviously made decision.
Is that how you increase the  level of bureaucracy in the distro?

>  IMHO we should keep that distinction, and not try to transform
> QA into a second Comrel. This has been discussed several times in the
> past, and the outcome always was that QA doesn't need such additional
> superpowers.

Please stop spreading misinformation, kind of this policy was discussed
and then developed by Amynka and me past summer, we just did not
implement it due to internal disagreement.

The distinction that ComRel is about relations between devs / users and
its consequences while
QA is about technical violations and its consequences.
>
> Also in my role as deputy QA lead, I find it strange that you post a
> patch to the mailing list, without first discussing your proposal within
> the QA team.
>
> Ulrich



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

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

[William Hubbs]

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

On Fri, Apr 12, 2019 at 04:40:43PM +0200, Michał Górny 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.
> 
> 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.

I would support this because in the very earliest days of the qa team,
qa actions were independent of ComRel.

I have no specific comrel action that I have issues with, but QA actions
should be independent of ComRel. If there are any reasons to belive that
the qa team abuses this, that would be a point where ComRel or the
council could get involved.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Michał Górny]

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

On Fri, 2019-04-12 at 17:19 +0200, Ulrich Mueller wrote:
> > > > > > On Fri, 12 Apr 2019, Michał Górny 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.
> 
> Comrel is about disciplinary actions, while QA is about the status of
> the tree. IMHO we should keep that distinction, and not try to transform
> QA into a second Comrel. This has been discussed several times in the
> past, and the outcome always was that QA doesn't need such additional
> superpowers.

Then how are things exactly supposed to work?  I think you can agree
that the way it's defined now is open to wide range of interpretation.

If I file a bug asking ComRel to consider acting on a developer causing
repeated issues, ComRel's going to close the bug as 'QA business'.  Now,
if I said I'm filing the bug on behalf of QA, QA is going to shot me for
unilaterally requesting something on behalf of QA.

Therefore, according to the de facto policy QA votes first on whether to
ask ComRel to vote for a disciplinary action.  However, by its role
ComRel is not guaranteed to have competence judging QA violations.  How
does this bureaucracy exactly help anyone?

> Also in my role as deputy QA lead, I find it strange that you post a
> patch to the mailing list, without first discussing your proposal within
> the QA team.
> 

Are you suggesting that we should handle such affairs in secret, rather
than discuss them in the open?  How does that help transparency,
especially given all the past accusations of making arbitrary decisions
behind the scenes.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Ulrich Mueller]

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

>>>>> On Fri, 12 Apr 2019, Mikle Kolyada wrote:

> On 12.04.2019 18:19, Ulrich Mueller wrote:
>> IMHO we should keep that distinction, and not try to transform QA
>> into a second Comrel. This has been discussed several times in the
>> past, and the outcome always was that QA doesn't need such additional
>> superpowers.

> Please stop spreading misinformation,

Where have I spread misinformation? I was referring to past discussions
on mailing lists and in council meetings.

> kind of this policy was discussed and then developed by Amynka and
> me past summer, we just did not implement it due to internal
> disagreement.

> The distinction that ComRel is about relations between devs / users
> and its consequences while QA is about technical violations and its
> consequences.

Exactly, and we should keep it this way.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[William Hubbs]

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

On Fri, Apr 12, 2019 at 11:10:39AM -0500, William Hubbs wrote:
> On Fri, Apr 12, 2019 at 04:40:43PM +0200, Michał Górny 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.
> > 
> > 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.
> 
> I would support this because in the very earliest days of the qa team,
> qa actions were independent of ComRel.
> 
> I have no specific comrel action that I have issues with, but QA actions
> should be independent of ComRel. If there are any reasons to belive that
> the qa team abuses this, that would be a point where ComRel or the
> council could get involved.

There are things I would definitely change about the past though.

In the past, the qa lead was the one who could go directly to
infrastructure on his own and ask for people to be blocked. I think the
only way this should happen is after a majority vote on the qa team.

Also, this definitely should not be the first step the qa team takes.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Michał Górny]

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

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Alice Ferrazzi]

On April 13, 2019 1:25:57 AM GMT+09:00, "Michał Górny" <mgorny@gentoo.org> wrote:
>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@gentoo.org>
>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.

I think such problems have to be dealt by using continuous integration checks on commits, not by banning people around.


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Michał Górny]

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

On Sat, 2019-04-13 at 12:07 +0900, Alice Ferrazzi wrote:
> > 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.
> 
> I think such problems have to be dealt by using continuous integration checks on commits, not by banning people around.

And how does that help, if the developer doesn't fix the breakage
introduced?  Effectively he's blocking things for everyone else until
somebody does the work needed to fix his action.

Also, you can't detect everything via CI.  Some things just require
thinking.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Mikle Kolyada]

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



On 12.04.2019 19:12, Ulrich Mueller wrote:
>>>>>> On Fri, 12 Apr 2019, Mikle Kolyada wrote:
>> On 12.04.2019 18:19, Ulrich Mueller wrote:
>>> IMHO we should keep that distinction, and not try to transform QA
>>> into a second Comrel. This has been discussed several times in the
>>> past, and the outcome always was that QA doesn't need such additional
>>> superpowers.
>> Please stop spreading misinformation,
> Where have I spread misinformation? I was referring to past discussions
> on mailing lists and in council meetings.

And I am referring to the QA discussion, where was decided that we need
the policy changes.

>> kind of this policy was discussed and then developed by Amynka and
>> me past summer, we just did not implement it due to internal
>> disagreement.
>> The distinction that ComRel is about relations between devs / users
>> and its consequences while QA is about technical violations and its
>> consequences.
> Exactly, and we should keep it this way.

No, this is not what we have now,  we have ComRel as a redundant layer
in the process of decisions making.
In the best case ComRel will validate QA decision (which is a waste of
time, as the decision had been made just before),
in the case of rejection (which was not the case in the past 6 years),
the QA lead still may appeal to to the Council.

I also want to point out that the change brings nothing new to the
policy, this just sets back these bits QA team lost
in approximately 2011 (needs double check), due to number of unjustified
decisions. I failed to recall unjustified actions
since then (especially after QA team was revived), so I fail to realize
why should not be the QA team fully independent this way,
especially taking into account that decisions still may be appealed to
the Council (as well as ComRel ones).

>
> Ulrich



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

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

[Michał Górny]

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

On Sat, 2019-04-13 at 14:34 +0300, Mikle Kolyada wrote:
> 
> On 12.04.2019 19:12, Ulrich Mueller wrote:
> > > > > > > On Fri, 12 Apr 2019, Mikle Kolyada wrote:
> > > On 12.04.2019 18:19, Ulrich Mueller wrote:
> > > > IMHO we should keep that distinction, and not try to transform QA
> > > > into a second Comrel. This has been discussed several times in the
> > > > past, and the outcome always was that QA doesn't need such additional
> > > > superpowers.
> > > Please stop spreading misinformation,
> > Where have I spread misinformation? I was referring to past discussions
> > on mailing lists and in council meetings.
> 
> And I am referring to the QA discussion, where was decided that we need
> the policy changes.
> 
> > > kind of this policy was discussed and then developed by Amynka and
> > > me past summer, we just did not implement it due to internal
> > > disagreement.
> > > The distinction that ComRel is about relations between devs / users
> > > and its consequences while QA is about technical violations and its
> > > consequences.
> > Exactly, and we should keep it this way.
> 
> No, this is not what we have now,  we have ComRel as a redundant layer
> in the process of decisions making.
> In the best case ComRel will validate QA decision (which is a waste of
> time, as the decision had been made just before),

Then Infra will validate ComRel decision once again, before executing
it.  Except that Infra doesn't debate for days before doing that.

> in the case of rejection (which was not the case in the past 6 years),
> the QA lead still may appeal to to the Council.

In the case of rejection, I expect a serious (please forgive my
language) shitstorm.  Because it would inevitably mean that ComRel is
making decisions that are outside their jurisdiction, and I believe
Council would have to reconsider the competence of ComRel members
in that case.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Andreas K. Huettel]

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

Am Freitag, 12. April 2019, 17:19:44 CEST schrieb Ulrich Mueller:
> >>>>> On Fri, 12 Apr 2019, Michał Górny 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.
> 
> Comrel is about disciplinary actions, while QA is about the status of
> the tree.

comrel is about interpersonal, qa about technical issues.

qa has always had the power to suspend someone's commit access (as last 
resort). the question that remained open was mainly whether such an action had 
to be "nodded off" by comrel. (which should be a formality anyway, since as 
per responsibility areas comrel can't and won't decide technical issues.)

a previous council tried to clarify this (long ago), unfortunately someone 
screwed up when writing the summary, so the issue remained on paper undecided. 

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Andreas K. Huettel]

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

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

I would like to support that this needs clarification. We have seen too many 
things bounced back and forth between qa and comrel and come to nothing in the 
past. 

* person X commits crap (as per qa guideline)
* someone Y complains (shouts at him)
* person X continues to commit crap
* qa leaves a marked statement
* person X continues to commit crap
* Y shouts more
* X complains to comrel
* qa asks comrel to do something
* comrel is more worried about Y than about X
  ("X is technical issue, not our business")
...

please fill in your own preference for x and y

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Andreas K. Huettel]

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

Am Samstag, 13. April 2019, 05:07:12 CEST schrieb Alice Ferrazzi:
>
> I think such problems have to be dealt by using continuous integration
> checks on commits, not by banning people around.

Automated checks are fine and useful, but only if they prevent committing crap 
in the first place (git hook), not if they complain afterwards (ci check).

Add now how many people complain about the incredible hurdle of getting their 
gpg key right once, or about having to add that horrible Signed-Off-By line, 
and you get how popular commit hooks would be.


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michał Górny]

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

On Fri, 2019-04-12 at 11:30 -0400, Alec Warner wrote:
> On Fri, Apr 12, 2019 at 10:40 AM Michał Górny <mgorny@gentoo.org> 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?
> 

Ok, you wanted a driver, so here's some data for the most recent QA ban.

QA finished voting within one day (~8 hours, to be precise), and
requested ComRel to implement the ban in the European evening
of the same day.  ComRel needed whole 4 days to vote for implementing
this.  In the end, according to the data presented to us two ComRel
members have voted against implementing this, and three wanted the ban
length changed.

This proves the existence of two problems.

Firstly, the presence of ComRel in the pipeline has delayed the ban four
days.  You might consider this insignificant if you presume that
the purpose of the ban is to satisfy somebody's petty vengeance, as it
is frequent for ComRel cases.  However, I believe that the ban makes
only sense if it aims to discipline the developer in question,
and disciplining makes sense only if you act reasonably promptly.

The later the ban is established, the more likely it will have adverse
effect of 'I understood my mistakes, I apologized, I improved my
behavior and you're banning me *now*'.  If there were no ComRel
in the pipeline, the ban would be set ~4 days earlier, and finished ~4
days earlier instead of putting the developer in silly position
of knowing that he's been banned but waiting for another body to confirm
it.

Secondly and more importantly, ComRel has failed to vote unanimously. 
This clearly indicates that at least some of the ComRel developers
do not respect QA's jurisdiction over technical issues, and believe that
they have better authority to judge the technical actions of developers.
If that is the case, I'm wondering why those developers haven't
volunteered to join QA and express their opinion in the initial vote,
and instead chose to try to override QA's decision.

In my opinion, the developers who voted 'no' should simply give up their
ComRel hats because they have clearly abused their ComRel position,
in order to make judgment outside their jurisdiction, and therefore
ridiculed the role given to them by GLEP 48.

Of course, unless they believe that QA has abused its powers in making
the vote.  But then, I would have to ask why those ComRel members
decided to address this by silently voting 'no' rather than bringing
this problem to light.

To summarize, I believe the arbitrary and artificial presence of ComRel
in GLEP 48 is simply harmful.  Furthermore, if ComRel was indeed added
because of potential for unprofessional behavior of QA team,
the evidence proves that such additional verification should be added
for ComRel instead.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Mikle Kolyada]

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



On 18.04.2019 15:10, Michał Górny wrote:
> On Fri, 2019-04-12 at 11:30 -0400, Alec Warner wrote:
>> On Fri, Apr 12, 2019 at 10:40 AM Michał Górny <mgorny@gentoo.org> 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?
>>
> [snip]

> In my opinion, the developers who voted 'no' should simply give up their
> ComRel hats because they have clearly abused their ComRel position,
> in order to make judgment outside their jurisdiction, and therefore
> ridiculed the role given to them by GLEP 48.

To clarify, ComRel votes count is less relevant than a direct QA lead
request made to infra.
ComRel is supposed to "nod", while QA lead is responsible for their
actions in front of Council
(as a QA lead is confirmed by Council directly). So this is not an
option to bypass ComRel if needed.



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

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

[Kristian Fiskerstrand]

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

On 4/12/19 4:40 PM, Michał Górny wrote:
>  In case of repeated offenses, the QA
> +  team may issue a permanent removal of the commit access (retirement).

This should still go via comrel, the QA actions should be restricted to
shorter temporary matters.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

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

[Thomas Deutschmann]

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

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


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

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

[Matthew Thode]

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

On 19-04-13 18:30:18, Andreas K. Huettel wrote:
> > 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'.
> 
> I would like to support that this needs clarification. We have seen too many 
> things bounced back and forth between qa and comrel and come to nothing in the 
> past. 
> 
> * person X commits crap (as per qa guideline)
> * someone Y complains (shouts at him)
> * person X continues to commit crap
> * qa leaves a marked statement
> * person X continues to commit crap
> * Y shouts more
> * X complains to comrel
> * qa asks comrel to do something
> * comrel is more worried about Y than about X
>   ("X is technical issue, not our business")
> ...
> 
> please fill in your own preference for x and y
> 

Perhaps QA can refer to council as tech stuff is their domain and seems
like the right escalation path (to me).  They meet monthly but I'm not
sure comrel is much quicker (honestly don't know).  One of the council
members could possibly push for quicker 'discipline' but I'd rather not
rush that aspect.

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Alec Warner]

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

On Tue, Apr 23, 2019 at 2:13 PM Thomas Deutschmann <whissi@gentoo.org>
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
>
>

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

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

[Chí-Thanh Christopher Nguyễn]

Alec Warner schrieb:
> I'd consider alternatives like:
>   - A period where the commits need review.

That is something which I could get behind. This could even be implemented in 
an automated way (checking for Reviewed-By: in the commit). But this is as 
far as QA disciplinary powers should go, and ComRel should take it from there.

Because other than that I don't trust QA at all to make disciplinary 
decisions based on policy. In the past, a package maintained by me has been 
on the receiving end of QA actions (in violation of tree removal policy) 
based on ad hoc made up rules[1]. After QA tried again for a second time[2], 
I had to ask Council to step in and put an end to this, which they did 
fortunately[3].

That was all a long while back, but I have seen similar tree removal policy 
violations on several packages after that by the QA team, so I don't think 
the situation has changed a lot.


Best regards,
Chí-Thanh Christopher Nguyễn


[1] https://bugs.gentoo.org/show_bug.cgi?id=361181
[2] https://bugs.gentoo.org/show_bug.cgi?id=414997
[3] https://projects.gentoo.org/council/meeting-logs/20121113-summary.txt

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

[Michał Górny]

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

On Tue, 2019-04-23 at 17:35 -0400, Alec Warner wrote:
> 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.

Who is going to do the reviewing?  Do you really believe we have
manpower for that?  Should QA be effectively punished by a lot of extra
work by developers who do bad stuff?

I would like to remind we had a developer like that once, and reviewing,
retraining, etc. did not help at all.  He just wasted a lot of time from
a lot of people, and removal was the only solution that actually worked.

It's easy to talk when you invent work for others to do.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Alec Warner]

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

On Wed, Apr 24, 2019 at 2:31 AM Michał Górny <mgorny@gentoo.org> wrote:

> On Tue, 2019-04-23 at 17:35 -0400, Alec Warner wrote:
> > 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.
>
> Who is going to do the reviewing?  Do you really believe we have
> manpower for that?  Should QA be effectively punished by a lot of extra
> work by developers who do bad stuff?
>

I didn't propose who would review. I've seen these systems work in practice:

 - A rotation where a given human is assigned to review stuff over a period
(typically 1w.) This probably works better in an organization with more
fixed time schedules and employees; I wouldn't propose it for Gentoo.
 - A mentor system where you explicitly assign mentors for folks who need
help. Gentoo does some of this already.
 - A system where there are a pool of reviewers, and a robot assigns
(pretty randomly) who reviews what. Gentoo does some of this too.

All of these require staffing, I agree. You rightly ask "is this work worth
it?" and I discuss more of this below.


>
> I would like to remind we had a developer like that once, and reviewing,
> retraining, etc. did not help at all.  He just wasted a lot of time from
> a lot of people, and removal was the only solution that actually worked.
>

I'm sad that we had that kind of experience.


>
> It's easy to talk when you invent work for others to do.
>

QA is work for others to do (its by definition a minimum standard we
require people to meet.) The point isn't that "we should not make work for
others" but instead that we should convince others the work has value. Most
of the project believes QA has value because they want to take pride in
their work and help others use the software they maintain, and use Gentoo
in a useful way; having a minimum quality bar enables this goal. This
mentorship is also extra work (as you note) and I think its worth it
because I think its a good goal for the project to have more contributors,
specifically since "not enough manpower" is a common complaint, and so I
see training and mentorship as a way to grow the contributor base. This
means I favor keeping people instead of removing them. So for contributors
who make many mistakes:

 - Talking to them about why the mistakes were made
 - Improving the tools to detect and prevent the mistakes
 - Offering training for things that are confusing

Its guaranteed some people will not respond to any of the above and they
just can't meet the QA standard set, and those people should not have
commit access (to your point above) but I'm not sure everyone who makes
mistakes falls into that category.

To conclude: I think we should remove people as a last resort, but I think
we should be deliberate when we do it and that means more talking to
individuals. I think so much of this is one sided (QA team decides
arbitrarily) rather than trying to understand why people are not following
the policy and trying to fix it; much of my proposals focus on that part
because I think its more valuable to train and keep contributors, rather
than to remove people who don't meet our QA bar.

-A


>
> --
> Best regards,
> Michał Górny
>
>

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

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

[Mikle Kolyada]

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

On 23.04.2019 21:13, Thomas Deutschmann wrote:

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

Any QA violation that may lead to the breakages of the Gentoo.git tree
and/or infra facilities, in case of QA having enough evidence that those
violations were not false reported (say, by CI checks, scripting or
other developers), and violations take place repeatedly (which said,
nobody is going to issue a disciplinary action just because a developer
slept badly or had eaten a spoiled dinner and that is why they forgot to
add a newline to the end of a file, and let me also point out that
nobody is going to issue a disciplinary action as well if a fact if
violation took place long ago).
 

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

Disciplinary actions are being issued based on the internal team voting.
In the case of emergency (are you aware of idella4?), the QA lead can
request access suspension straight from the Infrastructure team.

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

QA issues warnings via mail, nobody wants public flogging, this also helps
to save a developer authority.

> - However, disciplinary actions must happen in time.

with ComRel presence in the process that is not quite possible, recently
we had a case when the ban was agreed upon within QA team and an
individual was aware of the pending ban,
but taking into account that ComRel gains majority slowly, a developer
had to wait his own ban being confirmed by ComRel, which is totally
unacceptable.

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

We believe this is clear, as the main source of work for Gentoo
developers is related to code,
that means if you lost the commit access you can not arrange your daily
duties, which is not
the main idea of those policy changes.

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

This is supposed to be limited, see the latest version, permabans are
still up to ComRel.


[snip]

> Based on this, I cannot vote for
> https://archives.gentoo.org/gentoo-project/message/548d9c439a73ae38756c0b92a28137ea:

This is obsolete. The new one:
https://archives.gentoo.org/gentoo-project/message/20aa5ce4fe2305d7569f68d9b77d4485

> The changed text grants too much power to QA project.

Nothing new is to be granted, these workflows have been used for ages now,
our aim is to make the policy more clear and transparent.


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



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

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

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

[Alexis Ballier]

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

On Tue, 23 Apr 2019 18:58:16 +0200
Kristian Fiskerstrand <k_f@gentoo.org> wrote:

> On 4/12/19 4:40 PM, Michał Górny wrote:
> >  In case of repeated offenses, the QA
> > +  team may issue a permanent removal of the commit access
> > (retirement).
> 
> This should still go via comrel, the QA actions should be restricted
> to shorter temporary matters.
> 

+1

QA's disciplinary actions are to "stop the bleeding", I don't see any
gain in having shortcuts here besides leaving room for potential
future abuses.

If comrel being slow is an issue, then this may be changed e.g. in
having QA being able to ban for n days and if comrel has been
asked to but hasn't voted for or against a permanent ban after n-1 days
then QA can issue it.
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQSpOxaxaZikKNVNlsYOJUi7xgflrgUCXMMS+wAKCRAOJUi7xgfl
rnn3AP0bt21xOBXja1U2YE5F5gkvM+OwQXyZr3PG+SMcUILecAD+OQn05cCivINd
ofD5ppJma5xIF9aE8IbkhKugOA1O7fI=
=on8D
-----END PGP SIGNATURE-----

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

[Alexis Ballier]

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

On Fri, 12 Apr 2019 18:10:43 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Fri, 2019-04-12 at 17:19 +0200, Ulrich Mueller wrote:
> > > > > > > On Fri, 12 Apr 2019, Michał Górny 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.
> > 
> > Comrel is about disciplinary actions, while QA is about the status
> > of the tree. IMHO we should keep that distinction, and not try to
> > transform QA into a second Comrel. This has been discussed several
> > times in the past, and the outcome always was that QA doesn't need
> > such additional superpowers.
> 
> Then how are things exactly supposed to work?  I think you can agree
> that the way it's defined now is open to wide range of interpretation.
> 
> If I file a bug asking ComRel to consider acting on a developer
> causing repeated issues, ComRel's going to close the bug as 'QA
> business'.  Now, if I said I'm filing the bug on behalf of QA, QA is
> going to shot me for unilaterally requesting something on behalf of
> QA.
> 
> Therefore, according to the de facto policy QA votes first on whether
> to ask ComRel to vote for a disciplinary action.  However, by its role
> ComRel is not guaranteed to have competence judging QA violations.
> How does this bureaucracy exactly help anyone?

comrel shouldn't close the bug as 'QA business': What comrel is
supposed to act on is the "repeated and on purpose" part.
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQSpOxaxaZikKNVNlsYOJUi7xgflrgUCXMMVHAAKCRAOJUi7xgfl
rr7jAP46eAaR03FF6Lo/9ZyI4X6Ps2czp0PeW5u/zGBcdqBS7wD+IkCnbofHYhCH
Tbb2iUh8ExF5rhLlW77n08xU7j8QBdE=
=vHY8
-----END PGP SIGNATURE-----

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

[Alexis Ballier]

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

On Fri, 12 Apr 2019 18:25:57 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Why do you
> presume that ComRel will never abuse its power, and at the same time
> presume QA will kick people 'on a whim'?

comrel does not create any rule. QA does. That's called separation of
powers.
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQSpOxaxaZikKNVNlsYOJUi7xgflrgUCXMMV4QAKCRAOJUi7xgfl
rqqmAP9P0VOjUCO3I1Ld7q7RUOW5q2liwCYSvamUPvH1GPgoTQD/V2kp4nEU1i4B
KVDUc6pXnKyPW2ykaTHOWmQRn1KA2eE=
=yOYD
-----END PGP SIGNATURE-----

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

[Michał Górny]

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

On Fri, 2019-04-26 at 16:29 +0200, Alexis Ballier wrote:
> On Fri, 12 Apr 2019 18:25:57 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > Why do you
> > presume that ComRel will never abuse its power, and at the same time
> > presume QA will kick people 'on a whim'?
> 
> comrel does not create any rule. QA does. That's called separation of
> powers.

If you follow that logic, we end up with ComRel deciding to punish
people based on the private opinions of its members rather than
established rules.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Alexis Ballier]

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

On Fri, 26 Apr 2019 16:55:57 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Fri, 2019-04-26 at 16:29 +0200, Alexis Ballier wrote:
> > On Fri, 12 Apr 2019 18:25:57 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > > Why do you
> > > presume that ComRel will never abuse its power, and at the same
> > > time presume QA will kick people 'on a whim'?
> > 
> > comrel does not create any rule. QA does. That's called separation
> > of powers.
> 
> If you follow that logic, we end up with ComRel deciding to punish
> people based on the private opinions of its members rather than
> established rules.
> 

what logic?
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQSpOxaxaZikKNVNlsYOJUi7xgflrgUCXMMvbQAKCRAOJUi7xgfl
rti3AP9CRvkdH5mHpjp4nnjUVcb9Aror18ejcJGpXHwx9IEIzAEAgFmaBIylAEgd
WLFHegqFaW1HQ7Ea6EcjpBwv8KEVMwk=
=lUIM
-----END PGP SIGNATURE-----

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

[Mikle Kolyada]

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



On 26.04.2019 17:29, Alexis Ballier wrote:
> On Fri, 12 Apr 2019 18:25:57 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>
> > Why do you
> > presume that ComRel will never abuse its power, and at the same time
> > presume QA will kick people 'on a whim'?
>
> comrel does not create any rule. QA does. That's called separation of
> powers.
If I understood you correctly, this is not particularly true. ComRel
changes its policy (because it belongs to ComRel, this is actually how
the proctors project was launched again), at the meantime QA changes its
policy, because GLEP48 is about QA.
The main difference is that ComRel does not have the GLEP describing its
duties, and that is why these changes attract less attention.


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

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

[Alec Warner]

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

On Fri, Apr 26, 2019 at 10:56 AM Michał Górny <mgorny@gentoo.org> wrote:

> On Fri, 2019-04-26 at 16:29 +0200, Alexis Ballier wrote:
> > On Fri, 12 Apr 2019 18:25:57 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> >
> > > Why do you
> > > presume that ComRel will never abuse its power, and at the same time
> > > presume QA will kick people 'on a whim'?
> >
> > comrel does not create any rule. QA does. That's called separation of
> > powers.
>
> If you follow that logic, we end up with ComRel deciding to punish
> people based on the private opinions of its members rather than
> established rules.
>

So when the QA team votes to punish someone, how is that not "based on the
private opinions of QA team members" and as opposed to "a set of
established rules?"

This is an important distinction. There is a recent article[0] about how
Amazon has automated the firing of employees in their warehouses because
they have a minimum quota (work / time) for workers and if you miss your
quota too often, the computer terminates you. Many people don't like this
because it removes a critical factor of human *judgement*; that the rules
are not sufficient to judge every situation. There is context around each
situation (worker was ill, had person issues that impacted their speed, has
problems with other co-workers, etc) and so just "well bob didn't work fast
enough" is not sufficient for termination.

I'm suggesting that someone has to have this judgement. In Gentoo I think
there are four judgments to be made:
(0) Create the list of QA rules. This is firmly in the QA team's purview.
(1) Was a rule broken? Gentoo work is more complex than Amazon's warehouse
work, so this question is not as simple as "bob missed his picking quota by
10% last month" because many QA violations have associated context and
engineering tradeoffs (which is why humans are doing them.) So we cannot
just automate this step.
(2) Why was the rule broken? This is a question Amazon seems not to be
asking according to the article (they just fire anyone who doesn't meet
quota), but I suggest we do ask it because it helps us improve the rules
and developer process. Understanding why violations happen help us prevent
and mitigate them.
(3) If a developer makes deliberate repeated mistakes over a time period,
what do we do about it?

I think 0-2 are clearly in the realm of the QA team to judge. I'm less
convinced of (3) and this is the judgement I expect Comrel to be making
because I believe this is not a technical problem. Ultimately if people
refuse to follow the policies of the organization they should either get
the policies modified, or leave.

[0]
https://www.businessinsider.com/amazon-system-automatically-fires-warehouse-workers-time-off-task-2019-4


> --
> Best regards,
> Michał Górny
>
>

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

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

[Michał Górny]

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

On Fri, 2019-04-26 at 18:18 +0200, Alexis Ballier wrote:
> On Fri, 26 Apr 2019 16:55:57 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Fri, 2019-04-26 at 16:29 +0200, Alexis Ballier wrote:
> > > On Fri, 12 Apr 2019 18:25:57 +0200
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > > 
> > > > Why do you
> > > > presume that ComRel will never abuse its power, and at the same
> > > > time presume QA will kick people 'on a whim'?
> > > 
> > > comrel does not create any rule. QA does. That's called separation
> > > of powers.
> > 
> > If you follow that logic, we end up with ComRel deciding to punish
> > people based on the private opinions of its members rather than
> > established rules.
> > 
> 
> what logic?

The logic that ComRel apparently doesn't create rules.  Ergo, ComRel
punishes without rules.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:
>>> If you follow that logic, we end up with ComRel deciding to punish
>>> people based on the private opinions of its members rather than
>>> established rules.
>>
>> what logic?
> 
> The logic that ComRel apparently doesn't create rules.  Ergo, ComRel
> punishes without rules.

I don't think so. ComRel does not create the rules. While they do have 
internally established procedures how to deal with things, the important 
rules by which they operate are imposed from outside.

There is however no transparency in ComRel, so it is not possible to tell for 
non-members (including subjects of disciplinary action) whether these rules 
were adhered to, or whether there has been any misconduct etc. but that is a 
different matter.


Best regards,
Chí-Thanh Christopher Nguyễn

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

[Michał Górny]

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

On Sat, 2019-04-27 at 03:04 +0200, Chí-Thanh Christopher Nguyễn wrote:
> Michał Górny schrieb:
> > > > If you follow that logic, we end up with ComRel deciding to punish
> > > > people based on the private opinions of its members rather than
> > > > established rules.
> > > 
> > > what logic?
> > 
> > The logic that ComRel apparently doesn't create rules.  Ergo, ComRel
> > punishes without rules.
> 
> I don't think so. ComRel does not create the rules. While they do have 
> internally established procedures how to deal with things, the important 
> rules by which they operate are imposed from outside.
> 

It all depends on where you set the line between 'rules imposed from
outside' and 'rules (procedures) internally established'.  QA doesn't go
out of their way to introduce abstract rules either, it mostly builds
more precise rules from generic directives 'imposed from outside'.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Alexis Ballier]

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

On Fri, 26 Apr 2019 22:06:36 +0300
Mikle Kolyada <zlogene@gentoo.org> wrote:

> 
> 
> On 26.04.2019 17:29, Alexis Ballier wrote:
> > On Fri, 12 Apr 2019 18:25:57 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> >
> > > Why do you
> > > presume that ComRel will never abuse its power, and at the same
> > > time presume QA will kick people 'on a whim'?
> >
> > comrel does not create any rule. QA does. That's called separation
> > of powers.
> If I understood you correctly, this is not particularly true. ComRel
> changes its policy (because it belongs to ComRel, this is actually how
> the proctors project was launched again), at the meantime QA changes
> its policy, because GLEP48 is about QA.
> The main difference is that ComRel does not have the GLEP describing
> its duties, and that is why these changes attract less attention.
> 


What I meant is that being judge and party (what this QA change is
about) is a highway to abuses. This does not prevent all of them, but I
believe having them separate is a very important barrier.
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQSpOxaxaZikKNVNlsYOJUi7xgflrgUCXMbBBQAKCRAOJUi7xgfl
riHKAPwJt8ogc74iU1O/D2TqL34WnruZBlwekMPzD/My6mwQ9QD8CpnJq5oxUSt0
RRTtSG364yGbzHk5bdUISnGL0eQ1rZg=
=CXJ/
-----END PGP SIGNATURE-----

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

[Alexis Ballier]

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

On Sat, 27 Apr 2019 08:09:23 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sat, 2019-04-27 at 03:04 +0200, Chí-Thanh Christopher Nguyễn wrote:
> > Michał Górny schrieb:
> > > > > If you follow that logic, we end up with ComRel deciding to
> > > > > punish people based on the private opinions of its members
> > > > > rather than established rules.
> > > > 
> > > > what logic?
> > > 
> > > The logic that ComRel apparently doesn't create rules.  Ergo,
> > > ComRel punishes without rules.
> > 
> > I don't think so. ComRel does not create the rules. While they do
> > have internally established procedures how to deal with things, the
> > important rules by which they operate are imposed from outside.
> > 
> 
> It all depends on where you set the line between 'rules imposed from
> outside' and 'rules (procedures) internally established'.  QA doesn't
> go out of their way to introduce abstract rules either, it mostly
> builds more precise rules from generic directives 'imposed from
> outside'.
> 


Right but you are missing the point here: comrel does not create "if X
then ban Y days" type of rules. comrel reacts to complaints: this is
what is imposed from outside. Obviously there is no algorithmic rule in
that kind of procedure.
QA, on the other hand, does create "this does not belong to gentoo.git"
types of rules that apply to anyone.
-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQSpOxaxaZikKNVNlsYOJUi7xgflrgUCXMbFpwAKCRAOJUi7xgfl
rv7AAP4zMKkMzSLMaxsh3Ss7fyP3liBmvnqNZjprdMOy0NWbuQD/YxLCLIywlNls
E9BFQ9YjxmWZW98/w8rqz7IxZ31LNdA=
=64bw
-----END PGP SIGNATURE-----