CONTRIBUTING.md changes to add Legal section + adding dco.txt

CONTRIBUTING.md

@@ -1,28 +1,69 @@
-# Guidelines for Contributing
+# Contributing
 
 Contributions from the community are essential in keeping Hibernate (any Open Source
-project really) strong and successful.  While we try to keep requirements for
+project really) strong and successful.  
-contributing to a minimum, there are a few guidelines we ask that you mind.
+
+# Legal
+
+All original contributions to Hibernate are licensed under the 
+[GNU Lesser General Public License (LGPL)](https://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt), 
+version 2.1 or later, or, if another license is specified as governing the file or directory being 
+modified, such other license.  The LGPL text is included verbatim in the link:lgpl.txt[lgpl.txt] file 
+in the root directory of the ORM repository.
+
+All contributions are subject to the [Developer Certificate of Origin (DCO)](https://developercertificate.org/).  
+The DCO text is also included verbatim in the link:dco.txt[dco.txt] file in the root directory of the ORM repository.
+
+
+## Guidelines
+
+While we try to keep requirements for contributing to a minimum, there are a few guidelines 
+we ask that you mind.
+
+For code contributions, these guidelines include:
+* respect the project code style - find templates for [Eclipse](https://community.jboss.org/docs/DOC-16649)
+ 	and [IntelliJ IDEA](https://community.jboss.org/docs/DOC-15468)
+* have a corresponding JIRA issue and the key for this JIRA issue should be used in the commit message
+* have a set of appropriate tests.  For bug reports, the tests reproduce the initial reported bug
+	and illustrates that the solution actually fixes the bug.  For features/enhancements, the 
+	tests illustrate the feature working as intended.  In both cases the tests are incorporated into
+	the project to protect against regressions.
+* if applicable, documentation is updated to reflect the introduced changes
+* the code compiles and the tests pass (`./gradlew clean build`)
+
+For documentation contributions, mainly just respect the project code style, especially in regards 
+to use of tabs - as mentioned above, code style templates are available for both Eclipse and IntelliJ 
+IDEA IDEs.  Ideally these contributions would also have a corresponding JIRA issue, although this 
+is less necessary for documentation contributions.
+
 
 ## Getting Started
 
 If you are just getting started with Git, GitHub and/or contributing to Hibernate via
-GitHub there are a few pre-requisite steps.
+GitHub there are a few pre-requisite steps to follow:
 
-* Make sure you have signed a [Contributor License Agreement](https://cla.jboss.org) (CLA) for the Hibernate project
 * Make sure you have a [Hibernate JIRA account](https://hibernate.atlassian.net)
 * Make sure you have a [GitHub account](https://github.com/signup/free)
 * [Fork](https://help.github.com/articles/fork-a-repo) the Hibernate repository.  As discussed in
 the linked page, this also includes:
     * [Set](https://help.github.com/articles/set-up-git) up your local git install
     * Clone your fork
-* See the wiki pages for setting up your IDE, whether you use [IntelliJ IDEA](https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ)
+* See the wiki pages for setting up your IDE, whether you use 
+[IntelliJ IDEA](https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ)
 or [Eclipse](https://community.jboss.org/wiki/ContributingToHibernateUsingEclipse).
 
+
 ## Create the working (topic) branch
 
-Create a [topic branch](http://git-scm.com/book/en/Git-Branching-Branching-Workflows#Topic-Branches) on which you
+Create a [topic branch](http://git-scm.com/book/en/Git-Branching-Branching-Workflows#Topic-Branches) 
-will work.  The convention is to name the branch using the JIRA issue key.  If there is not already a JIRA issue
+on which you will work.  The convention is to incorporate the JIRA issue key in the name of this branch,
+although this is more of a mnemonic strategy than a hard=and-fast rule - but doing so helps:
+* remember what each branch is for 
+* isolate the work from other contributions you may be working on.  
+
+
+This branch will be the base for 
+.  If there is not already a JIRA issue
 covering the work you want to do, create one.  Assuming you will be working from the master branch and working
 on the JIRA HHH-123 : `git checkout -b HHH-123 master`
 
@@ -46,7 +87,17 @@ appreciated btw), please use rebasing rather than merging.  Merging creates
 
 ## Submit
 
-* If you have not already, sign the [Contributor License Agreement](https://cla.jboss.org).
 * Push your changes to the topic branch in your fork of the repository.
 * Initiate a [pull request](http://help.github.com/articles/creating-a-pull-request)
 * Update the JIRA issue, adding a comment including a link to the created pull request
+	_if the JIRA key was not used in the commit message_.
+
+
+It is important that this topic branch on your fork:
+
+* be isolated to just the work on this one JIRA issue, or multiple issues if they are
+	related and also fixed/implemented by this work.  The main point is to not push
+	commits for more than one PR to a single branch - GitHub PRs are linked to
+	a branch rather than specific commits.
+* remain until the PR is closed.  Once the underlying branch is deleted the corresponding
+	PR will be closed, if not already, and the changes will be lost.

dco.txt

@@ -0,0 +1,37 @@
+Developer Certificate of Origin
+Version 1.1
+
+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+1 Letterman Drive
+Suite D4700
+San Francisco, CA, 94129
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+
+Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+(a) The contribution was created in whole or in part by me and I
+    have the right to submit it under the open source license
+    indicated in the file; or
+
+(b) The contribution is based upon previous work that, to the best
+    of my knowledge, is covered under an appropriate open source
+    license and I have the right under that license to submit that
+    work with modifications, whether created in whole or in part
+    by me, under the same open source license (unless I am
+    permitted to submit under a different license), as indicated
+    in the file; or
+
+(c) The contribution was provided directly to me by some other
+    person who certified (a), (b) or (c) and I have not modified
+    it.
+
+(d) I understand and agree that this project and the contribution
+    are public and that a record of the contribution (including all
+    personal information I submit with it, including my sign-off) is
+    maintained indefinitely and may be redistributed consistent with
+    this project or the open source license(s) involved.