> 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-or-otherwise-using-python>. 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 <tjre...@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 <aeros...@gmail.com > > <mailto: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. > > 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@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/CIJQTX557STYUPVW3GHQ7EEKSSY4V4UO/ Code of Conduct: http://python.org/psf/codeofconduct/
