[Python-Dev] Re: Merging PRs without CLA signed

[Brett Cannon]

My personal stance is if Microsoft Word could have come up with the change then 
a signed CLA is _probably_ not needed (IOW typos and grammatical errors).

But honestly, I fall into the same camp as Mariatta and Pablo out of laziness 
and fear of being wrong. :) Laziness because there are plenty of other people 
willing to sign the CLA and participate fully that I would rather help out with 
my limited open source time. Out of fear because I don't want to get this wrong 
and be the reason the PSF gets sued some day.

Personally, I hope we move to CLA Assistant (or improve the-knights-who-say-ni 
to be as usable) and then make CLA signing a required status check on PRs to 
negate having to think about this.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QQYQSI3X26IK23MJPEQJKYNLTVZSVHP3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merging PRs without CLA signed

[Kyle Stanley]

> I remember seeing it too.  It may have originally been in the tracker
> instructions, but should definitely be in the devguide now.

>From looking through the devguide for every instance of "CLA" and
"trivial", there seems to be just one section that mentions anything
regarding the triviality of the patch in relation to the CLA:

"If the submitter lacks a signed CLA and the patch is non-trivial, direct
them to the electronic Contributor Licensing Agreement
 to ensure the PSF has
the appropriate authorizations in place to relicense and redistribute their
code."

