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@g.o> 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@g.o>
>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.