Gentoo Archives: gentoo-project

From: Alexis Ballier <aballier@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] [PATCH v3] glep-0048: Provide clear rules for disciplinary actions
Date: Mon, 29 Apr 2019 16:23:39
Message-Id: 20190429182330.1d61d368@gentoo.org
In Reply to: Re: [gentoo-project] [PATCH v3] glep-0048: Provide clear rules for disciplinary actions by "Michał Górny"
1 On Mon, 29 Apr 2019 17:53:21 +0200
2 Michał Górny <mgorny@g.o> wrote:
3
4 > > Also, "impacting the work of other developers" is not QA's
5 > > responsibility and due to the fact that you cannot really define
6 > > that
7 >
8 > For example, it means that the QA breakage you've introduced and
9 > refuse to fix is preventing other developers from working on their
10 > ebuilds.
11
12 It is QA's role to jump and fix it to minimize the impact on other
13 developers. And because it is not fun to do so if someone is not
14 cooperating, I believe short bans in the hands of QA's team make sense,
15 even if I dislike the idea.
16
17 [...]
18 > > 3) 30 days is too long. Like said, Gentoo should never be about
19 > > disciplinary actions but it looks like some current QA members want
20 > > to change that. I am against that change:
21 >
22 > Tell that to ComRel. If Proctors reduce their maximum disciplinary
23 > action, I will adjust the spec. Otherwise, this is moot point.
24
25
26 What's the relation with proctors here?
27
28 > > For me the important difference is: Gentoo is not 'real life'. I.e.
29 > > in life you cannot always chose the people you have to deal with.
30 > > So we have laws and policy to be prepared against people we cannot
31 > > avoid. But assuming that everyone in Gentoo is sharing the same
32 > > goals (for Gentoo) and has accepted CoC, a situation like this
33 > > shouldn't be normal. Therefore we don't need to give a project like
34 > > QA the absolute power to protect us just in case of an emergency
35 >
36 > This is not to protect anyone in emergencies. This is to enforce
37 > a clear split between handling of social and technical problems.
38 > ComRel just isn't the right body to judge technical issues caused by
39 > developers.
40
41 What you're missing here is that repeated uncooperative behavior is no
42 longer technical, this becomes comrel's grounds.
43
44 [..]

Replies