1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
|
# Contributing Guidelines
The following is a set of guidelines for contributing to NGINX Unit. We do
appreciate that you are considering contributing!
## Table Of Contents
- [Getting Started](#getting-started)
- [Ask a Question](#ask-a-question)
- [Contributing](#contributing)
- [Git Style Guide](#git-style-guide)
## 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.
## 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
[here](https://mailman.nginx.org/mailman3/lists/unit.nginx.org/)).
## Contributing
### Report a Bug
Ensure the bug was not already reported by searching on GitHub under
[Issues](https://github.com/nginx/unit/issues).
If the bug is a potential security vulnerability, please report using our
[security policy](https://unit.nginx.org/troubleshooting/#getting-support).
To report a non-security bug, open an
[issue](https://github.com/nginx/unit/issues/new) 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.
### Suggest an Enhancement
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.
### 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.
## Git Style Guide
- 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.
Ideally you should rebase locally and force push new commits up.
- 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 `.`
- Try to limit the subject line to around 50 characters, but try not to
exceed 72.
- Wrap the body of the commit message after 72 characters.
- 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:"
- 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.
|
