diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 47752c2935..be0bd15ed6 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,6 +1,6 @@
 # Contributing
 
-Contributions from the community are essential in keeping Hibernate (any Open Source
+Contributions from the community are essential in keeping Hibernate (and any Open Source
 project really) strong and successful.  
 
 # Legal
@@ -8,11 +8,13 @@ project really) strong and successful.
 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 [lgpl.txt](lgpl.txt) file 
-in the root directory of the ORM repository.
+modified, such other license.
+
+The LGPL text is included verbatim in the [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 [dco.txt](dco.txt) file in the root directory of the ORM repository.
+
+The DCO text is available verbatim in the [dco.txt](dco.txt) file in the root directory of the ORM repository.
 
 
 ## Guidelines
@@ -21,33 +23,35 @@ While we try to keep requirements for contributing to a minimum, there are a few
 we ask that you mind.
 
 For code contributions, these guidelines include:
-* respect the project code style - find templates for [IntelliJ IDEA](https://hibernate.org/community/contribute/intellij-idea/) or [Eclipse](https://hibernate.org/community/contribute/eclipse-ide/)
-* 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 illustrate 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`)
+* Respect the project code style - find templates for [IntelliJ IDEA](https://hibernate.org/community/contribute/intellij-idea/) or [Eclipse](https://hibernate.org/community/contribute/eclipse-ide/)
+* Have a corresponding JIRA [issue](https://hibernate.atlassian.net/browse/HHH) and be sure to include the key for this JIRA issue in your commit messages.
+* Have a set of appropriate tests.  
+  	For your convenience, a [set of test templates](https://github.com/hibernate/hibernate-test-case-templates/tree/main/orm) have been made available.
+  	
+	When submitting bug reports, the tests should reproduce the initially reported bug and illustrate that your solution addresses the issue.
+	For features/enhancements, the tests should demonstrated that the feature works as intended.  
+    	In both cases, be sure to incorporate your tests into the project to protect against possible regressions.
+* If applicable, documentation should be 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 IntelliJ IDEA and Eclipse
-IDEs.  Ideally these contributions would also have a corresponding JIRA issue, although this 
+For documentation contributions, mainly to respect the project code style, especially in regards 
+to the use of tabs - as mentioned above, code style templates are available for both IntelliJ IDEA and Eclipse
+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
+If you are just getting started with Git, GitHub, and/or contributing to Hibernate via
 GitHub there are a few pre-requisite steps to follow:
 
-* 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
+* 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 up your local git install](https://help.github.com/articles/set-up-git) 
     * clone your fork
-* see the wiki pages for setting up your IDE, whether you use 
+* See the wiki pages for setting up your IDE, whether you use 
 [IntelliJ IDEA](https://hibernate.org/community/contribute/intellij-idea/)
 or [Eclipse](https://hibernate.org/community/contribute/eclipse-ide/)<sup>(1)</sup>.
 
@@ -57,8 +61,8 @@ or [Eclipse](https://hibernate.org/community/contribute/eclipse-ide/)<sup>(1)</s
 Create a [topic branch](https://git-scm.com/book/en/Git-Branching-Branching-Workflows#Topic-Branches) 
 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
+* Remember what each branch is for 
+* Isolate the work from other contributions you may be working on
 
 _If there is not already a JIRA issue covering the work you want to do, create one._
   
@@ -73,27 +77,26 @@ Do your thing!
 
 ## Commit
 
-* make commits of logical units
-* be sure to **use the JIRA issue key** in the commit message.  This is how JIRA will pick
+* Make commits of logical units
+* Be sure to **use the JIRA issue key** in the commit message.  This is how JIRA will pick
 up the related commits and display them on the JIRA issue
-* make sure you have added the necessary tests for your changes
-* run _all_ the tests to assure nothing else was accidentally broken
-* make sure your source does not violate the _checkstyles_
+* Make sure you have added the necessary tests for your changes
+* Run _all_ the tests to ensure nothing else was accidentally broken
+* Make sure your source does not violate the _checkstyles_
 
-_Prior to committing, if you want to pull in the latest upstream changes (highly
+_Before committing, if you want to pull in the latest upstream changes (highly
 appreciated btw), please use rebasing rather than merging.  Merging creates
-"merge commits" that really muck up the project timeline._
+"merge commits" that invariably muck up the project timeline._
 
 ## Submit
 
-* push your changes to the topic branch in your fork of the repository
-* initiate a [pull request](https://help.github.com/articles/creating-a-pull-request)
-* update the JIRA issue by providing the PR link in the **Pull Request** column on the right
-
+* Push your changes to the topic branch in your fork of the repository
+* Initiate a [pull request](https://help.github.com/articles/creating-a-pull-request)
+* Once your pull request has been summitted you can verify that the pull request has been properly linked to its corrosponding Jira issue by clicking on the _Recent rule runs_ _Refresh_ button on the right side of issue, if your pull request has been properly linked a _Pull Request (ORM)_ entry will be displayed.
 
 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
+* Is 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