Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Subject: [gentoo-project] [RFC] More improvement-targeted approach to disciplinary actions (aka removing bans)
Date: Fri, 24 Jul 2020 13:59:52
Message-Id: 5ced7d1a2a5133aca2521b7126b33f8eaa5bd0b2.camel@gentoo.org
1 Hi,
2
3 TL;DR: the current punishment-based disciplinary (ComRel/QA) model
4 doesn't work very well. Most of the time it is tedious and results
5 in a ban that doesn't solve anything, and effectively ends up being
6 harmful to users (as a third party). I would like to discuss replacing
7 it with a model that focuses on improvement and making amends.
8
9
10 Disclaimer: I am a QA member, so I know the QA process more than
11 the ComRel process. However, I think that both of them are similar
12 enough not to require separate discussion.
13
14 Disclaimer 2: I do realize that 'disciplinary actions' are not the only
15 part of ComRel/QA process that might need changes. However, I would
16 really like to keep this thread focused, so please assume that we're
17 talking about the situation that ComRel/QA (according to the current or
18 any future process) has established that there's no 'friendly' way to
19 resolve the problem, and a disciplinary action needs to be taken.
20
21 In other words, please don't turn this into 'punishing people for making
22 mistakes'. Mistakes are acceptable, and they should be fixed. This is
23 about the case that developers repeatedly misbehave (violate standards)
24 and refuse to improve.
25
26
27 The current model and what's wrong with it
28 ==========================================
29 The current model assumes that if developer does not willingly want to
30 improve, we should try to use force. This 'force' comes in a few
31 variants:
32
33 1. warnings,
34
35 2. temporary bans (= more firm warnings),
36
37 3. eventually, commit access removal / retirement.
38
39 In my opinion, this works real poor. While warnings make sense, bans
40 don't really help much. Firstly, because they do not encourage
41 developers to fix their mistakes (actually, they prevent them from doing
42 it earlier). Secondly, because they sometimes impact users (= innocent
43 third parties) more than the developer in question. Thirdly, they don't
44 scale well to various kinds of violations.
45
46 The whole process assumes that developers value not being banned,
47 and wish to do their best to follow standards. However, if that were
48 the case we wouldn't be needing a disciplinary process in the first
49 place.
50
51 Sadly, often the result of bans is not improvement and fixing of
52 mistakes but even more stubbornness and attempts at revenge. In the end,
53 members of the disciplinary body put much more effort into this than
54 the guilty developer, and we just spend a lot of time on due effort that
55 results in zero improvement.
56
57 What's even worse, some developers are literally trying hard to push
58 the limits and see what they can get away with. We end up with lots of
59 minor violations, none of them justifying any real disciplinary action
60 yet causing a lot of negativity as a result.
61
62 A typical case of disciplinary action lately can be illustrated as:
63
64 QA: developer X, please follow the standards.
65 [silence]
66 QA: developer X, ping.
67 [silence]
68 QA: developer X, please answer or else...
69 [silence]
70 QA: developer X, we issue official warning.
71 [*shrug*]
72 <a few warnings later>
73 QA: we issue 14 day ban for developer X.
74 dev X: bad QA! I never got any warnings! They didn't really try to
75 reach out! [to users] I'm sorry, this guy has banned me so I can't bump
76 Y, it's all their fault.
77
78 As I said, the problem is that ban is the kind of punishment that harms
79 users more than misbehaving developers. While it might make sense to
80 issue short bans to let people cool down (this is proctors' area), bans
81 to punish misbehavior block good actions as much as bad.
82
83
84 Improvement-targeted disciplinary actions
85 =========================================
86 The key point in my proposal is to remove temporary bans from ComRel/QA
87 disciplinary actions entirely. Instead, we should focus on giving
88 developers specific 'improvement' tasks.
89
90 For example, if a developer keeps committing broken ebuilds without
91 testing them properly, he is asked to fix the tests in some of these
92 pacakges. If a developer keeps making bad commit messages, he is
93 required to start using better commit messages. If a developer insults
94 somebody else, he's asked to apologize and make amends. No temporary
95 ban, just a request to do something in limited time.
96
97 Now, if the developer deliberately refuses to make amends, then I think
98 we shouldn't play cat-and-mouse any longer and immediately go for
99 retirement. Of course, with possibility of appeal to the Council
100 and the usual rights but without the 'N bans' game before it.
101
102 WDYT?
103
104 --
105 Best regards,
106 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies