|
| 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