1# Contributing Guidelines 2 3The following is a set of guidelines for contributing to NGINX Unit. We do 4appreciate that you are considering contributing! 5 6## Table Of Contents 7 8- [Getting Started](#getting-started) 9- [Ask a Question](#ask-a-question) 10- [Contributing](#contributing) 11- [Git Style Guide](#git-style-guide) 12 13 14## Getting Started 15 16Check out the [Quick Installation](README.md#quick-installation) and 17[Howto](https://unit.nginx.org/howto/) guides to get NGINX Unit up and running. 18 19 20## Ask a Question 21 22Please open an [issue](https://github.com/nginx/unit/issues/new) on GitHub with 23the label `question`. You can also ask a question on 24[GitHub Discussions](https://github.com/nginx/unit/discussions) or the NGINX Unit mailing list, 25unit@nginx.org (subscribe 26[here](https://mailman.nginx.org/mailman3/lists/unit.nginx.org/)). 27 28 29## Contributing 30 31### Report a Bug 32 33Ensure the bug was not already reported by searching on GitHub under 34[Issues](https://github.com/nginx/unit/issues). 35 36If the bug is a potential security vulnerability, please report using our 37[security policy](https://unit.nginx.org/troubleshooting/#getting-support). 38 39To report a non-security bug, open an 40[issue](https://github.com/nginx/unit/issues/new) on GitHub with the label 41`bug`. Be sure to include a title and clear description, as much relevant 42information as possible, and a code sample or an executable test case showing 43the expected behavior that doesn't occur. 44 45 46### Suggest an Enhancement 47 48To suggest an enhancement, open an 49[issue](https://github.com/nginx/unit/issues/new) on GitHub with the label 50`enhancement`. Please do this before implementing a new feature to discuss the 51feature first. 52 53 54### Open a Pull Request 55 56Before submitting a PR, please read the NGINX Unit code guidelines to know more 57about coding conventions and benchmarks. Fork the repo, create a branch, and 58submit a PR when your changes are tested and ready for review. Again, if you'd 59like to implement a new feature, please consider creating a feature request 60issue first to start a discussion about the feature. 61 62 63## Git Style Guide 64 65- Keep a clean, concise and meaningful `git commit` history on your branch, 66 rebasing locally and squashing before submitting a PR 67 68- For any user-visible changes, updates, and bugfixes, add a note to 69 `docs/changes.xml` under the section for the upcoming release, using `<change 70 type="feature">` for new functionality, `<change type="change">` for changed 71 behavior, and `<change type="bugfix">` for bug fixes. 72 73- In the subject line, use the past tense ("Added feature", not "Add feature"); 74 also, use past tense to describe past scenarios, and present tense for 75 current behavior 76 77- Limit the subject line to 67 characters, and the rest of the commit message 78 to 80 characters 79 80- Use subject line prefixes for commits that affect a specific portion of the 81 code; examples include "Tests:", "Packages:", or "Docker:", and also 82 individual languages such as "Java:" or "Ruby:" 83 84- Reference issues and PRs liberally after the subject line; if the commit 85 remedies a GitHub issue, [name 86 it](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) 87 accordingly 88 89- Don't rely on command-line commit messages with `-m`; use the editor instead 90 91