xref: /unit/CONTRIBUTING.md (revision 2095:8c0978d786bd)
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[Slack](https://nginxcommunity.slack.com) 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