Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: copy-edit COLLABORATOR_GUIDE.md #17922

Closed
wants to merge 3 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 19 additions & 20 deletions COLLABORATOR_GUIDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@

* [Issues and Pull Requests](#issues-and-pull-requests)
- [Managing Issues and Pull Requests](#managing-issues-and-pull-requests)
- [Welcoming First-Time Contributiors](#welcoming-first-time-contributiors)
- [Welcoming First-Time Contributors](#welcoming-first-time-contributors)
- [Closing Issues and Pull Requests](#closing-issues-and-pull-requests)
* [Accepting Modifications](#accepting-modifications)
- [Code Reviews and Consensus Seeking](#code-reviews-and-consensus-seeking)
Expand Down Expand Up @@ -33,7 +33,7 @@
- [How is an LTS release cut?](#how-is-an-lts-release-cut)

This document contains information for Collaborators of the Node.js
project regarding maintaining the code, documentation, and issues.
project regarding managing the project's code, documentation, and issue tracker.

Collaborators should be familiar with the guidelines for new
contributors in [CONTRIBUTING.md](./CONTRIBUTING.md) and also
Expand All @@ -52,11 +52,11 @@ may also notify other qualified parties for more input on an issue
or a pull request.
[See "Who to CC in issues"](./doc/onboarding-extras.md#who-to-cc-in-issues)

### Welcoming First-Time Contributiors
### Welcoming First-Time Contributors

Courtesy should always be shown to individuals submitting issues and pull
requests to the Node.js project. Be welcoming to first-time contributors,
identified by the GitHub ![badge](./doc/first_timer_badge.png) badge.
identified by the GitHub ![First-time contributor](./doc/first_timer_badge.png) badge.

For first-time contributors, check if the commit author is the same as the
pull request author, and ask if they have configured their git
Expand Down Expand Up @@ -201,11 +201,10 @@ Node.js API are internal:
- Any native C/C++ APIs/ABIs exported by the Node.js `*.h` header files that
are hidden behind the `NODE_WANT_INTERNALS` flag are internal.

Exception to each of these points can be made if use or behavior of a given
internal API can be demonstrated to be sufficiently relied upon by the Node.js
ecosystem such that any changes would cause too much breakage. The threshold
for what qualifies as too much breakage is to be decided on a case-by-case
basis by the TSC.
Exceptions can be made if use or behavior of a given internal API can be
demonstrated to be sufficiently relied upon by the Node.js ecosystem such that
any changes would cause too much breakage. The threshold for what qualifies as
too much breakage is to be decided on a case-by-case basis by the TSC.

If it is determined that a currently undocumented object, property, method,
argument, or event *should* be documented, then a pull request adding the
Expand Down Expand Up @@ -244,14 +243,14 @@ properties to an options argument) are semver-minor changes.

#### Breaking Changes and Deprecations

With a few notable exceptions outlined below, when backwards incompatible
changes to a *Public* API are necessary, the existing API *must* be deprecated
*first* and the new API either introduced in parallel or added after the next
major Node.js version following the deprecation as a replacement for the
deprecated API. In other words, as a general rule, existing *Public* APIs
*must not* change (in a backwards incompatible way) without a deprecation.
With a few exceptions outlined below, when backward-incompatible changes to a
*Public* API are necessary, the existing API *must* be deprecated *first* and
the new API either introduced in parallel or added after the next major Node.js
version following the deprecation as a replacement for the deprecated API. In
other words, as a general rule, existing *Public* APIs *must not* change (in a
backward-incompatible way) without a deprecation.

Exception to this rule is given in the following cases:
Exceptions to this rule may be made in the following cases:

* Adding or removing errors thrown or reported by a Public API;
* Changing error messages;
Expand Down Expand Up @@ -352,7 +351,7 @@ recommended but not required.
### Deprecations

_Deprecation_ refers to the identification of Public APIs that should no longer
be used and that may be removed or modified in non-backwards compatible ways in
be used and that may be removed or modified in backward-incompatible ways in
a future major release of Node.js. Deprecation may be used with internal APIs if
there is expected impact on the user community.

Expand Down Expand Up @@ -492,7 +491,7 @@ Check and re-review the changes:
$ git diff upstream/master
```

Check number of commits and commit messages:
Check the number of commits and commit messages:

```text
$ git log upstream/master...master
Expand Down Expand Up @@ -653,7 +652,7 @@ commit final.
#### What is LTS?

Long Term Support (often referred to as *LTS*) guarantees application developers
a 30 month support cycle with specific versions of Node.js.
a 30-month support cycle with specific versions of Node.js.

You can find more information
[in the full release plan](https://github.com/nodejs/Release#release-plan).
Expand All @@ -666,7 +665,7 @@ certain performance improvements that can be demonstrated to not break existing
applications. Semver-minor changes are only permitted if required for bug fixes
and then only on a case-by-case basis with LTS WG and possibly Technical
Steering Committee (TSC) review. Semver-major changes are permitted only if
required for security related fixes.
required for security-related fixes.

Once a Current branch moves into Maintenance mode, only **critical** bugs,
**critical** security fixes, and documentation updates will be permitted.
Expand Down