1 |
On 10/07/2016 08:13 AM, Rich Freeman wrote: |
2 |
> On Fri, Oct 7, 2016 at 10:54 AM, Nick Vinson <nvinson234@×××××.com> wrote: |
3 |
>> |
4 |
>> On 10/07/2016 07:32 AM, Raymond Jennings wrote: |
5 |
>>> On Fri, Oct 7, 2016 at 7:20 AM, Rich Freeman <rich0@g.o> wrote: |
6 |
>>>> On Fri, Oct 7, 2016 at 10:05 AM, Raymond Jennings <shentino@×××××.com> |
7 |
>>>> wrote: |
8 |
>>>>> My opinion is that if a developer is bad enough to keep out, its also |
9 |
>>>>> important enough to get the paperwork fixed to prove it. If they |
10 |
>>>>> have a |
11 |
>>>>> clean case it *should* be very easy to get the paperwork right. |
12 |
>>>> |
13 |
>>>> Sure, by all means leave the bug open until the paperwork is fixed, |
14 |
>>>> but I don't think that means that the developer should be allowed back |
15 |
>>>> in if the bug isn't closed before some deadline. |
16 |
>>> |
17 |
>>> What I want to prevent is a stagnation where a dev gets mistakenly |
18 |
>>> locked out because his case got left in limbo. |
19 |
>>> |
20 |
>>>>> But its the "due process" here that proves the developer is bad to |
21 |
>>>>> begin |
22 |
>>>>> with. If comrel screwed up and there was a mistake and the |
23 |
>>>>> developer is |
24 |
>>>>> actually meritorious, its bad for gentoo to keep them out. |
25 |
>>> |
26 |
>>>> Sure, if all three of your preconditions are true I agree with your |
27 |
>>>> conclusion. However, if comrel screwed up and there was a mistake and |
28 |
>>>> the developer is actually still a problem, then the solution is to fix |
29 |
>>>> the mistakes, not keep them around. |
30 |
>>> |
31 |
>>> And how do you know whether the developer is a problem or not? |
32 |
> |
33 |
> The same way Comrel knows. You look at the evidence and draw a |
34 |
> conclusion. If you don't trust somebody to do that, you shouldn't be |
35 |
> putting them on the Council. |
36 |
> |
37 |
>> |
38 |
>> If ComRel screwed |
39 |
>> up, then "fixing" the mistake is also reversing their decisions that |
40 |
>> includes bringing back the dev. If the developer is really a problem, |
41 |
>> then ComRel will be given repeated chances to deal with the developer |
42 |
>> and eventually (well hopefully not eventually) the "due process" will be |
43 |
>> done correctly and the developer will be removed. |
44 |
> |
45 |
> And what happens when somebody sues Gentoo or one of its contributors |
46 |
> for not doing enough to deal with a problem, because we're fighting |
47 |
> over process when there is agreement that the person in question ought |
48 |
> to go? |
49 |
|
50 |
The same thing that happens when somebody sues Gentoo or one of its |
51 |
contributors for discrimination or some other related charge because it |
52 |
overreacted to a problem and punished an innocent developer. |
53 |
|
54 |
That said, if there are concerns about legal issues relating to Gentoo |
55 |
policy or procedures, then the Trustees need to be notified so they can |
56 |
look into it. Neither the council nor ComRel are staffed with the |
57 |
expectation to understand or act on potential legal issues. The |
58 |
Trustees, on the other hand, are expected to address legal concerns in |
59 |
whatever manner is appropriate. They are the ones, after-all, that |
60 |
would have to deal with any lawsuit against the Gentoo foundation. |
61 |
|
62 |
> |
63 |
>> To me this really seems to follow the line of thinking of "If the dev |
64 |
>> was really innocent of any wrong doing, no complaint would have been |
65 |
>> filed". I hope that's not the case because I find that style of logic |
66 |
>> to be both naive and dangerous. |
67 |
> |
68 |
> This would only be a valid criticism if every complaint resolved in |
69 |
> the harshest possible punishment. From the sound of things most |
70 |
> complaints result in no action at all. As far as I can tell most |
71 |
> Comrel actions aren't even appealed. After all, the matter that |
72 |
> started this whole discussion wasn't even appealed to the whole of |
73 |
> Comrel let alone to the Council. |
74 |
> |