From: Lars Wendler <polynomial-c@gentoo.org>
To: "Michał Górny" <mgorny@gentoo.org>
Cc: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] [RFC] More improvement-targeted approach to disciplinary actions (aka removing bans)
Date: Sat, 25 Jul 2020 12:01:29 +0200 [thread overview]
Message-ID: <20200725120129.4b7076df@abudhabi.paradoxon.rec> (raw)
In-Reply-To: <5ced7d1a2a5133aca2521b7126b33f8eaa5bd0b2.camel@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 5127 bytes --]
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
[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2020-07-25 10:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-24 13:59 [gentoo-project] [RFC] More improvement-targeted approach to disciplinary actions (aka removing bans) Michał Górny
2020-07-24 14:21 ` Joonas Niilola
2020-07-24 20:22 ` Michał Górny
2020-07-27 7:27 ` Joonas Niilola
2020-07-27 7:34 ` Michał Górny
2020-07-24 16:15 ` Aaron Bauman
2020-07-25 10:01 ` Lars Wendler [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200725120129.4b7076df@abudhabi.paradoxon.rec \
--to=polynomial-c@gentoo.org \
--cc=gentoo-project@lists.gentoo.org \
--cc=mgorny@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox