Skip to content

Commit d2c945e

Browse files
committed
docs(contrib): add contributing guide for submitting pull requests
1 parent 311ba2b commit d2c945e

File tree

2 files changed

+51
-1
lines changed

2 files changed

+51
-1
lines changed

CONTRIBUTING.md

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,7 @@ You want to contribute? You're awesome! Don't know where to start? Check the [li
55
[easy tag]: https://github.com/hyperium/hyper/issues?q=label%3AE-easy+is%3Aopen
66

77

8-
## Pull Requests
8+
## [Pull Requests](./docs/PULL_REQUESTS.md)
99

10+
- [Submitting a Pull Request](./docs/PULL_REQUESTS.md#submitting-a-pull-request)
1011
- [Commit Guidelines](./docs/COMMITS.md)

docs/PULL_REQUESTS.md

Lines changed: 49 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,49 @@
1+
# Pull Requests
2+
3+
Pull requests are the way to submit changes to the hyper repository.
4+
5+
## Submitting a Pull Request
6+
7+
In most cases, it a good idea to discuss a potential change in an
8+
[issue](ISSUES.md). This will allow other contributors to provide guidance and
9+
feedback _before_ significant code work is done, and can increase the
10+
likelihood of getting the pull request merged.
11+
12+
### Tests
13+
14+
If the change being proposed alters code (as opposed to only documentation for
15+
example), it is either adding new functionality to hyper or it is fixing
16+
existing, broken functionality. In both of these cases, the pull request should
17+
include one or more tests to ensure that hyper does not regress in the future.
18+
19+
### Commits
20+
21+
Once code, tests, and documentation have been written, a commit needs to be
22+
made. Following the [commit guidelines](COMMITS.md) will help with the review
23+
process by making your change easier to understand, and makes it easier for
24+
hyper to produce a valuable changelog with each release.
25+
26+
However, if your message doesn't perfectly match the guidelines, **do not
27+
worry!** The person that eventually merges can easily fixup the message at that
28+
time.
29+
30+
### Opening the Pull Request
31+
32+
From within GitHub, open a new pull request from your personal branch.
33+
34+
Once opened, pull requests are usually reviewed within a few days.
35+
36+
### Discuss and Update
37+
38+
You will probably get feedback or requests for changes to your Pull Request.
39+
This is a big part of the submission process so don't be discouraged! Some
40+
contributors may sign off on the Pull Request right away, others may have more
41+
detailed comments or feedback. This is a necessary part of the process in order
42+
to evaluate whether the changes are correct and necessary.
43+
44+
Any community member can review a PR and you might get conflicting feedback.
45+
Keep an eye out for comments from code owners to provide guidance on
46+
conflicting feedback.
47+
48+
You don't need to close the PR and create a new one to address feedback. You
49+
may simply push new commits to the existing branch.

0 commit comments

Comments
 (0)