| 1 |
Alec Warner: |
| 2 |
> On Wed, Apr 10, 2019 at 2:17 AM Alice Ferrazzi <alicef@g.o> wrote: |
| 3 |
> |
| 4 |
>> The 04/10/2019 07:59, Ulrich Mueller wrote: |
| 5 |
>>>>>>>> On Wed, 10 Apr 2019, Ulrich Mueller wrote: |
| 6 |
>>> |
| 7 |
>>>>>>>> On Tue, 09 Apr 2019, Gokturk Yuksek wrote: |
| 8 |
>>> |
| 9 |
>>>> I'd like to (informally) propose the following, for which I'm willing |
| 10 |
>>>> to formulate as a GLEP proposal if there is interest: |
| 11 |
>>> |
| 12 |
>>>> The Foundation has an established practice of storing the legal names |
| 13 |
>>>> of developers who join under a pseudonym. The infrastructure is |
| 14 |
>>>> already in place for this. I think that allowing these developers to |
| 15 |
>>>> commit using their pseudonyms as long as the Foundation is informed |
| 16 |
>>>> their real identity does not exacerbate the legal risks they already |
| 17 |
>>>> pose. The foundation may decide their arbitrary criteria on who is |
| 18 |
>>>> eligible for this type of protection, including requiring sound legal |
| 19 |
>>>> reasons for them to keep their identities hidden. I understand that |
| 20 |
>>>> the maintenance of this could be a burden for the Foundation in |
| 21 |
>>>> theory, but in practice I suspect this number is very low already. |
| 22 |
>>> |
| 23 |
>>> That doesn't work, because there would be no way for a person outside of |
| 24 |
>>> the Foundation to verify such identities. |
| 25 |
>>> |
| 26 |
>> There is no way also for foundation to check all sign-off are assigned |
| 27 |
>> to real legal names. |
| 28 |
>> |
| 29 |
> |
| 30 |
> So these are two separate points. I don't quite understand Ulm's point but |
| 31 |
> it is different than the point you are raising. |
| 32 |
> |
| 33 |
> Your point seems to be that somehow the "Foundation must be able to check |
| 34 |
> if all sign-offs are signed by a legal name." We already made it clear we |
| 35 |
> don't do this checking. That doesn't mean its OK to use an pseudonym (it is |
| 36 |
> not, and doing so violates the policy.) If we later find out people violate |
| 37 |
> the policy, we don't accept commits from them anymore. You can call the |
| 38 |
> system crappy or whatever, but its the system we have in place. today. |
| 39 |
> |
| 40 |
> Ulm's point seems to be about transparency: "there would be no way for a |
| 41 |
> person outside of the Foundation to verify such identities." I'm not sure |
| 42 |
> the entire usefulness of such a use case (do people care about being able |
| 43 |
> to do this?) |
| 44 |
> |
| 45 |
> Putting the above points aside for a moment the Foundation has had a policy |
| 46 |
> of shielding specific contributors from having their identity made public. |
| 47 |
> I can't say with a straight face that "the infrastructure is already in |
| 48 |
> place for this" (it really isn't) nor can I say that the Foundation has any |
| 49 |
> written policies about how to safeguard, share, divulge, or otherwise use |
| 50 |
> this information and instead it has ridden on the spoken words of various |
| 51 |
> Foundation officials in the past. Its not something I'd want to build upon. |
| 52 |
> |
| 53 |
> |
| 54 |
>>> To clarify, I won't be opposed against making a specific exception and |
| 55 |
>>> "grandfathering" any devs who had commit access before the cut-off date |
| 56 |
>>> when GLEP 76 was implemented. |
| 57 |
>>> |
| 58 |
>> |
| 59 |
>> I propose foundation to vote for add the use of pseudonym in the GLEP 76. |
| 60 |
>> For keeping Gentoo a confortable and inclusive place. |
| 61 |
>> |
| 62 |
>>> However, going forward, we shouldn't allow any further exceptions from |
| 63 |
>>> the real name policy. |
| 64 |
>>> |
| 65 |
>> |
| 66 |
> |
| 67 |
> I'm not especially keen on grandfathering people into the project in this |
| 68 |
> way because I think it defers the problem. Pseudonymous contributors want |
| 69 |
> to contribute but cannot. Letting in people who happened to be contributors |
| 70 |
> before glep 76 doesn't solve this problem, it just defers it in the hopes |
| 71 |
> that new contributors who fall into this bucket get dissuaded before they |
| 72 |
> push for changes. |
| 73 |
> |
| 74 |
> |
| 75 |
|
| 76 |
I see the concern of setting a precedent here. I also support more |
| 77 |
transparency, and am not advocating that we include more anonymous |
| 78 |
developers. I'd like to make a few clarifications: |
| 79 |
|
| 80 |
- I believe the necessity for a pseudonym must be justified to the |
| 81 |
Foundation. Therefore, I'm not suggesting that people should remain |
| 82 |
anonymous for arbitrary reasons. I am also **not** suggesting that we |
| 83 |
get rid of the DCO. |
| 84 |
|
| 85 |
- Grandfathering the existing devs does not set a precedent for future |
| 86 |
devs who'd like to join under a pseudonym. The situation is more complex |
| 87 |
than that: since users are not allowed to contribute under a pseudonym, |
| 88 |
they'd have to disclose their legal name even before they become a |
| 89 |
developer. In the rare case that a user with no contributions somehow |
| 90 |
finds a mentor and applies to become a dev, the recruitment process |
| 91 |
requires the candidate to submit a fix to an existing bug (unless this |
| 92 |
process has changed). The fix would naturally require them to disclose |
| 93 |
their real name, and would defeat the purpose of joining under a |
| 94 |
pseudonym. I hope this addresses the concern about setting a precedent. |
| 95 |
|
| 96 |
- I'm only advocating for repurposing an already existing system (that |
| 97 |
is the pseudonym mechanism offered by the Foundation) to bring back |
| 98 |
developers who have been impacted by GLEP 76, so long as they have valid |
| 99 |
reasons (based on what the Foundation deems "valid") to maintain their |
| 100 |
pseudonymity. As such, I expect the extra maintenance burden on the |
| 101 |
Foundation to be minimal and I'm willing to work out the details (such |
| 102 |
as what k_f brought up before). |
| 103 |
|
| 104 |
-- |
| 105 |
gokturk |
Archives