Collecting CLAs for contributions made outside of GitHub

[Justin Obara]

Hi Everyone,

It’s been a wile since we switched from our paper/pdf based CLAs to using CLA Assistant <https://cla-assistant.io/> to require digital signatures when submitting PRs to our GitHub repos. However, we’ve found that this workflow doesn’t work well when contributions are made through an external means, such as Netlify CMS <https://www.netlifycms.org/>. In such a case the contribution is made in the external system and submitted as a commit to GitHub in a Pull Request. But the contributor may not have a GitHub account and doesn’t really ever need to see the GitHub UI to make the contribution. This means that they have no means of accepting the CLA.

Typically we only required the CLA be signed for code contributions, so for now, things like Netlify CMS contributions would likely fall outside of that requirement. Unfortunately, CLA Assistant doesn’t allow much breadth in terms of customization options. We can add users to an allowlist, exclude some repos, or have a minimum number of line or file changes. However, none of those options fully satisfy the case. For example, ideally we’d still require a CLA to be signed for code changes.

Another option would be to transition to using CLA assistant lite <https://github.com/marketplace/actions/cla-assistant-lite>, which is a GitHub Action variant of CLA Assistant. Some benefits:

Anyone could configure
right now only I can configure CLA Assistant
More configuration options available as we have more control over configuration for Github Actions. 
E.g. running against specific branches and etc.
Although configuration is still limited
Would be easier to have different configurations for each repo

Some drawbacks:

More work for configuring/setting up. 
At the moment CLA Assistant is configured per org, so all repos share the same configuration. CLA Assistant is configured per repo. 
May be able to mitigate the work for new repos by creating a template repo, but would have to update all existing repos.

Additionally we’d need to decide where to store the signatures. They could either be committed into a file in the repo, or stored in an external repo, which would allow us to centralize the signatures and could even be private if desired.

There are additional options though. 
Switch to a Developer Certificate of Origin (DCO),
may not help with Netlify CMS issue
Info on CLA vs DCO <https://opensource.com/article/18/3/cla-vs-dco-whats-difference>
Drop the CLA requirement completely
Keep CLA Assistant as is, and exclude some repos; moving them to CLA Assistant lite or something else.
etc.

Another conversation that may be needed, along with this or separate, is how we inform contributors using external systems like Netlify CMS and etc. about what the contributor license is (e.g. CC BY 4.0), privacy policy, code of conduct and etc. 

It would be great to hear what the community thinks about this and what suggestions you all may have.

Thanks
Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20210503/b69cebbe/attachment.htm>