]>
Commit | Line | Data |
---|---|---|
add651ee FG |
1 | # Contributing to _h2_ # |
2 | ||
3 | :balloon: Thanks for your help improving the project! | |
4 | ||
5 | ## Getting Help ## | |
6 | ||
7 | If you have a question about the h2 library or have encountered problems using it, you may | |
4b012472 | 8 | [file an issue][issue] or ask a question on the [Tokio Gitter][gitter]. |
add651ee FG |
9 | |
10 | ## Submitting a Pull Request ## | |
11 | ||
12 | Do you have an improvement? | |
13 | ||
14 | 1. Submit an [issue][issue] describing your proposed change. | |
15 | 2. We will try to respond to your issue promptly. | |
16 | 3. Fork this repo, develop and test your code changes. See the project's [README](README.md) for further information about working in this repository. | |
17 | 4. Submit a pull request against this repo's `master` branch. | |
4b012472 | 18 | 5. Your branch may be merged once all configured checks pass, including: |
add651ee FG |
19 | - Code review has been completed. |
20 | - The branch has passed tests in CI. | |
21 | ||
22 | ## Committing ## | |
23 | ||
24 | When initially submitting a pull request, we prefer a single squashed commit. It | |
25 | is preferable to split up contributions into multiple pull requests if the | |
26 | changes are unrelated. All pull requests are squashed when merged, but | |
27 | squashing yourself gives you better control over the commit message. | |
28 | ||
29 | After the pull request is submitted, all changes should be done in separate | |
30 | commits. This makes reviewing the evolution of the pull request easier. We will | |
31 | squash all the changes into a single commit when we merge the pull request. | |
32 | ||
33 | ### Commit messages ### | |
34 | ||
35 | Finalized commit messages should be in the following format: | |
36 | ||
37 | ``` | |
38 | Subject | |
39 | ||
40 | Problem | |
41 | ||
42 | Solution | |
43 | ||
44 | Validation | |
45 | ``` | |
46 | ||
47 | #### Subject #### | |
48 | ||
49 | - one line, <= 50 characters | |
50 | - describe what is done; not the result | |
51 | - use the active voice | |
52 | - capitalize first word and proper nouns | |
53 | - do not end in a period — this is a title/subject | |
54 | - reference the github issue by number | |
55 | ||
56 | ##### Examples ##### | |
57 | ||
58 | ``` | |
59 | bad: server disconnects should cause dst client disconnects. | |
60 | good: Propagate disconnects from source to destination | |
61 | ``` | |
62 | ||
63 | ``` | |
64 | bad: support tls servers | |
65 | good: Introduce support for server-side TLS (#347) | |
66 | ``` | |
67 | ||
68 | #### Problem #### | |
69 | ||
70 | Explain the context and why you're making that change. What is the problem | |
71 | you're trying to solve? In some cases there is not a problem and this can be | |
72 | thought of as being the motivation for your change. | |
73 | ||
74 | #### Solution #### | |
75 | ||
76 | Describe the modifications you've made. | |
77 | ||
78 | #### Validation #### | |
79 | ||
80 | Describe the testing you've done to validate your change. Performance-related | |
81 | changes should include before- and after- benchmark results. | |
82 | ||
83 | [issue]: https://github.com/hyperium/h2/issues/new | |
84 | [gitter]: https://gitter.im/tokio-rs/tokio |