Re: [gentoo-project] [RFC] More improvement-targeted approach to disciplinary actions (aka removing bans)

[Lars Wendler]

On Fri, 24 Jul 2020 15:59:45 +0200 Michał Górny wrote:

>Hi,
>
>TL;DR: the current punishment-based disciplinary (ComRel/QA) model
>doesn't work very well.  Most of the time it is tedious and results
>in a ban that doesn't solve anything, and effectively ends up being
>harmful to users (as a third party).  I would like to discuss replacing
>it with a model that focuses on improvement and making amends.
>
>
>Disclaimer: I am a QA member, so I know the QA process more than
>the ComRel process.  However, I think that both of them are similar
>enough not to require separate discussion.
>
>Disclaimer 2: I do realize that 'disciplinary actions' are not the only
>part of ComRel/QA process that might need changes.  However, I would
>really like to keep this thread focused, so please assume that we're
>talking about the situation that ComRel/QA (according to the current or
>any future process) has established that there's no 'friendly' way to
>resolve the problem, and a disciplinary action needs to be taken.
>
>In other words, please don't turn this into 'punishing people for
>making mistakes'.  Mistakes are acceptable, and they should be fixed.
>This is about the case that developers repeatedly misbehave (violate
>standards) and refuse to improve.
>
>
>The current model and what's wrong with it
>==========================================
>The current model assumes that if developer does not willingly want to
>improve, we should try to use force.  This 'force' comes in a few
>variants:
>
>1. warnings,
>
>2. temporary bans (= more firm warnings),
>
>3. eventually, commit access removal / retirement.
>
>In my opinion, this works real poor.  While warnings make sense, bans
>don't really help much.  Firstly, because they do not encourage
>developers to fix their mistakes (actually, they prevent them from
>doing it earlier).  Secondly, because they sometimes impact users (=
>innocent third parties) more than the developer in question.  Thirdly,
>they don't scale well to various kinds of violations.
>
>The whole process assumes that developers value not being banned,
>and wish to do their best to follow standards.  However, if that were
>the case we wouldn't be needing a disciplinary process in the first
>place.
>
>Sadly, often the result of bans is not improvement and fixing of
>mistakes but even more stubbornness and attempts at revenge. In the
>end, members of the disciplinary body put much more effort into this
>than the guilty developer, and we just spend a lot of time on due
>effort that results in zero improvement.
>
>What's even worse, some developers are literally trying hard to push
>the limits and see what they can get away with.  We end up with lots of
>minor violations, none of them justifying any real disciplinary action
>yet causing a lot of negativity as a result.
>
>A typical case of disciplinary action lately can be illustrated as:
>
>QA: developer X, please follow the standards.
>[silence]
>QA: developer X, ping.
>[silence]
>QA: developer X, please answer or else...
>[silence]
>QA: developer X, we issue official warning.
>[*shrug*]
><a few warnings later>
>QA: we issue 14 day ban for developer X.
>dev X: bad QA!  I never got any warnings!  They didn't really try to
>reach out!  [to users] I'm sorry, this guy has banned me so I can't
>bump Y, it's all their fault.
>
>As I said, the problem is that ban is the kind of punishment that harms
>users more than misbehaving developers.  While it might make sense to
>issue short bans to let people cool down (this is proctors' area), bans
>to punish misbehavior block good actions as much as bad.
>
>
>Improvement-targeted disciplinary actions
>=========================================
>The key point in my proposal is to remove temporary bans from ComRel/QA
>disciplinary actions entirely.  Instead, we should focus on giving
>developers specific 'improvement' tasks.
>
>For example, if a developer keeps committing broken ebuilds without
>testing them properly, he is asked to fix the tests in some of these
>pacakges.  If a developer keeps making bad commit messages, he is
>required to start using better commit messages.  If a developer insults
>somebody else, he's asked to apologize and make amends.  No temporary
>ban, just a request to do something in limited time.
>
>Now, if the developer deliberately refuses to make amends, then I think
>we shouldn't play cat-and-mouse any longer and immediately go for
>retirement.  Of course, with possibility of appeal to the Council
>and the usual rights but without the 'N bans' game before it.
>
>WDYT?
>

My first thought after reading this was: "Well yeah, sure we can do
this and make the lack of developers even worse."
Yes, comrel and QA might not have a perfect way to solve issues, but I
doubt there is a "perfect" way to solve the stuff you described.
And I don't believe that your suggested solutions really improve this.

Cheers
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39