fix: Markups

.github/pull_request_template.md

@@ -1,11 +1,11 @@
 > [!IMPORTANT]
 >
 > * Please read our [Contributing Guidelines](CONTRIBUTING.md) before opening a PR.
-> * Before creating your PR, please ensure you have used the _correct base branch_ as per the [branching strategy](/docs/branching-strategy.md), both for branching from, and in the PR  UI above.
->   * For docs, this is `main`.
+> * Before creating your PR, please ensure you have used the _correct base branch_ as per the [branching strategy](/docs/branching-strategy.md), both for branching from, and in the PR UI above.
 >   * For most code changes, this is `develop`.
+>   * For stand-alone docs changes, this is `main`.
 >   * For workflow changes, this is the oldest supported `release/*` branch. 
-> * Please remove these sections as you fill in your PR.
+> * Please remove these sections as you fill out your PR.
 > 
 
 ## Summary

CONTRIBUTING.md

@@ -97,7 +97,7 @@ $ ./gradlew spotlessApply
 
 Commit your changes with a descriptive commit message.
 
-*  We prefer [convential commit messages](https://www.conventionalcommits.org/en/v1.0.0/), although don't enforce it
+*  We prefer [conventional commit messages](https://www.conventionalcommits.org/en/v1.0.0/), although don't enforce it
 *  Separate the subject from body with a blank line
 *  Limit the subject line to 50 characters
 *  Capitalise the subject line

docs/branching-strategy.md

@@ -52,13 +52,13 @@ When working on changes:
 
 Features branches usually branch from `develop`, unless they need to target the current/previous protocol version, in which case, they will need to target the appropriate `release/*` branch.
 
-### Doc changes
+### Stand-alone doc changes
 
-Docs changes should use a base branch of `main`.
+Public facing docs change unrelated to another ticket should use a base branch of `main` - as this is the branch which is first visible when someone looks at the repository.
 
 ### Workflow / CI changes
 
-Should branch from the _most downstream_ (earliest) supported branch. Typically this is a `release/*` branch.
+Workflow changes should branch from the _most downstream_ (earliest) supported branch. Typically this is a `release/*` branch.
 
 Once the post-merge process is followed, this change will find itself on all downstream base branches too.