You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+3-2Lines changed: 3 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,8 @@ You should usually open an issue in the following situations:
6
6
* Report an error you can’t solve yourself
7
7
* Discuss a high-level topic or idea (for example, community, vision or policies)
8
8
* Propose a new feature or other project idea
9
-
* Tips for communicating on issues:
9
+
10
+
**Tips for communicating on issues:**
10
11
11
12
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.
12
13
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.
@@ -23,7 +24,7 @@ If the project is on GitHub, here’s how to submit a pull request:
23
24
24
25
* Fork the repository and clone it locally. Connect your local to the original “upstream” repository by adding it as a remote. Pull in changes from “upstream” often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions here.)
25
26
* Create a branch for your edits.
26
-
* Reference any relevant issues or supporting documentation in your PR (for example, “Closes #37.”)
27
+
* Reference any relevant issues or supporting documentation in your PR. (for example, “Closes #37.”)
27
28
* 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.
28
29
* 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.
29
30
* 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.
0 commit comments