Merge pull request #12 from ADACS-Australia/feature/docker

Add pull_request template to the rendered template; update ADACS logo with off-white bg to match RTD theme.

.github/pull_request_template.md

@@ -6,16 +6,21 @@
 ### Related Issue(s)
 [If applicable, mention any related issues or tasks that this pull request addresses.]
 
-### Checklist
-Please make sure to review and check the following before submitting your pull request. Remove any items that are not applicable.
+### Checklists
+Please indicate which of the following (if any) are being contributed to the codebase by this PR:
 
-- [ ] You have added the text `[version:minor]` if new functionality has been added; `[version:major]` if there are any breaking changes.
-- [ ] Unit tests have been added or updated to ensure proper functionality.
-- [ ] Documentation has been updated to reflect the changes (if applicable).
+- [ ] New feature(s) (warranting a MINOR version bump);
+- [ ] Breaking change(s) (warranting a MAJOR version bump);
+- [ ] Bug fix(es); or
+- [ ] Documentation improvements.
+
+**Make sure that `[version:minor]` gets added to the head commit message if a MINOR bump is needed; `[version:major]` if a MAJOR bump is needed.**
+
+Please ensure that the following have been addressed (if applicable) before submitting your PR:
+
+- [ ] Unit tests have been added or updated to ensure proper functionality;
+- [ ] Documentation has been updated to reflect the changes (if applicable); and
 - [ ] All commit messages are clear and descriptive.
 
-### Additional Notes
+### Notes for reviewers
 [Include any additional information or notes that may be helpful for reviewers.]
-
-### Reviewer(s)
-[Tag any specific person or team responsible for reviewing this pull request, if applicable.]

docs/content/development_guidelines.md

@@ -20,7 +20,7 @@ workflows can be found within the `./.github/workflows/` directory and include:
 
 2. **bump.yml**
 
-    This workflow leverages the colocated `bump.sh` bash script to automatically increment the project version whenever code is pushed to the `main` branch.  It is controlled by adding the text `[version:minor]` or `[version:major]` to one of the commit messages of a pull request.
+    This workflow leverages the colocated `bump.sh` bash script to automatically increment the project version whenever code is pushed to the `main` branch.  It is controlled by adding the text `[version:minor]` or `[version:major]` to the message of the pull request's head commit.
 
 3. **publish.yml**
 
@@ -91,12 +91,12 @@ In the following, we lay-out some important guidelines for developing on this co
 
 ### Versioning
 
-Semantic versioning (i.e. a scheme that follows a `vMAJOR.MINOR.PATCH` format; see <https://semver.org> for details) is used for this project.  ***The single point of truth for the current production version is the last git tag on the main branch with a `v[0-9]*` format***.  When developing locally, the reported version will often appear as `v0.0.0-dev`.
+Semantic versioning (i.e. a scheme that follows a `vMAJOR.MINOR.PATCH` format; see <https://semver.org> for details) is used for this project.  ***The single point of truth for the current production version is the last git tag on the main branch with a `v[0-9]*` format***.  When developing locally, the reported version will appear as `v0.0.0-dev`.
 
 Changes are handled by a *GitHub Workflow* which increments the version and creates a new tag whenever a push occurs to the `main` branch.  This ensures that every commit on the `main` branch is assigned a unique version.  The logic by which it modifies the version is as follows:
 
-1. if the PR message (or one of its commits' messages) contains the text `[version:major]`, then `MAJOR` is incremented;
-2. else if the PR message (or one of its commits' messages) contains the text `[version:minor]`, then `MINOR` is incremented;
+1. if the message of the PR's head commit contains the text `[version:major]`, then `MAJOR` is incremented;
+2. else if it contains the text `[version:minor]`, then `MINOR` is incremented;
 3. else `PATCH` is incremented.
 
 A `MAJOR` version change should be indicated if the PR introduces a breaking change.  A `MINOR` version change should be indicated if the PR introduces new functionality.

{{cookiecutter.repo_name}}/.github/pull_request_template.md

@@ -0,0 +1,26 @@
+## Pull Request
+
+### Description
+[Provide a brief description of the changes or features implemented in this pull request.]
+
+### Related Issue(s)
+[If applicable, mention any related issues or tasks that this pull request addresses.]
+
+### Checklists
+Please indicate which of the following (if any) are being contributed to the codebase by this PR:
+
+- [ ] New feature(s) (warranting a MINOR version bump);
+- [ ] Breaking change(s) (warranting a MAJOR version bump);
+- [ ] Bug fix(es); or
+- [ ] Documentation improvements.
+
+**Make sure that `[version:minor]` gets added to the head commit message if a MINOR bump is needed; `[version:major]` if a MAJOR bump is needed.**
+
+Please ensure that the following have been addressed (if applicable) before submitting your PR:
+
+- [ ] Unit tests have been added or updated to ensure proper functionality;
+- [ ] Documentation has been updated to reflect the changes (if applicable); and
+- [ ] All commit messages are clear and descriptive.
+
+### Notes for reviewers
+[Include any additional information or notes that may be helpful for reviewers.]

{{cookiecutter.repo_name}}/docs/content/notes_for_developers.md

@@ -18,7 +18,7 @@ workflows can be found within the `./.github/workflows/` directory and include:
 
 2. **bump.yml**
 
-    This workflow leverages the colocated `bump.sh` bash script to automatically increment the project version whenever code is pushed to the `main` branch.  It is controlled by adding the text `[version:minor]` or `[version:major]` to one of the commit messages of a pull request.
+    This workflow leverages the colocated `bump.sh` bash script to automatically increment the project version whenever code is pushed to the `main` branch.  It is controlled by adding the text `[version:minor]` or `[version:major]` to the message of the pull request's head commit.
 
 3. **publish.yml**
 
@@ -89,12 +89,12 @@ In the following, we lay-out some important guidelines for developing on this co
 
 ### Versioning
 
-Semantic versioning (i.e. a scheme that follows a `vMAJOR.MINOR.PATCH` format; see <https://semver.org> for details) is used for this project.  ***The single point of truth for the current production version is the last git tag on the main branch with a `v[0-9]*` format***.  When developing locally, the reported version will often appear as `v0.0.0-dev`.
+Semantic versioning (i.e. a scheme that follows a `vMAJOR.MINOR.PATCH` format; see <https://semver.org> for details) is used for this project.  ***The single point of truth for the current production version is the last git tag on the main branch with a `v[0-9]*` format***.  When developing locally, the reported version will appear as `v0.0.0-dev`.
 
 Changes are handled by a *GitHub Workflow* which increments the version and creates a new tag whenever a push occurs to the `main` branch.  This ensures that every commit on the `main` branch is assigned a unique version.  The logic by which it modifies the version is as follows:
 
-1. if the PR message (or one of its commits' messages) contains the text `[version:major]`, then `MAJOR` is incremented;
-2. else if the PR message (or one of its commits' messages) contains the text `[version:minor]`, then `MINOR` is incremented;
+1. if the message of the PR's head commit contains the text `[version:major]`, then `MAJOR` is incremented;
+2. else if it contains the text `[version:minor]`, then `MINOR` is incremented;
 3. else `PATCH` is incremented.
 
 A `MAJOR` version change should be indicated if the PR introduces a breaking change.  A `MINOR` version change should be indicated if the PR introduces new functionality.