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: docs/about/contributing/CONTRIBUTING.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -154,11 +154,11 @@ We welcome pull requests (PRs) from community members including (but not limited
154
154
155
155
We will ask that you sign a Contributor License Agreement before we accept any contributions into our repo.
156
156
157
-
Please keep PRs small and selfcontained. This allows code reviewers (see below) to focus and fully understand the PR. A good rule of thumb is less than 1000 lines changed. (One exception is a mechanistic refactor, like renaming, that is conceptually trivial but might have a large line count.)
157
+
Please keep PRs small and self-contained. This allows code reviewers (see below) to focus and fully understand the PR. A good rule of thumb is less than 1000 lines changed. (One exception is a mechanistic refactor, like renaming, that is conceptually trivial but might have a large line count.)
158
158
159
159
If your intended feature or refactor will be larger than this:
160
160
161
-
1. Open an issue explaining what you intend to build, how it will work, and that you are volunteering to do the development.
161
+
1. Open an issue explaining what you intend to build, how it will work, and that you are volunteering to do the development. Include `@coder/community-triage`in the body.
162
162
2. Give the maintainers a chance to respond. Changes to the visual, interaction, or software design are easier to adjust before you start laying down code.
163
163
3. Break your work up into a series of smaller PRs.
164
164
@@ -167,7 +167,7 @@ Stacking tools like [Graphite](https://www.graphite.dev) are useful for keeping
167
167
Each PR:
168
168
169
169
- Must individually build and pass all tests, including formatting and linting.
170
-
- Must not introduce regressions or back compatibility issues, even if a later PR would resolve the issue.
170
+
- Must not introduce regressions or backward-compatibility issues, even if a subsequent PRin your series would resolve the issue.
171
171
- Should be a conceptually coherent change set.
172
172
173
173
In practice, many of these smaller PRs will be invisible to end users, and that is ok. For example, you might introduce
0 commit comments