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...>