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: CONTRIBUTING.md
+35-36Lines changed: 35 additions & 36 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,9 +14,9 @@ We **love** pull requests! Before [forking the repo](https://help.github.com/en/
14
14
15
15
For most contributions, after your first pull request is accepted and merged, you will be [invited to the project](https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/inviting-collaborators-to-a-personal-repository) and given **push access**. :tada:
16
16
17
-
*Note: All contributions will be licensed under the project's license.*
17
+
_Note: All contributions will be licensed under the project's license._
18
18
19
-
-**Smaller is better.** Submit **one** pull request per bug fix or feature. A pull request should contain isolated changes pertaining to a single bug fix or feature implementation. **Do not** refactor or reformat code that is unrelated to your change. It is better to **submit many small pull requests** rather than a single large one. Enormous pull requests will take enormous amounts of time to review, or may be rejected altogether.
19
+
-**Smaller is better.** Submit **one** pull request per bug fix or feature. A pull request should contain isolated changes pertaining to a single bug fix or feature implementation. **Do not** refactor or reformat code that is unrelated to your change. It is better to **submit many small pull requests** rather than a single large one. Enormous pull requests will take enormous amounts of time to review, or may be rejected altogether.
20
20
21
21
-**Coordinate bigger changes.** For large and non-trivial changes, open an issue to discuss a strategy with the maintainers. Otherwise, you risk doing a lot of work for nothing!
22
22
@@ -30,9 +30,9 @@ For most contributions, after your first pull request is accepted and merged, yo
30
30
31
31
-**[Resolve any merge conflicts](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github)** that occur.
32
32
33
-
-**Keep PR in Draft** until ready for review. When PR ready for review assign PR to ourself and assing at least one reviewer
33
+
-**Keep PR in Draft** until ready for review. When it is ready, assign the PR to yourself and request at least one reviewer.
34
34
35
-
-**Promptly address any CI failures**. If your pull request fails to build or pass tests, please push another commit to fix it.
35
+
-**Promptly address any CI failures**. If your pull request fails to build or pass tests, please push another commit to fix it.
36
36
37
37
- When writing comments, use properly constructed sentences, including punctuation.
38
38
@@ -44,32 +44,32 @@ Please [write a great commit message](https://chris.beams.io/posts/git-commit/).
44
44
45
45
1. Separate subject from body with a blank line
46
46
1. Limit the subject line to 50 characters
47
-
1. Capitalize the subject line
48
-
1. Add [Draft] prefix for PR not ready for review
47
+
1. Use sentence case (capitalize the first word)
49
48
1. Do not end the subject line with a period
50
49
1. Use the imperative mood in the subject line (example: "Fix networking issue")
51
50
1. Wrap the body at about 72 characters
52
-
1. Use the body to explain **why**, *not what and how* (the code shows that!)
53
-
1. If applicable, prefix the title with the relevant component name. (examples: "[Docs] Fix typo", "[Profile] Fix missing avatar")
51
+
1. Use the body to explain **why**, _not what and how_ (the code shows that!)
52
+
1. Do not use semantic prefixes or tags (examples: `fix:`, `feat:`, `[Docs]`)
53
+
1. Keep PR state out of commit messages; use GitHub Draft PRs instead
54
54
55
55
```
56
-
[TAG] Short summary of changes in 50 chars or less
56
+
Short summary of changes in 50 chars or less
57
57
58
-
Add a more detailed explanation here, if necessary. Possibly give
59
-
some background about the issue being fixed, etc. The body of the
60
-
commit message can be several paragraphs. Further paragraphs come
58
+
Add a more detailed explanation here, if necessary. Possibly give
59
+
some background about the issue being fixed, etc. The body of the
60
+
commit message can be several paragraphs. Further paragraphs come
61
61
after blank lines and please do proper word-wrap.
62
62
63
-
Wrap it to about 72 characters or so. In some contexts,
64
-
the first line is treated as the subject of the commit and the
65
-
rest of the text as the body. The blank line separating the summary
66
-
from the body is critical (unless you omit the body entirely);
67
-
various tools like `log`, `shortlog` and `rebase` can get confused
63
+
Wrap it to about 72 characters or so. In some contexts,
64
+
the first line is treated as the subject of the commit and the
65
+
rest of the text as the body. The blank line separating the summary
66
+
from the body is critical (unless you omit the body entirely);
67
+
various tools like `log`, `shortlog` and `rebase` can get confused
68
68
if you run the two together.
69
69
70
70
Explain the problem that this commit is solving. Focus on why you
71
-
are making this change as opposed to how or what. The code explains
72
-
how or what. Reviewers and your future self can read the patch,
71
+
are making this change as opposed to how or what. The code explains
72
+
how or what. Reviewers and your future self can read the patch,
73
73
but might not understand why a particular solution was implemented.
74
74
Are there side effects or other unintuitive consequences of this
75
75
change? Here's the place to explain them.
@@ -93,33 +93,32 @@ See also: #456, #789
93
93
94
94
-**Always do your best.** No one writes bugs on purpose. Do your best, and learn from your mistakes.
95
95
96
-
- Kindly note any violations to the guidelines specified in this document.
96
+
- Kindly note any violations to the guidelines specified in this document.
97
97
98
-
-**Use CREG (Code Review Emoji Guide)**to give the reviewee added context and clarity to follow up on code review.
98
+
-**Use CREG (Code Review Emoji Guide)** to give the reviewee added context and clarity to follow up on code review.
| 😃👍💯 |`:smiley:``:+1:``:100:`| I like this... <br /><br /> ...and I want the author to know it! This is a way to highlight positive parts of a code review. |
105
-
| 🔧 |`:wrench:`| I think this needs to be changed. <br /><br />This is a concern or suggested change/refactor that I feel is worth addressing. |
106
-
| ❓ |`:question:`| I have a question. <br /><br /> This should be a fully formed question with sufficient information and context that requires a response. |
107
-
| 🤔💭 |`:thinking:``:thought_balloon:`| Let me think out loud here for a minute. <br /><br /> I might express concern, suggest an alternative solution, or walk through the code in my own words to make sure I understand. |
108
-
| 🌱 |`:seedling:`| Planting a seed for future. <br /><br /> An observation or suggestion that is not a change request, but may have larger implications. Generally something to keep in mind for the future. |
109
-
| 📝 |`:memo:`| This is an explanatory note, fun fact, or relevant commentary that does not require any action. |
110
-
| ⛏ |`:pick:`| This is a nitpick. <br /><br /> This does not require any changes and is often better left unsaid. This may include stylistic, formatting, or organization suggestions and should likely be prevented/enforced by linting if they really matter |
111
-
| ♻️ |`:recycle:`| Suggestion for refactoring. <br /><br /> Should include enough context to be actionable and not be considered a nitpick. |
112
-
| 🏕 |`:camping:`| Here is an opportunity, not directly related to your changes, for us to leave the campground [code] cleaner than we found it. |
113
-
| 📌 |`:pushpin:`| This is a concern that is _out of scope_ and should be staged appropriately for follow up. |
| 😃👍💯 |`:smiley:``:+1:``:100:`| I like this... <br /><br /> ...and I want the author to know it! This is a way to highlight positive parts of a code review. |
105
+
| 🔧 |`:wrench:`| I think this needs to be changed. <br /><br />This is a concern or suggested change/refactor that I feel is worth addressing. |
106
+
| ❓ |`:question:`| I have a question. <br /><br /> This should be a fully formed question with sufficient information and context that requires a response. |
107
+
| 🤔💭 |`:thinking:``:thought_balloon:`| Let me think out loud here for a minute. <br /><br /> I might express concern, suggest an alternative solution, or walk through the code in my own words to make sure I understand. |
108
+
| 🌱 |`:seedling:`| Planting a seed for future. <br /><br /> An observation or suggestion that is not a change request, but may have larger implications. Generally something to keep in mind for the future. |
109
+
| 📝 |`:memo:`| This is an explanatory note, fun fact, or relevant commentary that does not require any action. |
110
+
| ⛏ |`:pick:`| This is a nitpick. <br /><br /> This does not require any changes and is often better left unsaid. This may include stylistic, formatting, or organization suggestions and should likely be prevented/enforced by linting if they really matter |
111
+
| ♻️ |`:recycle:`| Suggestion for refactoring. <br /><br /> Should include enough context to be actionable and not be considered a nitpick. |
112
+
| 🏕 |`:camping:`| Here is an opportunity, not directly related to your changes, for us to leave the campground [code] cleaner than we found it. |
113
+
| 📌 |`:pushpin:`| This is a concern that is _out of scope_ and should be staged appropriately for follow up. |
115
114
116
115
## :nail_care: Coding Style
117
116
118
117
Consistency is the most important. Following the existing Rust style, formatting, and naming conventions of the file you are modifying and of the overall project. Failure to do so will result in a prolonged review process that has to focus on updating the superficial aspects of your code, rather than improving its functionality and performance.
119
118
120
-
Style and format will be enforced with a linter when PR is crated.
119
+
Style and format will be enforced with a linter when the PR is created.
0 commit comments