(https://devguide.python.org/committing/#handling-others-code)

Since the licensing section of the pullrequest page is linked to from the
index of the devguide, as being the main reference for first-time
contributors signing the CLA, I think we could benefit from mentioning it
there as well:

"To accept your change we must have your formal approval for distributing
your work under the PSF license
.
Therefore, you need to sign a contributor agreement
 which allows the Python Software
Foundation  to license your code for use with
Python (you retain the copyright)."

(https://devguide.python.org/pullrequest/#cla)

This could involve a very minimal change to the first sentence, which would
help both sections to better convey the same policy [1]:

"To accept any non-trivial change we must have..."
Would that be reasonable? It wouldn't change the existing policy (since
it's mentioned on the committing page), but I think it would make it more
visibly clear that the CLA isn't a hard requirement for trivial PRs. This
would likely just reinforce the current state of affairs, where it's
ultimately at the discretion of the core dev(s) reviewing the patch [2];
while hopefully clearing up misconceptions.

I think it would also be useful to briefly describe guidelines on the
committing page that help to define what may constitute as trivial vs
non-trivial, along the lines of how Terry described the distinction. I
personally found the comparison of minor fact correction vs creative
expression to be particularly helpful. But, a section like that would
likely require some oversight from the PSF legal staff.

---

[1] - From my interpretation at least, "To accept your change we must have
..." and "If the submitter lacks a signed CLA and the patch is non-trivial
..." seem to be mildly in conflict of one another regarding the CLA policy.

[2] - Discretion to determine triviality based on best judgement, and
whether or not they personally consider merging any PRs without the CLA
signed.

On Mon, Feb 24, 2020 at 1:54 PM Terry Reedy  wrote:

> On 2/23/2020 11:44 PM, Guido van Rossum wrote:
> > On Sun, Feb 23, 2020 at 8:11 PM Kyle Stanley  > > wrote:
> >
> > In a recently opened typo fixing PR [1], an issue came up regarding
> > the lack of a signed CLA, where the author specifically mentioned
> > they did not want to sign it for privacy concerns.
> >
> >
> > In that case I'm not sure the author ought to get credit for the PR.
>
> If the account has a real name, then there cannot be a privacy concern.
> If if does not, then credit can only be claimed privately.
>
> > They can file a bug pointing out the typo and someone else can submit a
> > fix.
>
> One of that justifications given for moving to github was that is would
> allow trivial changes to be submitted without an issue.  Allowing merges
> for trivial changes without a CLA was intentional, after discussion.
>
> To summarize my response a few minutes ago to Antoine and Chris
> Angelico, I consider trivial to mean non-copyrightable because short and
> fact based.
>
> > (This is what Glyph had to do for all his contributions while he
> > was employed at Apple.)
>
> And what anyone in a similar situation should still do for anything
> non-trivial.
> > Yeah, typically we don't insist on a CLA for trivial fixes -- it's at
> > the discretion of the core dev reviewing/merging the PR. I actually
> > thought this was a policy that was written down somewhere, but I don't
> > know where (maybe somewhere in the devguide?).
>
> I remember seeing it too.  It may have originally been in the tracker
> instructions, but should definitely be in the devguide now.
>
>
>
>
> --
> Terry Jan Reedy
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/UARCSQSBLTU2YHOM4QDTGNYXXDWVM26W/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- 

[Python-Dev] Re: Merging PRs without CLA signed

[Mariatta]

don't remember if there's a magic comment that contributors can
leave to get the bot to check again on its own, but the usual trigger
for this is the submitter posting to say they've signed it, a core dev
or triager seeing that and removing the "CLA Not Signed" label,



There is no magic comment, and to reduce work from core dev/triager,
contributors can use this to update their own PRs
https://check-python-cla.herokuapp.com/

Being able to update the CLA as soon as it gets signed instead of waiting a
couple days, is on top of my wishlist:

https://github.com/python/core-workflow/issues/360
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FUUEN6OBXNYJ4K3ENXKAQNLXX5ENAFBF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merging PRs without CLA signed

[Nick Coghlan]

On Mon, 24 Feb 2020 at 14:51, Kyle Stanley  wrote:
>
> > Note that if you open a PR, and _then_ sign the CLA, the label is not 
> > updated (at least, that's what I experienced before I did). So this list is 
> > likely inaccurate.
>
> I believe that I might have seen this happen a few times, but in the majority 
> cases the label is updated from "CLA not signed" => "CLA signed". There's a 
> bit of delay (~24-48 hours) from the time you sign the CLA to when it's 
> updated in the heroku app, so if the PR gets merged during that time the 
> label might not ever update.
>
> For my own first PR, it was initially not signed when I opened it, and then 
> the label updated to signed within a couple days after signing the CLA. This 
> has also been the case in the majority of PRs I've reviewed from first-time 
> contributors.

I don't remember if there's a magic comment that contributors can
leave to get the bot to check again on its own, but the usual trigger
for this is the submitter posting to say they've signed it, a core dev
or triager seeing that and removing the "CLA Not Signed" label, and
then the bot adding the "CLA signed" label (confirming that the CLA
has, in fact, been signed, and the PSF records have been updated
accordingly).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/22ZP56KOHIPRPSD5H72KIGTEEAY5DNVZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merging PRs without CLA signed

[Mariatta]

FWIW, I'm also one of the few core devs who won't merge a PR unless CLA is
signed.
Such PRs (and the backports) can't be automerged, creating manual work.

I find the "triviality" is subjective. One line change in documentation is
maybe trivial. One line change in the code is probably not as trivial.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ORBVOSW64EMTGHMD5IBEBN5AITLCVBM5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merging PRs without CLA signed

[Terry Reedy]

On 2/23/2020 11:44 PM, Guido van Rossum wrote:
On Sun, Feb 23, 2020 at 8:11 PM Kyle Stanley > wrote:


In a recently opened typo fixing PR [1], an issue came up regarding
the lack of a signed CLA, where the author specifically mentioned
they did not want to sign it for privacy concerns.


In that case I'm not sure the author ought to get credit for the PR. 


If the account has a real name, then there cannot be a privacy concern. 
If if does not, then credit can only be claimed privately.


They can file a bug pointing out the typo and someone else can submit a 
fix.


One of that justifications given for moving to github was that is would 
allow trivial changes to be submitted without an issue.  Allowing merges 
for trivial changes without a CLA was intentional, after discussion.


To summarize my response a few minutes ago to Antoine and Chris 
Angelico, I consider trivial to mean non-copyrightable because short and 
fact based.


(This is what Glyph had to do for all his contributions while he 
was employed at Apple.)


And what anyone in a similar situation should still do for anything 
non-trivial.
Yeah, typically we don't insist on a CLA for trivial fixes -- it's at 
the discretion of the core dev reviewing/merging the PR. I actually 
thought this was a policy that was written down somewhere, but I don't 
know where (maybe somewhere in the devguide?).


I remember seeing it too.  It may have originally been in the tracker 
instructions, but should definitely be in the devguide now.





--
Terry Jan Reedy
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UARCSQSBLTU2YHOM4QDTGNYXXDWVM26W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merging PRs without CLA signed

[Terry Reedy]

On 2/24/2020 10:32 AM, Chris Angelico wrote:

On Tue, Feb 25, 2020 at 2:25 AM Antoine Pitrou  wrote:



I'd like to point out that the relevant perspective here isn't PSF
policy as much as copyright law.


Since Python is copyrighted in the US and the license specifies Virginia 
as the state of jurisdiction, I presume we can reference US law and 
precedents.



 Something as trivial as a typo fix
for sure isn't copyrightable, so there's no point in requiring a CLA
for it.  


Copyright serves to protect 'creative expression'.  Facts are not 
creative expression.  (But they can be creatively expressed.)  A typo 
fix changes a 'creative spelling' to a standard spelling, found in 
dictionaries, that is nearly always unique and never, that I know of, 
has more than two choices.  They can be made by programs, and multiple 
fixes in one PR are the result of such programs.


Grammar fixes are similar in standardizing 'creative writing'.  Link 
fixes usually update changed facts.



For more involved changes, things are less clear, and a court
would be the final authority; but that's admittedly an argument for
erring on the side of caution and requiring a CLA for *any* non-trivial
change.


I agree.  If a change is subject to discussion and disagreement beyond a 
choice of facts, best to have a CLA.



I don't think anyone disputes that the CLA is needed for any
non-trivial change. The question is, what constitutes a non-trivial
change?  > Is it subjective? What's the smallest copyrightable edit
(which may or may not be related to the smallest copyrightable piece
of text)?


US courts have wrestled with this as people have tried to claim 
copyright on short bits of language, music, or movement.  I am pretty 
sure that two words, notes, or positions (and the transitions between) 
are generally considered too short.  (Which is why game emotes can 
legally copy 'signature' dance moves that consist of 'start pose 
transition to end pose'.)



Does it depend on context - is fixing a link more trivial
than fixing a piece of English?


Depends on the length of the 'piece'.  See discussion of data above.


It'd be great to get a lawyer's firm stance on this. On the PEPs repo,
I've merged a good few simple PRs, and don't want to be putting the
PSF into legal trouble.


Sentences are usually creative, not merely trivial.


--
Terry Jan Reedy
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QBIHIMGBOGIWJ443GINA24GH5V4O4YIL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merging PRs without CLA signed

[Ivan Pozdeev via Python-Dev]

On 24.02.2020 8:30, Kyle Stanley wrote:
> (What is it with typos anyway? Why do people feel the need to invoke megabytes if not gigabytes of internet traffic to correct a word 
that every reader can easily correct in their mind?)


Speaking from personal experience to some degree, my first PR was an incredibly minimal documentation enhancement: 
https://github.com/python/cpython/pull/14069. It's not exactly a typo fix, but in retrospect, I'd consider it to be about equally 
impactful. I can't speak for everyone, but my own motivation was to do something very mildly helpful just to get a feel for the workflow. 
It eventually led to increasingly involved contributions. (:


I think some people might also consider grammatical corrections to be helpful for bolstering the "professionalism" of the documentation a 
bit, but it's hard to say for sure.


I can affirm that. Nothing says "amateurish" and "neglectful" like glaring grammatical errors. It shows that the author doesn't care about 
their users' convenience and likes to waste their time (the text _can_ be read but it's significantly _harder_ to read and otherwise use), 
and that other aspects of the work are likely similarly chaotic.


It's not even uncommon when they make the meaning unclear. Or e.g. typos or inconsistency in a term make it hard to locate other references 
to it or deduce if the phrase is being used as a term or as a common phrase.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DDKRNSHJFQUDB5OU2D5KMARMRLQRXXX5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merging PRs without CLA signed

[David Mertz]

There is, for better or worse, no bright line about what is copyrightable.
Unfortunately, a lot of the standard is "how deep are the pockets of the
opposing party?"

If you are Oracle and you want to sue Google, code which any normal person
world consider trivial becomes precious intellectual property. Likewise, if
you are Microsoft and you can find a proxy in SCO to sabotage Linux.

If I, as a self-employed freelancer, contribute a couple lines to Python
without a CLA, I'm not going to sue anyone. But if I accept a job with some
huge tech company and sign standard employee agreements, they might, even
against my wishes.

On Mon, Feb 24, 2020, 10:39 AM Chris Angelico  wrote:

> On Tue, Feb 25, 2020 at 2:25 AM Antoine Pitrou 
> wrote:
> >
> > On Mon, 24 Feb 2020 00:30:41 -0500
> > Kyle Stanley  wrote:
> > > > In that case I'm not sure the author ought to get credit for the PR.
> They
> > > can file a bug pointing out the typo and someone else can submit a fix.
> > >
> > > That sounds like a reasonable solution to me; even for more substantial
> > > issues (if signing the CLA is a genuine issue). I think there are a
> fair
> > > number of individuals out there who just want to fix something and
> aren't
> > > concerned with attributions or long-term contributions; they just want
> to
> > > fix the issue for themselves or perhaps for altruistic reasons.
> >
> > I'd like to point out that the relevant perspective here isn't PSF
> > policy as much as copyright law.  Something as trivial as a typo fix
> > for sure isn't copyrightable, so there's no point in requiring a CLA
> > for it.  For more involved changes, things are less clear, and a court
> > would be the final authority; but that's admittedly an argument for
> > erring on the side of caution and requiring a CLA for *any* non-trivial
> > change.
> >
>
> I don't think anyone disputes that the CLA is needed for any
> non-trivial change. The question is, what constitutes a non-trivial
> change? Is it subjective? What's the smallest copyrightable edit
> (which may or may not be related to the smallest copyrightable piece
> of text)? Does it depend on context - is fixing a link more trivial
> than fixing a piece of English?
>
> It'd be great to get a lawyer's firm stance on this. On the PEPs repo,
> I've merged a good few simple PRs, and don't want to be putting the
> PSF into legal trouble.
>
> ChrisA
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/KNX3ZIQKABBNH6LXEWZ765UKVDR7C3CT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NPH3SVMFISKVHVEFZEE5HL26SNVOKS4T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merging PRs without CLA signed

[Chris Angelico]

On Tue, Feb 25, 2020 at 2:25 AM Antoine Pitrou  wrote:
>
> On Mon, 24 Feb 2020 00:30:41 -0500
> Kyle Stanley  wrote:
> > > In that case I'm not sure the author ought to get credit for the PR. They
> > can file a bug pointing out the typo and someone else can submit a fix.
> >
> > That sounds like a reasonable solution to me; even for more substantial
> > issues (if signing the CLA is a genuine issue). I think there are a fair
> > number of individuals out there who just want to fix something and aren't
> > concerned with attributions or long-term contributions; they just want to
> > fix the issue for themselves or perhaps for altruistic reasons.
>
> I'd like to point out that the relevant perspective here isn't PSF
> policy as much as copyright law.  Something as trivial as a typo fix
> for sure isn't copyrightable, so there's no point in requiring a CLA
> for it.  For more involved changes, things are less clear, and a court
> would be the final authority; but that's admittedly an argument for
> erring on the side of caution and requiring a CLA for *any* non-trivial
> change.
>

I don't think anyone disputes that the CLA is needed for any
non-trivial change. The question is, what constitutes a non-trivial
change? Is it subjective? What's the smallest copyrightable edit
(which may or may not be related to the smallest copyrightable piece
of text)? Does it depend on context - is fixing a link more trivial
than fixing a piece of English?

It'd be great to get a lawyer's firm stance on this. On the PEPs repo,
I've merged a good few simple PRs, and don't want to be putting the
PSF into legal trouble.

ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KNX3ZIQKABBNH6LXEWZ765UKVDR7C3CT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merging PRs without CLA signed

[Antoine Pitrou]

On Mon, 24 Feb 2020 00:30:41 -0500
Kyle Stanley  wrote:
> > In that case I'm not sure the author ought to get credit for the PR. They  
> can file a bug pointing out the typo and someone else can submit a fix.
> 
> That sounds like a reasonable solution to me; even for more substantial
> issues (if signing the CLA is a genuine issue). I think there are a fair
> number of individuals out there who just want to fix something and aren't
> concerned with attributions or long-term contributions; they just want to
> fix the issue for themselves or perhaps for altruistic reasons.

I'd like to point out that the relevant perspective here isn't PSF
policy as much as copyright law.  Something as trivial as a typo fix
for sure isn't copyrightable, so there's no point in requiring a CLA
for it.  For more involved changes, things are less clear, and a court
would be the final authority; but that's admittedly an argument for
erring on the side of caution and requiring a CLA for *any* non-trivial
change.

Regards

Antoine.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OVZPP3TAPZYZMKBPKPCG4ETVNMGEMRAJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merging PRs without CLA signed

[Ethan Furman]

On 02/23/2020 08:44 PM, Guido van Rossum wrote:


(What is it with typos anyway? Why do people feel the need to invoke megabytes 
if not gigabytes of internet traffic to correct a word that every reader can 
easily correct in their mind?)


Typos are like skate boarding on fresh asphalt and then hitting a pebble.  Not 
fun.  ;-)

--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/M7TPAILCOWUILSG3L53L6FQM2YK3V3NH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merging PRs without CLA signed

[Kyle Stanley]

> In that case I'm not sure the author ought to get credit for the PR. They
can file a bug pointing out the typo and someone else can submit a fix.

That sounds like a reasonable solution to me; even for more substantial
issues (if signing the CLA is a genuine issue). I think there are a fair
number of individuals out there who just want to fix something and aren't
concerned with attributions or long-term contributions; they just want to
fix the issue for themselves or perhaps for altruistic reasons.

> In the past the people who refused to sign the CLA just had some beef
with the legal system -- that's fine, it's their choice, but we just cannot
accept their contributions: that's our choice.

Yeah, I think that's fair.

> (What is it with typos anyway? Why do people feel the need to invoke
megabytes if not gigabytes of internet traffic to correct a word that every
reader can easily correct in their mind?)

Speaking from personal experience to some degree, my first PR was an
incredibly minimal documentation enhancement:
https://github.com/python/cpython/pull/14069. It's not exactly a typo fix,
but in retrospect, I'd consider it to be about equally impactful. I can't
speak for everyone, but my own motivation was to do something very mildly
helpful just to get a feel for the workflow. It eventually led to
increasingly involved contributions. (:

I think some people might also consider grammatical corrections to be
helpful for bolstering the "professionalism" of the documentation a bit,
but it's hard to say for sure.

> Honestly it seems a rather trivial matter to be so concerned about
fairness. Hopefully a contributor isn't really going to claim "Python Core
Contributor" on their resume based on a typo fix they contributed, and if
they do, I'm not sure whether the CLA requirement is really the key issue
of fairness...

Haha, I had honestly not considered that perspective. But yeah, hopefully
in that case the potential employer would look into the actual contribution
or ask them to link their GitHub, rather than just taking it at face
value...

My concern was mostly just that it might turn some first-contributors away
if they open their first minimal PR, are required to sign the CLA, and then
see that others for similar (or even more involved) PRs didn't have to sign
it. It also has came up enough times that I'd like to have a clear answer
to provide. Perhaps "fairness" could be overstating the issue though.

I was also wondering if there might be any licensing issues for having a
decent volume of total contributions to CPython from individuals without a
CLA signed (even if they're minimal by themselves), but that's likely a
question for the PSF legal team rather than python-dev.

> Write down explicitly that for truly trivial PRs it's at the discretion
of the reviewer?

IMO, that would still be an improvement, because at least then everyone
would have a definitive policy to refer to, even if that policy is "it's up
to the core dev reviewing the PR". I would very much like to know whether
signing the CLA for all PRs is intended to be a concrete policy or if it's
at the discretion of those reviewing the PR. Over the course of my PR
reviews, I've seen quite a number of mixed answers. It's not an absurdly
common issue that is asked on every other PR, but I think it comes up
enough to justify having a more clearly defined policy of some form.

> I believe I've heard that the FSF has a similar policy that states a
maximum number of lines or characters for PRs to be considered possibly
trivial -- but since it's sometimes possible to contribute a truly amazing
speedup that's only a few characters in size, it really ought to be up to
the core dev. Or maybe it should be limited to at most a handful of typo,
grammar or punctuation fixes in docs or comments. (And no splitting it up
into a multiple PRs to duck the limit.)

Both of those also sounds reasonable, and would be aligned with the
existing similar PRs that have been merged without a signed CLA (as far as
I can tell). As mentioned in the OP, I don't have an especially strong
opinion on how it should be handled. More than anything, I'd just like the
policy to be made clear for future PRs so that I can provide an accurate
answer to newer contributors.

On Sun, Feb 23, 2020 at 11:44 PM Guido van Rossum  wrote:

> On Sun, Feb 23, 2020 at 8:11 PM Kyle Stanley  wrote:
>
>> In a recently opened typo fixing PR [1], an issue came up regarding the
>> lack of a signed CLA, where the author specifically mentioned they did not
>> want to sign it for privacy concerns.
>>
>
> In that case I'm not sure the author ought to get credit for the PR. They
> can file a bug pointing out the typo and someone else can submit a fix.
> (This is what Glyph had to do for all his contributions while he was
> employed at Apple.)
>
> While it's *possible* that there are authors there who worry about
> prosecution and don't want their private data exposed to the PSF's database
> of Python 

[Python-Dev] Re: Merging PRs without CLA signed

[Kyle Stanley]

> Note that if you open a PR, and _then_ sign the CLA, the label is not
updated (at least, that's what I experienced before I did). So this list is
likely inaccurate.

I believe that I might have seen this happen a few times, but in the
majority cases the label is updated from "CLA not signed" => "CLA signed".
There's a bit of delay (~24-48 hours) from the time you sign the CLA to
when it's updated in the heroku app, so if the PR gets merged during that
time the label might not ever update.

For my own first PR, it was initially not signed when I opened it, and then
the label updated to signed within a couple days after signing the CLA.
This has also been the case in the majority of PRs I've reviewed from
first-time contributors.

On Sun, Feb 23, 2020 at 11:24 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

>
> On 24.02.2020 7:07, Kyle Stanley wrote:
> >
> > For a full list of merged PRs to CPython with a "CLA not signed" label,
> see the following:
> >
> https://github.com/python/cpython/pulls?utf8=%E2%9C%93=is%3Apr+state%3Amerged+label%3A%22CLA+not+signed%22
> >
> Note that if you open a PR, and _then_ sign the CLA, the label is not
> updated (at least, that's what I experienced before I did). So this
> list is likely inaccurate.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/IO66YO2SVW55M5KXCAM2P4J7DVMSCK5X/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/F22BOEMMBFZJMVKGVR7YDTR5ZXJKIXAY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merging PRs without CLA signed

[Guido van Rossum]

On Sun, Feb 23, 2020 at 8:11 PM Kyle Stanley  wrote:

> In a recently opened typo fixing PR [1], an issue came up regarding the
> lack of a signed CLA, where the author specifically mentioned they did not
> want to sign it for privacy concerns.
>

In that case I'm not sure the author ought to get credit for the PR. They
can file a bug pointing out the typo and someone else can submit a fix.
(This is what Glyph had to do for all his contributions while he was
employed at Apple.)

While it's *possible* that there are authors there who worry about
prosecution and don't want their private data exposed to the PSF's database
of Python contributors, I doubt that that's the situation here. Such people
usually have more important things to do than point out typos. In the past
the people who refused to sign the CLA just had some beef with the legal
system -- that's fine, it's their choice, but we just cannot accept their
contributions: that's our choice.

(What is it with typos anyway? Why do people feel the need to invoke
megabytes if not gigabytes of internet traffic to correct a word that every
reader can easily correct in their mind?)


> In the past, I've seen several PRs with similarly minimal [2] changes
> (such as typo fixes, grammar fixes, link fixes, etc) merged without having
> the CLA signed, so it was my assumption that this was acceptable. For a
> full list of merged PRs to CPython with a "CLA not signed" label, see the
> following:
> https://github.com/python/cpython/pulls?utf8=%E2%9C%93=is%3Apr+state%3Amerged+label%3A%22CLA+not+signed%22
>

Yeah, typically we don't insist on a CLA for trivial fixes -- it's at the
discretion of the core dev reviewing/merging the PR. I actually thought
this was a policy that was written down somewhere, but I don't know where
(maybe somewhere in the devguide?).


> However, I was informed by Pablo Galindo that there are legal issues
> involved with merging *any* PRs without the CLA signed, including typo
> fixes. Personally, I have no strong opinion one way or the other, as I
> don't have an adequate understanding from a legal/licensing perspective.
> But, I think think there's definitely an issue with the lack of consistency
> regarding this policy.
>

I haven't encountered this strong position before. Maybe it's something
Pablo learned from his employer's lawyers? Perhaps more applicable in a
different context?


> *To require a signed CLA for some minimal PRs but not others, solely based
> on who happens to be reviewing the PR, seems rather unfair to potential
> contributors.* From my perspective, the solution seems to be clearly
> defining a more explicit stance on this policy, and having it apply as
> universally as possible to *all* PRs made to CPython.
>

Honestly it seems a rather trivial matter to be so concerned about
fairness. Hopefully a contributor isn't really going to claim "Python Core
Contributor" on their resume based on a typo fix they contributed, and if
they do, I'm not sure whether the CLA requirement is really the key issue
of fairness...


> For example, if the CLA should be required for all PRs, the policy might
> state something like this: "The author of any PR made to the CPython
> repository must have signed the CLA before their PR can be merged. Any PR
> opened by an author that has not signed the CLA can't be merged until it
> has been signed."
>
> OTOH, if it's okay for minimal PRs to not have a signed CLA: "The author
> of any PR made to the CPython repository must have signed the CLA before
> their PR can be merged, except for minimal PRs. Some examples of minimal
> PRs include: ..."
>
> Currently, the policy seems to be learning more towards the former based
> on the devguide [3], where it states "To accept your change we must have
> your formal approval for distributing your work under the PSF license.
> Therefore, you need to sign a contributor agreement which allows the Python
> Software Foundation to license your code for use with Python (you retain
> the copyright)".
>
> However, it seems apparent to me that either this policy isn't explicit
> enough, has a lack of visibility, or simply isn't followed consistently.
> What might be a viable solution to this problem?
>

Write down explicitly that for truly trivial PRs it's at the discretion of
the reviewer? I believe I've heard that the FSF has a similar policy that
states a maximum number of lines or characters for PRs to be considered
possibly trivial -- but since it's sometimes possible to contribute a truly
amazing speedup that's only a few characters in size, it really ought to be
up to the core dev. Or maybe it should be limited to at most a handful of
typo, grammar or punctuation fixes in docs or comments. (And no splitting
it up into a multiple PRs to duck the limit.)


> ---
>
> [1] - https://github.com/python/cpython/pull/18603
>
> [2] - The term "minimal" can be interchanged with "trivial" for the most
> part in the above context, but I tend to prefer the former. IMO, it 

[Python-Dev] Re: Merging PRs without CLA signed

[Ivan Pozdeev via Python-Dev]

On 24.02.2020 7:07, Kyle Stanley wrote:


For a full list of merged PRs to CPython with a "CLA not signed" label, see the following: 
https://github.com/python/cpython/pulls?utf8=%E2%9C%93=is%3Apr+state%3Amerged+label%3A%22CLA+not+signed%22


Note that if you open a PR, and _then_ sign the CLA, the label is not updated (at least, that's what I experienced before I did). So this 
list is likely inaccurate.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IO66YO2SVW55M5KXCAM2P4J7DVMSCK5X/
Code of Conduct: http://python.org/psf/codeofconduct/