### Problem to solve Ability to prevent new contributions to a project, or accept new contributions via merge requests, that have not been properly signed-off as part of a project's [Developer Certificate of Origin](http://developercertificate.org/) requirements. ### Further details It's the goal of this request to enable Open Source maintainers to restrict code contributions that have not agreed to a _Developer Certificate of Origin_. Doing so empowers those maintainers to create an environment that aligns with their risk tolerances (willingness to take on legal risks associated with accepting contributions from third-parties). ### Proposal Add a new option to the _Push Rules_ section of the _Repository_ settings page that restricts pushes to a project if any commit being pushed lacks a `Signed-off-by` line ([git signed-off-by documentation](https://git-scm.com/docs/git-commit#git-commit--s)). ---  --- ### What does success look like, and how can we measure that? If by success, you mean success in users adopting this feature, then merely grepping the database should be sufficient. As to what success looks like in terms of total expected usage, that's a little tricky since DCOs are still quite new. In my research few projects are aware of DCOs, or feel a DCO is sufficient protection. However, given that most, in my experience, CLAs are merely restatement's of a project's existing license, we should see most CLA-based workflows adopt this feature as they become more comfortable with a DCO. As for success of the feature itself, tests should verify that no commit, directly pushed, accepted through a merge request, or contributed through the online editor (Web IDE), should be incorporated into a project's _default_ branch unless each commit contributed contains the properly formatted `Signed-off-by` line. ### Links / references