Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] [RFC] More improvement-targeted approach to disciplinary actions (aka removing bans)
Date: Fri, 24 Jul 2020 20:22:12
Message-Id: 693cf5cb9ac349685f5a1fa83544ab2b539569b4.camel@gentoo.org
In Reply to: Re: [gentoo-project] [RFC] More improvement-targeted approach to disciplinary actions (aka removing bans) by Joonas Niilola
1 On Fri, 2020-07-24 at 17:21 +0300, Joonas Niilola wrote:
2 > On 7/24/20 4:59 PM, Michał Górny wrote:
3 > > Hi,
4 > >
5 > > TL;DR: the current punishment-based disciplinary (ComRel/QA) model
6 > > doesn't work very well. Most of the time it is tedious and results
7 > > in a ban that doesn't solve anything, and effectively ends up being
8 > > harmful to users (as a third party). I would like to discuss replacing
9 > > it with a model that focuses on improvement and making amends.
10 >
11 > Sometimes I wish I was banned, so I could keep a two week vacation from
12 > any Gentoo related work with good conscience.
13
14 What about the feeling of guilt that you did something to get banned?
15 ;-)
16
17 > QA: developer X, please follow the standards.
18 > > [silence]
19 > > QA: developer X, ping.
20 > > [silence]
21 > > QA: developer X, please answer or else...
22 > > [silence]
23 > > QA: developer X, we issue official warning.
24 > > [*shrug*]
25 > > <a few warnings later>
26 > > QA: we issue 14 day ban for developer X.
27 > > dev X: bad QA! I never got any warnings! They didn't really try to
28 > > reach out! [to users] I'm sorry, this guy has banned me so I can't bump
29 > > Y, it's all their fault.
30 > >
31 > I'm fine with your solution, retiring the dev if they refuse to
32 > co-operate. However I'd like to see a full pseudo-example here what
33 > happens before the retirement by Comrel/QA. A list of all steps. And by
34 > this time, I'd say to have 1 strike before retirement, with a cooldown
35 > of say 1-2 years. Just to eradicate any human errors from the process,
36 > and I believe everyone deserves a 2nd chance.
37 >
38
39 Ok, so let's compare what happens once initial 'friendly comms' between
40 devs fail and QA is asked to intervene.
41
42
43 Currently:
44
45 1. QA communicates with the dev, asks nicely.
46
47 2. If this fails, QA votes on issuing a warning. Once the warning is
48 issued, the process is done and dev doesn't formally have to fix
49 the issue.
50
51 3. If another problem occurs and the dev is reported again, the process
52 repeats at least once, to a second warning.
53
54 4. If developer is reported again and the process fails again,
55 the developer gets a short-time ban.
56
57 5. QA generally issues at least one more ban if a problem happens again
58 and the developer keeps refusing to cooperate.
59
60 6. Eventually (so at least after being completely uncooperative at least
61 5 times in a row), QA votes on requesting ComRel to remove commit access
62 permanently.
63
64
65 Per the new process:
66
67 1. QA communicates with the dev, asks nicely.
68
69 2. If this fails, QA prepares a reasonable list of tasks to be done
70 (usually, fix a reasonable subset of the issues that provoked the QA
71 response). Of course, all guidance is provided as necessary and time
72 can be extended to account for developer's needs.
73
74 3. If the developer shows effort to solve the problem, case closed.
75 On the other hand, if he refuses to cooperate, QA requests ComRel to
76 remove commit access.
77
78 To be honest, I don't think we need '1 strike'. The whole point is that
79 if the developer understands the problem and wants to fix it, then
80 the problem is solved and there's no harm done. On the other hand,
81 if the developer doesn't want to cooperate, then I don't really
82 understand the point of a 'second chance' (to do what? figure out a way
83 not to follow standards and stay under the radar?)
84
85 Am I missing something?
86
87 --
88 Best regards,
89 Michał Górny

Attachments

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

Replies