I’ve written down requirements for a new/improved CLA host https://github.com/python/core-workflow/issues/360
3 Likes
Hi @Mariatta,
I am one of the Project maintainer of the CLA Assistant and it is unfortunate CLA Assistant is No-Go.
This bug which you mentioned in this Pull Request https://github.com/cla-assistant/cla-assistant/pull/462 is been fixed.
Regarding handling corporate CLA, there is a whitelisting feature in CLA-Assistant in which you can whitelist the whole GItHub Organisation. And If a Organisation is whitelisted, then all the members of the organisation don’t have to sign the CLA.We are also doing membership test which is, If a non-member collaborator has write access to the whitelisted Organisation then he/she has to sign the CLA because he/she is not part of the whitelisted organisation.
If something is missing, please feel free to reach out to me and It is great to see that you have considered CLA Assistant for handling CLAs.
1 Like
Thanks for the info, @ibakshay!
Is there any way to differentiate between corporate versus personal contributions? I.e. if my employer signs a CLA on work time but I haven’t signed for personal contributions can you differentiate those? We were thinking that could be done based on where the fork was coming from for instance.
Hi @brettcannon,
Just to give a quick background, the CLA Assistant currently only supports the Individual CLA but not the Corporate CLA. We have already implemented all the checks to support the Corporate CLA in the backend (excluding email check), However, due to GitHub API restrictions like we don’t have access to the private members of the GItHub organisation and other edge cases, we decided not to implement Corporate CLA functionality in the UI as we are not convinced enough.
So, if a organisation signs the Corporate CLA (hard signature), then you can just whitelist that organisation and all the members of that organisation don’t have to sign the individual CLA.
Is there any way to differentiate between corporate versus personal contributions?
Currently you can only differentiate by adding the Custom Fields to the CLA so that the contributor has to fill these custom fields before signing the CLA.
"category": {
"title": "How do you sign?",
"type": {
"enum": [
"I am signing on behalf of myself.",
"I am signing on behalf of my employer."
]
},
"required": true
}
This is why we were planning to make it based on where the branch for the PR originated from. I.e. if the PR is coming from a fork under the organization that has signed the CLA then the PR is considered cleared.
But that doesn’t let one programmatically differentiate between a work contribution and personal contribution based on one’s GitHub account. For instance, I use my GitHub account both for personal and work purposes, so if my work happened to sign the CLA but I had not personally I could still manage to submit a change on my GitHub account outside of work time and have it slip through even though that work was not under a CLA.
But this is a problem that the current process shares, right? So why should this be a reason not to adopt CLA Assistant?
It’s best to defer to PSF’s lawyer on this matter. In any case, your personal opinion is off topic to whether or not we can use CLA-assistant.
2 Likes
Yes.
I think the question is “do we want to solve this problem?” If the answer is “yes” then we’re back to the question of whether we think CLA Assistant is up to solving it for us or if any of us want to hack on some Java code to make it happen (and if @ibakshay could let us know how difficult this functionality would be to add). Otherwise we’re back to solving our CLA issues ourselves.
But if we don’t want to bother to solve the issue then CLA Assistant would be a fine solution. It’s just one of the reasons this discussion kicked up was because of the corporate contributor conundrum (with getting in-browser signing the other reason that I’m aware of).
OK, but since CLA Assistant is listed as a blocker for the bpo->GitHub transition I think we may have to put off solving this until after the transition, and our best option for getting the transition unblocked still seems CLA Assistant. The solution will depend more on GitHub than on anything else, since the problem is how to distinguish corporate and personal use of the same GitHub account. (Maybe the email used to push a PR is visible?) We may have to bring this up with GitHub.
You can tweak the code to do CLA check based on where the PR originated from. I believe the effort will be minimum.
However, with the current solution, you can whitelist the entire GitHub organisation. i.e If a PR is coming from a organisation that has already signed the Corporate CLA, then the PR will be accepted.
We also do a membership check in this scenario to check whether all the committers of this PR are members of the organisation, If a committer from this PR is not a member but just has write access, then he/she has to sign the Individual CLA.
Unfortunately, we do not have a solution yet to tackle this problem. As the email address can also be made private , we cannot check with the email to distinguish one’s contributions between the corporate and personal use. I will take it as a feature request and discuss with my team regarding this topic. The CLA Assistant is not written in Java but a Node j.s Application. Pull Request or any lead is very much welcome.
1 Like