Skip to content

Explain how to fill out the CLA #142

Closed

Description

@marienz

Before contributing to Python, I searched the developer guide (https://docs.python.org/devguide/) for "CLA", to make sure I would not have to file one. The string "CLA" does not appear on that page, and there was no reference to having to sign something in the quickstart section, so I assumed there was no need.

When I actually sent my pull request, I received a github message claiming signing the PSF CLA is "necessary for legal reasons before we can look at your contribution".

After signing it, I checked the dev guide more thoroughly. On https://docs.python.org/devguide/committing.html#contributor-licensing-agreements, it says "It’s unlikely bug fixes will require a Contributor Licensing Agreement unless they touch a lot of code" (which my pull request doesn't).

There are two (and a half) problems here:

  • The dev guide and the github message cannot both be right. One should be updated to match the other.

  • If signing a CLA is required, I think it's a good idea to mention this early on in the dev guide. If for whatever reason a contributor cannot or will not sign the CLA, they should find out about it before they have produced and sent off a pull request.

  • The abbreviation "CLA" might be common enough it's worth including in the dev guide, to make sure someone searching for that string (like I did) finds the right section.

Activity

  1. marienz commented on Mar 7, 2017

    @marienz
    Author

    Ah, and I just found https://docs.python.org/devguide/pullrequest.html#licensing, which is probably what I should have found to begin with. That one says I need to sign the CLA "for non-trivial changes".

  2. DimitrisJim commented on Mar 7, 2017

    @DimitrisJim
    Contributor

    I thought the-knights-who-say-ni would've included that url in the text reply it leaves. It might be worth to add it there.

  3. brettcannon commented on Mar 7, 2017

    @brettcannon
    Member

    Technically we can skip the CLA signing for any changes where we can't be sued over patents or copyrights. The problem is that's not exactly well-defined, so the bot automatically just says "sign the CLA" rather than try and explain the nuance of the situation in a single GitHub comment. (Ultimately it's up to Python core developers to make a call as to whether to ignore when someone doesn't sign).

    And as a refresher of what the bot says, see e.g. python/cpython#540 (comment). It doesn't link to that part of the devguide because it doesn't say anything the bot doesn't already tell you itself. But if a location in the devguide subsumed those instructions then we could simplify the message to something more like "we can't find a CLA for you, please read the devguide (link) on how to do that."

  4. DimitrisJim commented on Mar 7, 2017

    @DimitrisJim
    Contributor

    Linking to the devguide would probably be better, both the NO_CLA_BODY and NO_USERNAME_BODY sections of the bot reply could be greatly simplified.

    Should I open a new issue to discuss this or should this issue just be renamed?

  5. changed the title [-]Clarify when filing a contributor agreement (CLA) is necessary[/-] [+]Explain how to fill out the CLA[/+] on Mar 7, 2017
  6. brettcannon commented on Mar 7, 2017

    @brettcannon
    Member

    I've hijacked this issue since it all ties together about when to fill out the CLA (always), and how.

  7. DimitrisJim commented on Mar 7, 2017

    @DimitrisJim
    Contributor

    The Licensing section of pullrequest seems like the best place for this. It should also be positioned before the changes proposed in #140 so users can first deal with the licencing before the actual submission.

  8. marienz commented on Mar 8, 2017

    @marienz
    Author

    As currently written, the quick start guide does not reference licensing requirements or link to pullrequest before telling the contributor to "Push the branch on your fork on GitHub". I think it should, for two main reasons:

    • Getting the CLA signature processed can take a while. It's nice for the contributor to get it out of the way early, in parallel with preparing the pull request.
    • Although signing the CLA is probably a mere formality for the majority of contributors, a small number of them will not or cannot sign, and therefore cannot contribute. For those, I think it's in everyone's best interest if they find out before making their patch public. It saves the contributor time, and it avoids any possible problems if someone else later wants to send a similar patch.

    I realize the quick start guide needs to be as brief as it can sensibly be. So if this isn't worth mentioning there, maybe drop the "Push the branch on your fork on GitHub" and only link to pullrequest. That way, someone reading the instructions up to the point of making the patch public stands a better chance of noticing the licensing bit in time.

  9. willingc commented on Mar 8, 2017

    @willingc
    Collaborator

    One way to concisely and effectively address the CLA in the quickstart would be to add one sentence at the end of Step 7:

    First time contributors will need to sign the Contributor Licensing Agreement (CLA) as described in the Licensing section of this guide.

  10. DimitrisJim commented on Mar 15, 2017

    @DimitrisJim
    Contributor

    If someone is working on this, please tell me. If not, I'll try and make a PR in the following days.

  11. DimitrisJim commented on Mar 27, 2017

    @DimitrisJim
    Contributor

    @marienz if you can, take a look at the submitted PR and tell me if you think it addressed your concerns.
    We can then close this issue :-)

  12. marienz commented on Mar 27, 2017

    @marienz
    Author

    Thanks, that completely addresses the concerns I had when opening this issue.

    The "committing" section of the dev guide still says "It’s unlikely bug fixes will require a Contributor Licensing Agreement unless they touch a lot of code". I suspect that's not quite right, but with the PR you submitted new contributors are unlikely to stumble across that section.

  13. brettcannon commented on Mar 27, 2017

    @brettcannon
    Member

    @marienz that wording got tweaked to be stronger so that takes care of everything!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions