Collecting CLAs for contributions made outside of GitHub

Justin Obara obara.justin at gmail.com
Mon May 3 14:16:39 UTC 2021


Hi Gio,

I don’t think there is a web flow, but we could look at other ways of performing the signature with CLA Assistant lite. In the boilerplate GA workflow file  <https://github.com/cla-assistant/github-action#1-add-the-following-workflow-file-to-your-repository-in-this-pathgithubworkflowsclayml>that they provide there is a condition that checks comments for “recheck”, the signature, or PR event. We might be able to add some other event signing the CLA or add some other functionality to have some web flow write a comment with the appropriate signature. Would have to investigate in more detail though, but at least there are things we could explore.

Thanks
Justin

> On May 3, 2021, at 9:47 AM, Giovanni Tirloni <gtirloni at ocadu.ca> wrote:
> 
> Is there a web flow for new CLA signatures that could be used for new users (in Netlify CMS, another app, or an explicit request)? Or is it only through PR comments (that users get to know where to go)?
> 
> 
> From: fluid-work <fluid-work-bounces at lists.idrc.ocad.ca> on behalf of Justin Obara <obara.justin at gmail.com>
> Sent: Monday, May 3, 2021 10:43
> To: fluid-work at lists.idrc.ocad.ca <fluid-work at lists.idrc.ocad.ca>
> Subject: Collecting CLAs for contributions made outside of GitHub
>  
> Hi Everyone,
> 
> It’s been a wile since we switched from our paper/pdf based CLAs to using CLA Assistant <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcla-assistant.io%2F&data=04%7C01%7Cgtirloni%40ocadu.ca%7C482295cb1eda4c39188008d90e39652b%7C06e469d12d2a468fae9b7df0968eb6d7%7C0%7C0%7C637556461943368033%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fIAC4m9Pg5kERe2wiDckkB%2FPR4YpKA1gJbm9YI%2B1Wfs%3D&reserved=0> 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://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.netlifycms.org%2F&data=04%7C01%7Cgtirloni%40ocadu.ca%7C482295cb1eda4c39188008d90e39652b%7C06e469d12d2a468fae9b7df0968eb6d7%7C0%7C0%7C637556461943378022%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ItGPxp9e1dNjNKh%2FBvp3gkmslxwAO2g5ahm%2BhWpK38E%3D&reserved=0>. 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://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmarketplace%2Factions%2Fcla-assistant-lite&data=04%7C01%7Cgtirloni%40ocadu.ca%7C482295cb1eda4c39188008d90e39652b%7C06e469d12d2a468fae9b7df0968eb6d7%7C0%7C0%7C637556461943378022%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zs9WiCRjDdgB1gP1OuKrbn4PGMlSXtINX%2FzelV6PB%2Fc%3D&reserved=0>, 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://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopensource.com%2Farticle%2F18%2F3%2Fcla-vs-dco-whats-difference&data=04%7C01%7Cgtirloni%40ocadu.ca%7C482295cb1eda4c39188008d90e39652b%7C06e469d12d2a468fae9b7df0968eb6d7%7C0%7C0%7C637556461943388020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=34nDfJIP1QWP7DTpVlV3Sn8FRFIRMKdZILc9CQqV7bQ%3D&reserved=0>
> 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: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20210503/078480ae/attachment.htm>


More information about the fluid-work mailing list