1 |
On Fri, Jul 24, 2020 at 03:59:45PM +0200, Michał Górny wrote: |
2 |
> Hi, |
3 |
> |
4 |
> TL;DR: the current punishment-based disciplinary (ComRel/QA) model |
5 |
> doesn't work very well. Most of the time it is tedious and results |
6 |
> in a ban that doesn't solve anything, and effectively ends up being |
7 |
> harmful to users (as a third party). I would like to discuss replacing |
8 |
> it with a model that focuses on improvement and making amends. |
9 |
> |
10 |
|
11 |
[snip] |
12 |
|
13 |
> QA: developer X, please follow the standards. |
14 |
> [silence] |
15 |
> QA: developer X, ping. |
16 |
> [silence] |
17 |
> QA: developer X, please answer or else... |
18 |
> [silence] |
19 |
> QA: developer X, we issue official warning. |
20 |
> [*shrug*] |
21 |
> <a few warnings later> |
22 |
> QA: we issue 14 day ban for developer X. |
23 |
> dev X: bad QA! I never got any warnings! They didn't really try to |
24 |
> reach out! [to users] I'm sorry, this guy has banned me so I can't bump |
25 |
> Y, it's all their fault. |
26 |
> |
27 |
|
28 |
People will always find excuses. It is the easiest way to avoid |
29 |
confrontation, be lazy, and "play the sympathy card." |
30 |
|
31 |
> As I said, the problem is that ban is the kind of punishment that harms |
32 |
> users more than misbehaving developers. While it might make sense to |
33 |
> issue short bans to let people cool down (this is proctors' area), bans |
34 |
> to punish misbehavior block good actions as much as bad. |
35 |
> |
36 |
|
37 |
Agreed. Users do lose out especially when the developer is responsible |
38 |
for "high profile" packages. |
39 |
|
40 |
> |
41 |
> Improvement-targeted disciplinary actions |
42 |
> ========================================= |
43 |
> The key point in my proposal is to remove temporary bans from ComRel/QA |
44 |
> disciplinary actions entirely. Instead, we should focus on giving |
45 |
> developers specific 'improvement' tasks. |
46 |
> |
47 |
|
48 |
Yes! I would also explain this as constructive criticism from a |
49 |
"sanctioned" body that reports directly to the council. As long as the |
50 |
QA team maintains professionalism then this approach works really well. |
51 |
Document the exchanges on restricted bugs as well. |
52 |
|
53 |
> For example, if a developer keeps committing broken ebuilds without |
54 |
> testing them properly, he is asked to fix the tests in some of these |
55 |
> pacakges. If a developer keeps making bad commit messages, he is |
56 |
> required to start using better commit messages. If a developer insults |
57 |
> somebody else, he's asked to apologize and make amends. No temporary |
58 |
> ban, just a request to do something in limited time. |
59 |
> |
60 |
|
61 |
Yes! Of course, some individuals will claim their time is precious and |
62 |
they cannot meet X timeline. If this is the case, I would propose that |
63 |
one *short* extension be given. Beyond that, the proceedings continue. |
64 |
|
65 |
> Now, if the developer deliberately refuses to make amends, then I think |
66 |
> we shouldn't play cat-and-mouse any longer and immediately go for |
67 |
> retirement. Of course, with possibility of appeal to the Council |
68 |
> and the usual rights but without the 'N bans' game before it. |
69 |
> |
70 |
|
71 |
Yup! These things aren't hard. I myself have had interactions with QA |
72 |
and find the exchanges very simple: |
73 |
|
74 |
QA: "Please abide by these rules/regulations so we do not have to take |
75 |
this further" |
76 |
|
77 |
Me: "Cool, will do, thanks" |
78 |
|
79 |
Problem solved. Anything beyond this, IMHO, is someone just trying to |
80 |
"buck" the system or cause strife. |
81 |
|
82 |
-- |
83 |
Cheers, |
84 |
Aaron |