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
|
# Contributing Guidelines
The following is a set of guidelines for contributing to unit-wasm. 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 [README](README.md).
## Ask a Question
Please open an [issue](https://github.com/nginx/unit-wasm/issues/new) on
GitHub with the label `question`. You can also ask a question on
[Slack](https://nginxcommunity.slack.com) 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-wasm/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-wasm/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
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.
## Git Style Guide
- 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")
|
