Merge pull request #77 from MonashDeepNeuron/dev

HPC Training Book v1.4.0

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,37 @@
+# Submit a pull request
+
+Thank you for submitting a pull request! To speed up the review process, please ensure that everything below
+is true:
+
+1. You have followed the [contributing guidelines][1]
+2. You have added an appropriate title to the PR.
+3. Requested a review from the HPC Training team.
+4. Delete any Markdown comments, instructions or anything else outside the below divider section once you have finished your PR.
+5. Ensure that you are merging into the `dev` and not `main`.
+
+Any questions should be directed to @MonashDeepNeuron/hpc-training.
+
+---
+
+Replace any "X" below with information about your pull request.
+
+## Details
+
+<!-- Provide details about changes you have made -->
+
+X
+
+## Linked
+
+<!-- Use a bullet list of linked or related issues, discussions, PR's and commits. This can be from this repository or external repositories.
+
+eg.
+
+- #1 (reference issue, PR or discussion by a hash number)
+- MonashDeepNeuron/EXAMPLE-REPO@<commit-hash> -->
+
+- X
+
+---
+
+[1]: https://github.com/MonashDeepNeuron/HPC-Training/blob/main/CONTRIBUTING.md

CONTRIBUTING.md

@@ -10,11 +10,13 @@ Any and all contributions are always very much appreciated. However, to make sur
 
 ## Steps to Contribute
 
-1. Fork the repository.
+1. Fork or Clone?
+   - If you are a member of Monash DeepNeuron you can simply clone repository.
+   - If you are an external contributor (non-member of Monash DeepNeuron) create a fork of the repository
 2. Create a new branch based on the `dev` branch (`git checkout -b <your_branch> dev`).
    If your contribution is a bug fix, you should name your branch `bugfix/xxx`;
    for a feature, it should be `feature/xxx` etc. Otherwise, just use your good
-   judgment. Consistent naming of branches is appreciated since it makes the
+   judgment. Alternatively you can use the name of the branch generated by GitHub if you create a branch from an issue (if you create a branch from an issue, make sure to change the source branch from `main` to `dev`). Consistent naming of branches is appreciated since it makes the
    output of `git branch` easier to understand with a single glance.
 3. Do your modifications on that branch.
 4. Make sure your modifications did not break anything by building and verifying the output using:
@@ -50,7 +52,7 @@ Any and all contributions are always very much appreciated. However, to make sur
 6. Push the changes to your fork (`git push origin <your_branch>`).
 7. Open a pull request against the package's `dev` branch (not against `main`).
 
-We will do my best to respond in a timely manner. I might discuss your patch and suggest some modifications, or I might amend your patch myself and ask you for feedback.
+We will do our best to respond in a timely manner. I might discuss your patch and suggest some modifications, or I might amend your patch myself and ask you for feedback.
 You will always be given proper credit.
 
 ## Style guide
@@ -67,28 +69,3 @@ For C content such as examples:
 - Do not leave trailing white spaces at the end of lines, and no more than a
   single newline at the end of a source file.
 - A definition blocks' initial brace should start on a newline, not trail off the declaration.
-
-For C++ content such as examples:
-
-- Indent using 4 spaces.
-- Do not leave trailing white spaces at the end of lines, and no more than a
-  single newline at the end of a source file.
-- A definition blocks' initial brace should start on a newline, not trail off the declaration.
-- Prefer direct initialisation (`{}` over `=`) over assignment initialisation, especially for primitive types.
-- Prefer brace-based initialisation for invoking a types constructor.
-- Use spaces on either side of constructor arguments when using braces (eg. `int{ _ }`).
-- Use `auto` as variable introducer and declare type explicitly in the brace initialiser or on right-hand-side of the assignment.
-- Prefer trailing return types on functions over prefixed notation.
-- Prefer to separate functions declarations (eg. `constexpr auto`), signature, constant and reference qualifiers (classes), `noexcept` specification and return type on separate lines if function declaration gets too long. Indent the constant and references qualifiers, `noexcept` specification and return type if they are on a newline.
-
-```cxx
-constexpr auto
-really_long_function_signature(that_takes lots_of_arguments, with_really long_names, for_types and_arguments)
-    noexcept( noexcept(long_noexcept_specification) && noexcept(with_multiple_conditions) )
-    -> a_really_long_return_type<with_lots<of_nested>, template_type<parameters, and_metaprogramming>>
-{}
-```
-
-- Indent `requires` clauses and `requires` expressions.
-- `#include` should be sorted in alphabetical order.
-- Mostly use your own judgment and stick to the style of the existing and surrounding code.