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
_______________________________________________________
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
