DCO Validation During Contribution Review

Owned by Danno Ferrin
Last updated: Apr 15, 2021 by David Enyeart
3 min read
Status

PROPOSED 

BlockingNone blocking, but Besu docs and Fabric docs are regularly impacted
Outcome
Minutes Link

Overview of Proposal

Multiple projects have faced issues with new contributors not correctly adding DCO sign off lines in their contributions, and when maintainers attempt to help the new contributors fix the issue the contributor withdraws from the process either implicitly (by ghosting) or explicitly (by saying this is too complex and then withdrawing).  This is most pronounced in the documentation repositories.

The proposed solution would allow for an author to make a DCO declaration outside of the git commits for workflows that support it. A comment in a Github PR would be an example.  Rather than asking the contributor to re-submit their git commits they can assert the DCO in the comments and the maintainers would squash merge the commit.

This is what Chef does with their DCO statements (see the next to last Q&A question).

Formal Proposal(s)

If a contributor does not make a DCO statement in each of their commits in a proposed change (via GitHub PR or other similar workflow) they can make a declaration in the comments of the review stream.  Ideally adding the "Signed-off-by: John Doe <john.doe@example.com>" line in the comment stream or another statement such as "this is my work and it complies with the DCO."  It is good form for the maintainers to directly link https://developercertificate.org/ when requesting the contributor provide an in-review stream sign-off. One such claim in a PR will be sufficient for each commit in the PR up to the point of attestation.

When merging such a commit the maintainer will either need to rebase the commit so that all commit entries have a DCO or perform a "squash" commit and enter the DCO. The "signed off by tag" in one of two forms:

  • If the contributor provided a "signed off by" tag in the comment stream that tag alone may be used.  The maintainer may optionally add their own tag in addition.
  • Otherwise the maintainer will need to provide their own signed off by tag (pursuant to clause c) in one of two forms:
    • Signed-off-by: Jane Maintainer <jmaintainer@example.org> 
    • Signed-off-by: Jane Maintainer <jmaintainer@example.org> on behalf of John Doe <john.doe@example.com> 

This proposal only applies to commits submitted for review.  All commits in branches that releases of any caliber are built off of (main/master, release branches, patch branches, alpha/beta/nightly) must still contain a signed off by tag in each commit.

Linear merges or linear rebases should not be done for commits covered by this policy.  Squash merges are recommended instead.

Tooling Impact

The current configuration of the DCO bot will need to be adjusted.  The quickest change is to make the DCO bot check not block merging, although that introduces risk that invalid merges may occur.  A more involved change would be for the DCO bot to check merge comments for a DCO tag.  If the maintainer accepts a non-tag statement they should reply with an "on behalf of" tag in the stream which the DCO bot can pick up.

Projects should be encouraged to add DCO checks into their CI build process.  Such a check would cause the CI to fail to produce a usable output if the DCO validation of the commits fails. These checks are not as universal as the DCO bot. If a project can demonstrate that the DCO checks are caught by their CI system then they would be allowed to drop DCO but errors to advisory errors in the Github PR flow.

Action Items

  • Type your task here, using "@" to assign to a user and "//" to select a due date

Reviewed By