Skip to content

Commit 0ddaea0

Browse files
committed
contribution.md file added
1 parent 8ea3b44 commit 0ddaea0

File tree

1 file changed

+65
-0
lines changed

1 file changed

+65
-0
lines changed

Diff for: CONTRIBUTING.md

+65
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
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

Comments
 (0)