Cross-project-council: Guidance for DCO (and DCO vs. CLA)

[tobie]

In https://github.com/openjs-foundation/cross-project-council/issues/124#issuecomment-512450068, @brianwarner announced that the foundation was working with its IP counsel to define the best way to offer a CLA for projects which want to continue using one and was planning to publish guidance on this topic. That looks super useful. ❤️

Is there a similar plan for projects which want to use a DCO instead? If so, what is the timeframe for guidance to be available to projects and what tooling, if any, is planned?

Also, is there a plan to release guidance for projects as to which one of CLA or DCO they should pick and why?

[mhdawson]

@brianwarner any starting comments/info?

[tobie]

I read through the IP Policy and while it clarifies the relationship between the DCO and the CLA, and the requirement to at least require a DCO, it doesn't say anything about the actual implementation of the policy.

Is that left to the project to decide?

If so, is it enough to include the text of the DCO in CONTRIBUTING.md, the way node.js does?

That would be ideal to lower the friction for contributing to the project.

[Trott]

If so, is it enough to include the text of the DCO in CONTRIBUTING.md, the way node.js does?

Node.js also includes the DCO text in the pull request template if that makes a difference.

[tobie]

Node.js also includes the DCO text in the pull request template if that makes a difference.

Oh! As a comment! That's pretty smart!

[kborchers]

I think @brianwarner and @mkdolan can provide more official guidance here but my understanding is that the Node.js implementation of DCO is still insufficient and that use of the DCO will require appropriate Signed-off by ... statements in commit messages in order to be accepted.

[tobie]

use of the DCO will require appropriate Signed-off by ... statements in commit messages in order to be accepted.

That’s precisely the part that is difficult to implement for contributors and that the AMP TSC would absolutely want to avoid.

[ljharb]

Don't forget that https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/ is also a pretty good option.

(whoops, sorry for the mis-close)

[tobie]

I agree, @ljharb. I think @davidstrauss astutely frames the issue in https://github.com/ampproject/meta-tsc/issues/25#issuecomment-549540646: although more lightweight on the legal requirements it imposes on contributors, DCO _implementations_ can end-up adding _more_ friction to contributions than a well implemented CLA. I’d like us to avoid this pitfall.

[ljharb]

In https://github.com/openjs-foundation/cross-project-council/pull/386#discussion_r353395129 @brianwarner points out that the node foundation didn't require a CLA; did it require a DCO? If not, then why would OpenJS projects require a DCO in the absence of a CLA?

[brianwarner]

@ljharb Node Foundation did require the DCO, yes.

[mcollina]

The Node.js project never enforced the letter of the DCO, as there is no signoff in any most of the commits.

[christian-bromann]

Has there been any updated to this? I found a comment from @MylesBorins saying that the foundation is finalizing the language of the CLA.

[tobie]

Yes. The OpenJSF's board has recently approved a CLA for individual and corporate contributors and is relying on the Linux Foundation's EasyCLA tool to implement it. More info here.

[christian-bromann]

Thanks @tobie , I will sign up for EasyCLA and will look for a place to document the process as guidance for other projects.

[tobie]

@brianwarner might be able to help set you up.

[brianwarner]

I can, yes.

@christian-bromann let's talk, I can walk you through the process.

[tobie]

There's also a test repo, if you want to look at what the outcome looks like: https://github.com/openjs-foundation/TEST-EasyCLA.