The following is a set of guidelines for contributing to unit-wasm. We do appreciate that you are considering contributing!
Check out the README.
Please open an issue on
GitHub with the label question. You can also ask a question on
Slack or the NGINX Unit mailing list,
[email protected] (subscribe
here).
Ensure the bug was not already reported by searching on GitHub under Issues.
If the bug is a potential security vulnerability, please report using our security policy.
To report a non-security bug, open an
issue on GitHub with the
label bug. Be sure to include a title and clear description, as much
relevant information as possible, and a code sample or an executable test
case showing the expected behavior that doesn't occur.
To suggest an enhancement, open an
issue on GitHub with the
label enhancement. Please do this before implementing a new feature to
discuss the feature first.
Clone the repo, create a branch, and submit a PR when your changes are tested and ready for review. Again, if you'd like to implement a new feature, please consider creating a feature request issue first to start a discussion about the feature.
-
Split your work into multiple commits is necessary. Each commit should make one logical change. I.e don't mix code re-formatting with a fix in the same commit.
-
Subject lines should be short (around 50 characters, not a hard rule) and concisely describe the change.
-
The commit message body should be limited to 72 character lines.
-
You can use subject line prefixes for commits that affect a specific portion of the code; examples include "libunit-wasm:" and "rust-bindings:".
-
Reference issues and PRs at the end of the commit messages, e.g if the commit remedies a GitHub issue add a tag like
Closes: https://github.com/nginx/unit-wasm/issues/NNN
If the commit fixes an issue introduced in a previous commit use the "Fixes" tag to reference it, e.g
Fixes: abbrev commit id ("Commit subject line")