diff options
Diffstat (limited to 'CONTRIBUTING.md')
| -rw-r--r-- | CONTRIBUTING.md | 66 |
1 files changed, 35 insertions, 31 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 77343271..eeee56cb 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -14,15 +14,16 @@ appreciate that you are considering contributing! ## Getting Started Check out the [Quick Installation](README.md#quick-installation) and -[Howto](https://unit.nginx.org/howto/) guides to get NGINX Unit up and running. +[Howto](https://unit.nginx.org/howto/) guides to get NGINX Unit up and +running. ## Ask a Question -Please open an [issue](https://github.com/nginx/unit/issues/new) on GitHub with -the label `question`. You can also ask a question on -[GitHub Discussions](https://github.com/nginx/unit/discussions) or the NGINX Unit mailing list, -unit@nginx.org (subscribe +Please open an [issue](https://github.com/nginx/unit/issues/new) on GitHub +with the label `question`. You can also ask a question on +[GitHub Discussions](https://github.com/nginx/unit/discussions) or the NGINX +Unit mailing list, unit@nginx.org (subscribe [here](https://mailman.nginx.org/mailman3/lists/unit.nginx.org/)). @@ -47,44 +48,47 @@ the expected behavior that doesn't occur. To suggest an enhancement, open an [issue](https://github.com/nginx/unit/issues/new) on GitHub with the label -`enhancement`. Please do this before implementing a new feature to discuss the -feature first. +`enhancement`. Please do this before implementing a new feature to discuss +the feature first. ### Open a Pull Request -Before submitting a PR, please read the NGINX Unit code guidelines to know more -about coding conventions and benchmarks. Fork 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. +Before submitting a PR, please read the NGINX Unit code guidelines to know +more about coding conventions and benchmarks. Fork 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. ## Git Style Guide -- Keep a clean, concise and meaningful `git commit` history on your branch, - rebasing locally and squashing before submitting a PR +- Create atomic commits. A commit should do just one thing, i.e. you + shouldn't mix refactoring with functional code changes. Do the + refactoring in one or more commits first. -- For any user-visible changes, updates, and bugfixes, add a note to - `docs/changes.xml` under the section for the upcoming release, using `<change - type="feature">` for new functionality, `<change type="change">` for changed - behavior, and `<change type="bugfix">` for bug fixes. + Ideally you should rebase locally and force push new commits up. -- In the subject line, use the past tense ("Added feature", not "Add feature"); - also, use past tense to describe past scenarios, and present tense for - current behavior +- In the subject line, use the imperative mood. I.e. write the subject like + you're giving git a command, e.g. "Free memory before exiting". Do not + terminate the subject with a `.` -- Limit the subject line to 67 characters, and the rest of the commit message - to 80 characters +- Try to limit the subject line to around 50 characters, but try not to + exceed 72. -- Use subject line prefixes for commits that affect a specific portion of the - code; examples include "Tests:", "Packages:", or "Docker:", and also - individual languages such as "Java:" or "Ruby:" +- Wrap the body of the commit message after 72 characters. -- Reference issues and PRs liberally after the subject line; if the commit - remedies a GitHub issue, [name - it](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) - accordingly +- Use lowercase subject line prefixes for commits that affect a specific + portion of the code; examples include "tests:", "ci:", or "http:", and + also individual languages such as "python:" or "php:". If multiple areas + are affected you can specify multiple prefixes, e.g. "auto, perl:" -- Don't rely on command-line commit messages with `-m`; use the editor instead +- If the commit fixes an open issue then you can use the "Closes:" + tag/trailer to reference it and have GitHub automatically close it once + it's been merged. E.g.: + + `Closes: https://github.com/nginx/unit/issues/9999` + + That should go at the end of the commit message, separated by a blank line, + along with any other tags. |