|
1 |
| - |
2 | 1 | ## Contribution Guidelines
|
3 | 2 |
|
4 | 3 | 👉 Please start by reading our guidelines here: https://kleros.gitbook.io/docs/contribution-guidelines/overview
|
|
7 | 6 |
|
8 | 7 | You should usually open an issue in the following situations:
|
9 | 8 |
|
10 |
| -* Report an error you can’t solve yourself |
11 |
| -* Discuss a high-level topic or idea (for example, community, vision or policies) |
12 |
| -* Propose a new feature or other project idea |
| 9 | +- Report an error you can’t solve yourself |
| 10 | +- Discuss a high-level topic or idea (for example, community, vision or policies) |
| 11 | +- Propose a new feature or other project idea |
13 | 12 |
|
14 | 13 | ### Tips for communicating on issues:
|
15 | 14 |
|
16 |
| -* **If you see an open issue that you want to tackle,** comment on the issue to let people know you’re on it. That way, people are less likely to duplicate your work. |
17 |
| -* **If an issue was opened a while ago,** it’s possible that it’s being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work. |
18 |
| -* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project. |
| 15 | +- **If you see an open issue that you want to tackle,** comment on the issue to let people know you’re on it. That way, people are less likely to duplicate your work. |
| 16 | +- **If an issue was opened a while ago,** it’s possible that it’s being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work. |
| 17 | +- **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project. |
19 | 18 |
|
20 | 19 | ## Opening a pull request
|
21 | 20 |
|
22 | 21 | You should usually open a pull request in the following situations:
|
23 | 22 |
|
24 |
| -* Submit trivial fixes (for example, a typo, a broken link or an obvious error). |
25 |
| -* Start work on a contribution that was already asked for, or that you’ve already discussed, in an issue. |
| 23 | +- Submit trivial fixes (for example, a typo, a broken link or an obvious error). |
| 24 | +- Start work on a contribution that was already asked for, or that you’ve already discussed, in an issue. |
26 | 25 |
|
27 |
| -A pull request doesn’t have to represent finished work. It’s usually better to open a *draft* pull request early on, so others can watch or give feedback on your progress. Just mark it as a “WIP” (Work in Progress) in the subject line. You can always add more commits later. |
| 26 | +A pull request doesn’t have to represent finished work. It’s usually better to open a _draft_ pull request early on, so others can watch or give feedback on your progress. Just mark it as a “WIP” (Work in Progress) in the subject line. You can always add more commits later. |
28 | 27 |
|
29 | 28 | As a contributor who is not an organization member, here’s how to submit a pull request:
|
30 | 29 |
|
31 |
| -* **Fork the repository** and clone it locally. Connect your local to the original repository by adding it as a remote. Pull in changes from this repository often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. |
32 |
| -* **Create a branch** for your edits. |
33 |
| -* **Reference any relevant issues** or supporting documentation in your PR (for example, “Closes #37.”) |
34 |
| -* **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request. |
35 |
| -* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don’t break the existing project. |
36 |
| -* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future. |
| 30 | +- **Fork the repository** and clone it locally. Connect your local to the original repository by adding it as a remote. Pull in changes from this repository often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. |
| 31 | +- **Create a branch** for your edits. |
| 32 | +- **Reference any relevant issues** or supporting documentation in your PR (for example, “Closes #37.”) |
| 33 | +- **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request. |
| 34 | +- **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don’t break the existing project. |
| 35 | +- **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future. |
37 | 36 |
|
38 | 37 | If you are an organization member, a branch can be created directly in this repository, there is no need to fork it.
|
0 commit comments