|
| 1 | +# Contributing to Tech Report APIs |
| 2 | + |
| 3 | +## Where do I go from here? |
| 4 | + |
| 5 | +If you've noticed a bug or have a feature request, make sure to check our [issues](https://github.com/HTTPArchive/tech-report-apis/issues) if there's something similar to what you have in mind. If not, you can open a new issue and provide as much detail as possible about what you'd like to see or what problem you're experiencing. |
| 6 | + |
| 7 | +## Fork & create a branch |
| 8 | + |
| 9 | +If this is something you think you can fix, then fork the repository and create a branch with a descriptive name. |
| 10 | + |
| 11 | +A good branch name would be (where issue #325 is the ticket you're working on): |
| 12 | + |
| 13 | +```bash |
| 14 | +git checkout -b feature/325-add-japanese-localisation |
| 15 | +``` |
| 16 | + |
| 17 | +## Implement your fix or feature |
| 18 | + |
| 19 | +At this point, you're ready to make your changes! Feel free to ask for help; everyone is a beginner at first. |
| 20 | + |
| 21 | +## Write a good commit message |
| 22 | + |
| 23 | +A good commit message serves at least three important purposes: |
| 24 | + |
| 25 | +- To speed up the reviewing process. |
| 26 | +- To help us write a good release note. |
| 27 | +- To help the future maintainers of Project Name (it could be you!), say five years into the future, to find out why a particular change was made to the code or why a specific feature was added. |
| 28 | + |
| 29 | +Here's an example of a good commit message structure: |
| 30 | + |
| 31 | +```bash |
| 32 | +Short (50 chars or less) summary of changes |
| 33 | + |
| 34 | +More detailed explanatory text, if necessary. Wrap it to about 72 |
| 35 | +characters or so. In some contexts, the first line is treated as the |
| 36 | +subject of an email and the rest of the text as the body. The blank |
| 37 | +line separating the summary from the body is critical (unless you omit |
| 38 | +the body entirely); tools like rebase can get confused if you run the |
| 39 | +two together. |
| 40 | + |
| 41 | +Further paragraphs come after blank lines. |
| 42 | + |
| 43 | +- Bullet points are okay, too |
| 44 | + |
| 45 | +- Typically a hyphen or asterisk is used for the bullet, followed by a |
| 46 | + single space, with blank lines in between, but conventions vary here |
| 47 | + |
| 48 | +- Use a hanging indent |
| 49 | +``` |
| 50 | +
|
| 51 | +## Submit a pull request |
| 52 | +
|
| 53 | +Once you've pushed your branch to your fork, you're ready to submit a pull request. We recommend opening a pull request early, and marking it as "Work in Progress" (prefix the title with `WIP:`), so that you can receive feedback early. |
| 54 | +
|
| 55 | +## Keeping your Pull Request updated |
| 56 | +
|
| 57 | +If a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed, and that you need to update your branch so it's easier to merge. |
| 58 | +
|
| 59 | +To update your pull request, follow these steps: |
| 60 | +
|
| 61 | +1. `git fetch origin` |
| 62 | +2. `git rebase origin/main` |
| 63 | +3. `git push --force-with-lease origin <your-branch>` |
| 64 | +
|
| 65 | +Thank you for your contributions! |
0 commit comments