On Sun, Feb 23, 2020 at 8:11 PM Kyle Stanley <aeros...@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-change-the-world/>
_______________________________________________ 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/TQCS55F5XUIWOXO2TEKJXPABY7466K22/ Code of Conduct: http://python.org/psf/codeofconduct/
