Thank you for taking the time to contribute. Any and all contributions are always very much appreciated. However, to make sure the process of accepting patches goes for everyone (especially for the maintainer), you should try to follow these few simple guidelines when you contribute:
-
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
-
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 branchbugfix/xxx
; for a feature, it should befeature/xxx
etc. Otherwise, just use your good 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 frommain
todev
). Consistent naming of branches is appreciated since it makes the output ofgit branch
easier to understand with a single glance. -
Do your modifications on that branch.
-
Make sure your modifications did not break anything by building and verifying the output using:
mdbook serve --open
-
Commit your changes. Your commit message should start with a one line short description of the modifications, with the details and explanations of your modifications following in subsequent paragraphs or bullet points. If you address an issue, create a subtitle with the issues number and title followed by the changes involved in resolving the issue. Please limit your lines to about 78 characters in commit messages, since it makes the output easier to read in
git log
. Also, starting your commit message with a tag describing the nature of the commit is nice, since it makes the commit history easier to skim through. For commits that do not change any functionality (e.g. refactoring or fixing typos), the[NFC]
tag (No Functionality Change) can be used. Here's an example of an acceptable commit message:[TAG] Refactor the interface - Rename elem to contains - Rename subset to is_subset, and make is_subset applicable in infix notation Issue (#12) - Add an at `at_key` method: - Added the `at_key` method - operator[] is now bound to at_key instead of find
When applicable, please squash adjacent wip commits into a single logical commit. If your contribution has several logical commits, it's fine.
-
Push the changes to your fork (
git push origin <your_branch>
). -
Open a pull request against the package's
dev
branch (not againstmain
).
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.
Markdown uses the CommonMark style guide for the most part however, certain exceptions are allowed for customizing the style. It is a guide for a reason.
- Any code example should have a corresponding example link that is either a full file/project or a link to an external compiler (eg. Godbolt).
- Any free standing or example links that are related should be put in a bullet-list and separate unrelated links by a empty line.
- Reserve the use of quote blocks (lines beginning with
>
in Markdown) for side notes relating to content or examples
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.