Gentoo Archives: gentoo-project

From: Aaron Bauman <bman@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 16:15:58
Message-Id: 20200724161553.GA10049@bubba
In Reply to: [gentoo-project] [RFC] More improvement-targeted approach to disciplinary actions (aka removing bans) by "Michał Górny"
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

Attachments

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