Gentoo Archives: gentoo-project

From: Alec Warner <antarus@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Subject: Re: [gentoo-project] [PATCH] glep-0048: Provide clear rules for disciplinary actions
Date: Wed, 24 Apr 2019 14:32:13
Message-Id: CAAr7Pr-m8sTeaSt8Kdad-c5yeL39Cn_dt9yANEREcYEwJx=p5g@mail.gmail.com
In Reply to: Re: [gentoo-project] [PATCH] glep-0048: Provide clear rules for disciplinary actions by "Michał Górny"
1 On Wed, Apr 24, 2019 at 2:31 AM Michał Górny <mgorny@g.o> wrote:
2
3 > On Tue, 2019-04-23 at 17:35 -0400, Alec Warner wrote:
4 > > I don't think committers who violate policy will be changed by a ban.
5 > > Certainly not a ban that is time-delimited (it means I get a 2 week
6 > gentoo
7 > > vacation!) I'd consider alternatives like:
8 > > - A period where the commits need review.
9 >
10 > Who is going to do the reviewing? Do you really believe we have
11 > manpower for that? Should QA be effectively punished by a lot of extra
12 > work by developers who do bad stuff?
13 >
14
15 I didn't propose who would review. I've seen these systems work in practice:
16
17 - A rotation where a given human is assigned to review stuff over a period
18 (typically 1w.) This probably works better in an organization with more
19 fixed time schedules and employees; I wouldn't propose it for Gentoo.
20 - A mentor system where you explicitly assign mentors for folks who need
21 help. Gentoo does some of this already.
22 - A system where there are a pool of reviewers, and a robot assigns
23 (pretty randomly) who reviews what. Gentoo does some of this too.
24
25 All of these require staffing, I agree. You rightly ask "is this work worth
26 it?" and I discuss more of this below.
27
28
29 >
30 > I would like to remind we had a developer like that once, and reviewing,
31 > retraining, etc. did not help at all. He just wasted a lot of time from
32 > a lot of people, and removal was the only solution that actually worked.
33 >
34
35 I'm sad that we had that kind of experience.
36
37
38 >
39 > It's easy to talk when you invent work for others to do.
40 >
41
42 QA is work for others to do (its by definition a minimum standard we
43 require people to meet.) The point isn't that "we should not make work for
44 others" but instead that we should convince others the work has value. Most
45 of the project believes QA has value because they want to take pride in
46 their work and help others use the software they maintain, and use Gentoo
47 in a useful way; having a minimum quality bar enables this goal. This
48 mentorship is also extra work (as you note) and I think its worth it
49 because I think its a good goal for the project to have more contributors,
50 specifically since "not enough manpower" is a common complaint, and so I
51 see training and mentorship as a way to grow the contributor base. This
52 means I favor keeping people instead of removing them. So for contributors
53 who make many mistakes:
54
55 - Talking to them about why the mistakes were made
56 - Improving the tools to detect and prevent the mistakes
57 - Offering training for things that are confusing
58
59 Its guaranteed some people will not respond to any of the above and they
60 just can't meet the QA standard set, and those people should not have
61 commit access (to your point above) but I'm not sure everyone who makes
62 mistakes falls into that category.
63
64 To conclude: I think we should remove people as a last resort, but I think
65 we should be deliberate when we do it and that means more talking to
66 individuals. I think so much of this is one sided (QA team decides
67 arbitrarily) rather than trying to understand why people are not following
68 the policy and trying to fix it; much of my proposals focus on that part
69 because I think its more valuable to train and keep contributors, rather
70 than to remove people who don't meet our QA bar.
71
72 -A
73
74
75 >
76 > --
77 > Best regards,
78 > Michał Górny
79 >
80 >