Merging PRs without CLA signed
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 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&q=is%3Apr+state%3Amerged+label%3A%22CLA+not+signed%22 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. *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. 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? --- [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 comes across as more respectful to the efforts made by the author, as even the smallest of PRs can require substantial efforts from first-time contributors that are entirely unfamiliar with the workflow; regardless of how small the change is. [3] - https://devguide.python.org/pullrequest/#licensing Regards, Kyle Stanley
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&q=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.
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:
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-leave@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/IO66YO2S... Code of Conduct: http://python.org/psf/codeofconduct/
On Mon, 24 Feb 2020 at 14:51, Kyle Stanley <aeros167@gmail.com> 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 | ncoghlan@gmail.com | Brisbane, Australia
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
On Sun, Feb 23, 2020 at 8:11 PM Kyle Stanley <aeros167@gmail.com> 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&q=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 comes across as more respectful to the efforts made by the author, as even the smallest of PRs can require substantial efforts from first-time contributors that are entirely unfamiliar with the workflow; regardless of how small the change is.
[3] - https://devguide.python.org/pullrequest/#licensing
Regards, Kyle Stanley
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
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?)
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
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. 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?
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
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. 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 <guido@python.org> wrote:
On Sun, Feb 23, 2020 at 8:11 PM Kyle Stanley <aeros167@gmail.com> 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&q=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 comes across as more respectful to the efforts made by the author, as even the smallest of PRs can require substantial efforts from first-time contributors that are entirely unfamiliar with the workflow; regardless of how small the change is.
[3] - https://devguide.python.org/pullrequest/#licensing
Regards, Kyle Stanley
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
On Mon, 24 Feb 2020 00:30:41 -0500 Kyle Stanley <aeros167@gmail.com> 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.
On Tue, Feb 25, 2020 at 2:25 AM Antoine Pitrou <solipsis@pitrou.net> wrote:
On Mon, 24 Feb 2020 00:30:41 -0500 Kyle Stanley <aeros167@gmail.com> 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
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 <rosuav@gmail.com> wrote:
On Tue, Feb 25, 2020 at 2:25 AM Antoine Pitrou <solipsis@pitrou.net> wrote:
On Mon, 24 Feb 2020 00:30:41 -0500 Kyle Stanley <aeros167@gmail.com> 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-leave@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/KNX3ZIQK... Code of Conduct: http://python.org/psf/codeofconduct/
On 2/24/2020 10:32 AM, Chris Angelico wrote:
On Tue, Feb 25, 2020 at 2:25 AM Antoine Pitrou <solipsis@pitrou.net> 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
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.
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~
On 2/23/2020 11:44 PM, Guido van Rossum wrote:
On Sun, Feb 23, 2020 at 8:11 PM Kyle Stanley <aeros167@gmail.com <mailto:aeros167@gmail.com>> 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
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 <https://www.python.org/psf/contrib/contrib-form/> 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 <https://docs.python.org/dev/license.html#terms-and-conditions-for-accessing-...>. Therefore, you need to sign a contributor agreement <https://www.python.org/psf/contrib/> which allows the Python Software Foundation <https://www.python.org/psf/> 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 <tjreedy@udel.edu> wrote:
On 2/23/2020 11:44 PM, Guido van Rossum wrote:
On Sun, Feb 23, 2020 at 8:11 PM Kyle Stanley <aeros167@gmail.com <mailto:aeros167@gmail.com>> 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-leave@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/UARCSQSB... Code of Conduct: http://python.org/psf/codeofconduct/
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.
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.
participants (11)
-
Antoine Pitrou -
Brett Cannon -
Chris Angelico -
David Mertz -
Ethan Furman -
Guido van Rossum -
Ivan Pozdeev -
Kyle Stanley -
Mariatta -
Nick Coghlan -
Terry Reedy