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 |
> |