Updated CONTRIBUTING doc

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.