Skip to content

Commit

Permalink
doc: improve readability of COLLABORATOR_GUIDE.md
Browse files Browse the repository at this point in the history
* convert run-on sentence to a bulleted list
* standardize capitalization in "Collaborators"

PR-URL: #17519
Reviewed-By: Jon Moss <me@jonathanmoss.me>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
  • Loading branch information
Trott authored and MylesBorins committed Dec 12, 2017
1 parent e812c9c commit 6039319
Showing 1 changed file with 11 additions and 10 deletions.
21 changes: 11 additions & 10 deletions COLLABORATOR_GUIDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -130,7 +130,7 @@ can be fast-tracked and may be landed after a shorter delay:
* Changes that fix regressions.

When a pull request is deemed suitable to be fast-tracked, label it with
`fast-track`. The pull request can be landed once 2 or more collaborators
`fast-track`. The pull request can be landed once 2 or more Collaborators
approve both the pull request and the fast-tracking request, and the necessary
CI testing is done.

Expand Down Expand Up @@ -225,15 +225,16 @@ on how to handle those types of changes.
### Breaking Changes

Backwards-incompatible changes may land on the master branch at any time after
sufficient review by collaborators and approval of at least two TSC members.

Examples of breaking changes include, but are not necessarily limited to,
removal or redefinition of existing API arguments, changing return values
(except when return values do not currently exist), removing or modifying
existing properties on an options argument, adding or removing errors,
changing error messages in any way, altering expected timing of an event (e.g.
moving from sync to async responses or vice versa), and changing the
non-internal side effects of using a particular API.
sufficient review by Collaborators and approval of at least two TSC members.

Examples of breaking changes include:

* removal or redefinition of existing API arguments
* changing return values
* removing or modifying existing properties on an options argument
* adding or removing errors
* altering expected timing of an event
* changing the side effects of using a particular API

Purely additive changes (e.g. adding new events to `EventEmitter`
implementations, adding new arguments to a method in a way that allows
Expand Down

0 comments on commit 6039319

Please sign in to comment.