Increase Contributor-Friendliness (CLA/DCO/Open)

[ghost]

As we are looking into sandboxing ContainerSSH per request of some of our users and contributors, we are evaluating licensing as well as the CLA and DCO process required by the CNCF IP Policy.

Proposal

Currently, we require neither a CLA nor DCO. We understand the need for compliance and attribution, though, and would therefore like to propose another process for CLAs:

1. Organizations on GitHub can have a CLA repository which includes one file including the CLA text and its signatories below the text
2. A new contributor to the organization is requested to add their GitHub username to the CLA via a pull request on GitHub
3. When merging the pull request, a bot automatically adds the pull request number next to the contributor's username

This process is quick, lightweight, automated, can be performed via GitHub's user interface, and does not save unnecessary personal data. The addition of the PR number next to the username (signature) makes it easier to find the PR where the user added their username themselves.

Background

The DCO process does not allow for easy editing via the web interface, which is frequently used for small fixes. If a user does not know or forgets about signing off, which can happen with every subsequent PR even with regular contributors, they will have to clone the repository and force push with their signature applied. In addition, the DCO does not provide additional value to our project, our contributors, and our users, as it does not seem to be legally enforceable and there is no other benefit to our community, since any contribution already includes the contributor's name, e-mail address, and commit ID, allows adding co-authors and is therefore clearly attributable. A DCO for our projects seems redundant and unnecessarily complicates contributions, depriving us of several small fixes contributed by end users.

CNCF's current CLA process requires contributors to expose a large amount of personal data and sign a PDF which is then sent via e-mail or physical mail, both of which are time-consuming and hostile to people who want to contribute while protecting their privacy.

---

We would be very grateful if the CNCF considered this or another approach and are happy to provide the GitHub tooling for it.

[ghost]

It's also worth noting that organizational CLAs are typically a bureaucratic process to get signed and are not conducive to easy contributions. The CLA added to the repository should account for that and be lightweight enough for the occasional contributor to sign themselves, making a representation that they are either owners, or have permission to contribute the code. Developer Certificate of Origin would be a good contender with the process outlined above instead of a required signature on each commit.

[dims]

@sanjacodes FYI, there is a new UI/UX for CLA, please see https://easycla.lfx.linuxfoundation.org/ ( Kubernetes has already switched to this easycla! - https://github.com/kubernetes/community/blob/master/CLA.md )

[ghost]

@dims thank you for your answer. If I'm reading this correctly, this still exposes the contributor email address to the CNCF and Docusign. Is that correct?

It also seems to introduce quite a bit of red tape for corporate contributors.

[ghost]

Thanks for the quick reply, @dims! Our main concern with our ContainerSSH community in particular is that we are in contact with several compliance-heavy institutions using it (telcos, government, research) and we know from their comments that it would take them months to get anything signed.

Exposing all e-mail addresses they have on their profile is also not what we would want for them. The EasyCLA bot and DocuSign seem to get access to all e-mail addresses as opposed to just the one they would want to use for their contribution.

Is there maybe some more information on what exactly happens with the data provided to the EasyCLA automation and how it is saved? We tried to search through the docs, but cannot find this information (other than the general LF privacy policy).

We want to make the contribution process as painless and privacy-oriented as possible for our community, so we're currently debating which options there are for us before applying for sandboxing. We used to require GPG-signed commits for each contribution, but dropped that after a while as we have gotten a few complaints. Since we dropped this requirement, we have received more contributions, particularly those simple fixes that greatly enhance documentation and the overall community experience.

Thanks a bunch!

[ghost]

What I mean with quick fixes, using CNCF repositories as an example: cncf/toc#843

Requiring new contributors to sign CLAs or DCOs for those one-off one-liners usually makes them just waive the idea and look for another project which makes it hard to grow projects that aren't already established.

Would it maybe be possible to drop the CLA/DCO requirement and move it to the incubating stage at which point projects usually have a more solid contributor base and it's easier to justify the additional hurdles?

[caniszczyk]

Ah, the CNCF TOC repo should be under DCO and we will fix that, that's an oversight.

re: privacy policy, all CNCF/LF/LFX tools etc are all covered by the LF Privacy Policy, this includes CLA information: https://www.linuxfoundation.org/privacy-policy/

re: DCO, it's going to get much easier for normal devs as this will be built in GitHub soon, you can trial it out here by making a request for your github org: todogroup/gh-issues#50 (comment)

@sanjacodes my advice would be to just use DCO for your project, no formal document required and it's what 98% of CNCF projects use

[ghost]

Yeah, that sounds like the most sensible solution right now. Thanks for the link to the trial and the quick response!

[dims]

yay!