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 |