diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 74bdd2c..590c773 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -86,20 +86,20 @@
  git clone https://gem5.googlesource.com/public/gem5
 ```
 
-By default, the master branch is checked out. The master branch is stable,
-containing the latest released version of gem5. To obtain code still
-under-development (and which contributions can be made):
+By default, the stable branch is checked out. The stable branch contains the
+latest released version of gem5. To obtain code still under-development (and
+which contributions can be made):
 
 ```
 cd gem5
 git checkout --track origin/develop
 ```
 
-Changes should be made to this develop branch. Changes to the master branch
+Changes should be made to this develop branch. Changes to the stable branch
 will be blocked. Once a change on the develop branch is properly incorporated
-into the gem5 repo it will be merged into the master Branch upon the next
+into the gem5 repo it will be merged into the stable Branch upon the next
 release of gem5. New releases of gem5 occur three times a year. Ergo, changes
-made to the develop branch should appear on the master branch within three to
+made to the develop branch should appear on the stable branch within three to
 four months as part of a stable release.
 
 Other gem5 repositories
@@ -322,7 +322,7 @@
 ========
 
 By default, contributions to gem5 should be made on the develop branch. The
-master branch is maintained as a stable release branch (i.e., it can be pulled
+stable branch is maintained as a stable release branch (i.e., it can be pulled
 to obtain the latest official release of gem5). Creation of additional branches
 is generally discouraged due to their tendency to bloat git repositories with
 abandoned code. However, the creation of new branches is permitted for
@@ -491,7 +491,7 @@
 2. When a release is ready, a new staging branch shall be created by a project
 maintainer, from develop, with the name "release-staging-{VERSION}". The
 gem5-dev mailing list will be notified that the staging branch will be merged
-into the master branch after two weeks, thus marking the new release.
+into the stable branch after two weeks, thus marking the new release.
 3. The staging branch will have the full suite of gem5 tests run on it to
 ensure all tests pass and the to-be-released code is in a decent state.
 4. If a user submits a changeset to the staging branch, it will be considered
@@ -504,8 +504,8 @@
 to gem5 will continue to be made to the develop branch. Patches submitted
 into the staging branch do not need to be re-added to the develop branch.
 5. Once signed off by members of the PMC the staging branch shall be merged
-into the master and develop branch. The staging branch will then be deleted.
-6. The master branch shall be tagged with the correct version number for that
+into the stable and develop branch. The staging branch will then be deleted.
+6. The stable branch shall be tagged with the correct version number for that
 release. gem5 conforms to a "v{YY}.{MAJOR}.{MINOR}.{HOTFIX}" versioning system.
 E.g., the first major release of 2022 will be "v22.0.0.0", followed by
 "v22.1.0.0". All the releases (with the exception of hotfixes) are considered
@@ -527,14 +527,14 @@
 made by members of the PMC if there is no consensus. Assuming the hotfix is
 permitted, the following steps will be taken:
 
-1. A new branch with the prefix "hotfix-" will be created from the master
+1. A new branch with the prefix "hotfix-" will be created from the stable
 branch. Only gem5 maintainers can create branches. If a non-maintainer requires
 the creation of a hotfix branch then they should contact a gem5 maintainer.
 2. The change shall be submitted to the hotfix branch via gerrit. Full review,
 as with any other change, will be required.
 3. Once fully submitted, the hotfix branch shall be merged into both the
-develop and the master branch by a gem5 maintainer.
-4. The master branch will be tagged with the new version number; the same as
+develop and the stable branch by a gem5 maintainer.
+4. The stable branch will be tagged with the new version number; the same as
 the last but with an incremented hotfix number (e.g., "v20.2.0.0" would
 transition to "v20.2.0.1").
 4. The hotfix branch will then be deleted.