Re: [gentoo-project] call for agenda items -- council meeting 2019-04-14

[Michael Everitt <m.j.everitt@iee.org>]

[-- Attachment #1.1: Type: text/plain, Size: 8291 bytes --]

On 03/04/19 19:12, Andrew Savchenko wrote:
> On Wed, 3 Apr 2019 17:43:15 +0300 Andrew Savchenko wrote:
>> On Wed, 3 Apr 2019 10:04:36 -0400 NP-Hardass wrote:
>>> On 4/3/19 8:43 AM, Alec Warner wrote:
>>>>
>>>> On Wed, Apr 3, 2019 at 7:31 AM NP-Hardass <NP-Hardass@gentoo.org
>>>> <mailto:NP-Hardass@gentoo.org>> wrote:
>>>>
>>>>     On 3/31/19 11:20 PM, William Hubbs wrote:
>>>>     > Hi all,
>>>>     >
>>>>     > two weeks from today (2019-04-14) the Gentoo Council will meet at
>>>>     > 19:00 UTC in the #gentoo-council channel on freenode.
>>>>     >
>>>>     > Please reply to this message with any items you would like us to
>>>>     put on
>>>>     > the agenda to discuss or vote on.
>>>>     >
>>>>     > Thanks much,
>>>>     >
>>>>     > William
>>>>     >
>>>>
>>>>     I'd like the council to discuss the issue and general trend of actions
>>>>     (particularly recent) to restrict the ability of developers to
>>>>     contribute to Gentoo.  In my view, efforts are being made to make
>>>>     contributions as users substantially easier, while efforts are being
>>>>     made to make being a developer substantially harder.  The months of
>>>>     studying, quiz taking, and interviews set a bar that should make
>>>>     contributions from those individuals that become developers easier than
>>>>     the average user, not more difficult.
>>>>
>>>>
>>>> This is a pretty vague statement, are there particular things you want
>>>> the council to review; or just the 'general trend'?
>>>> I'm not aware of any recent changes to the developer onboarding process.
>>>>
>>>> -A
>>>>  
>>>>
>>>>
>>>>     -- 
>>>>     NP-Hardass
>>>>
>>> Not just the onboarding, but the retention too.  General trend is what
>>> I'm proposing should be discussed publicly during the meeting.
>>>
>>> Three points:
>>>
>>> At present time, everyone needs a "Real Name" to contribute.  A user,
>>> with a new email address, can allege to be "Foo Bar" and contribute
>>> without impediment, but, as recent proposals would have it, developers
>>> would need to show proof of ID over video call to become part of the web
>>> of trust for committing.  That effectively allows any user to remain
>>> anonymous by using a false name, obviating a huge portion of the alleged
>>> benefit to requiring names in the first place. So, developers can be
>>> held to such a high standard that they can either no longer contribute,
>>> while we trim eligible pool of new developers and compare that to the
>>> ease with which any "named" contributor on github or bugzilla can do as
>>> they please.
>>>
>>> We currently have a RFC, just posted two days ago, for developers to be
>>> regularly tested to maintain commit status.  Again, if the developer
>>> feels like it, maybe it is easier for him/her to just become a plain old
>>> user and submit patches, waiting on the (as I see it, dwindling,) amount
>>> of active other developers ready to commit instead.
>> That RFC was issued on 1st April, so I assume it to be an ill joke.
>>
>>> Totally anecdotal, I've seen developers that have fairly decent QA on
>>> their own commits merge PRs from users without full review and
>>> introducing a whole host of issues because code from users isn't always
>>> vetted as thoroughly as ones own work.  So, I'd argue, the QA standards
>>> of being a dev don't quite apply to you as stringently once you
>>> downgrade to being a user...
>>>
>>> At the end of the day, holding developers to higher standards than users
>>> is a given, but it shouldn't be more onerous to be a developer than to
>>> be a user contributing.
>> As you already noted, users also have to sign-off contributions with
>> their real names, though we have no way to verify those names, as
>> well as for developers actually.
>>
>> Will all due respect GLEP76 was prepared by people without much
>> legal expertise and creates more problems than solves. The part of
>> GLEP76 mandating real name signatures *must* be amended.
>>
>> Why? We have no way to verify that provided names are valid or that
>> provided ID's are valid. At least in my jurisdiction such
>> information collected can't be used for legal action or protection
>> without following established government-assisted verification
>> procedure. In other jurisdictions similar problems may and will
>> arise. Additional problem is personal data collection, it is
>> restricted or heavily regulated in many countries. One can't just
>> demand to show an ID via electronic means without following
>> complicated data protection procedures which are likely to be
>> incompatible between jurisdictions.
>>
>> So the real name requirement gives us no real protection from
>> possible cases, but creates real and serious problems by kicking
>> active developers and contributors from further contributions.
>> NP-Hardass is not the only one. I invited some gifted people with
>> high quality out-of-tree work to become contributors or developers,
>> but due to hostile attitude towards anonymous contributors they
>> can't join. And people want to stay anonymous for good reasons,
>> because they are engaged with privacy oriented development.
>>
>> We are loosing real people, real contributions and real community.
>> What for? For solving imaginary problems with inappropriate tools.
> Since the Council usually makes decisions on some specific proposals
> and not on vague ideas, here is my proposal on this subject: keep real
> name as a recommendation, not as a requirement. See a draft patch to
> GLEP 76 below. It is not intended to be a final wording, but it
> shows the idea.
>
> diff --git a/glep-0076.rst b/glep-0076.rst
> index 9d5aa79..b16fae7 100644
> --- a/glep-0076.rst
> +++ b/glep-0076.rst
> @@ -137,8 +137,9 @@ the Certificate of Origin by adding ::
>      Signed-off-by: Name <e-mail>
>  
>  to the commit message as a separate line.  The sign-off must contain
> -the committer's legal name as a natural person, i.e., the name that
> -would appear in a government issued document.
> +either the committer's legal name as a natural person, i.e., the name
> +that would appear in a government issued document or the pseudonym.
> +Usage of the legal name is recommended.
>  
>  The following is the current Gentoo Certificate of Origin, revision 1:
>  
> @@ -242,10 +243,9 @@ to protect the Gentoo infrastructure owners and improve consistency.
>  
>  The copyright model is built on the DCO model used by the Linux kernel
>  and requires all contributors to certify the legitimacy of their
> -contributions.  This also requires that they use their real name for
> -signing; an anonymous certification or one under a pseudonym would not
> -mean anything.  This policy is derived from the Linux project's policy
> -[#SUBMITTING-PATCHES]_.
> +contributions. This also requires that they use their real name
> +(recommended) or a pseudonym for signing. This policy is derived from the
> +Linux project's policy [#SUBMITTING-PATCHES]_.
>  
>  In the future, a second stage of this policy may use a combination of
>  the DCO model and an FLA model [#FLA]_ as it is used by different open
>
>
> Best regards,
> Andrew Savchenko
I would also note, that I know several people using pseudonyms whose real
identity I don't, and have no wish to, know; who have documents verifying
their right to use said pseudonym as their legal identity. Therefore if you
were insistent on pursuing copyright claims, you could equally use said
identity to carry out such procedures. In reality, I don't see Gentoo
pursuing any legal cases, nor having to address any copyright claims, as I
have certainly seen no requests to either the Council as governing body NOR
trustees as the legal entity representing Gentoo Linux.

IANAL, but I certainly agree with the synopsis that the council is somewhat
obsessed with "... solving imaginary problems with inappropriate tools".

Let's see some Real World examples of situations that have caused the
council a problem (no I don't want a whole bunch more straw men made), and
I invite the trustees to present real world cases of enquiries they have
received relating to such issues.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]