diff options
| author | Rich Trott <rtrott@gmail.com> | 2018-06-15 15:37:47 -0700 |
|---|---|---|
| committer | Rich Trott <rtrott@gmail.com> | 2018-06-16 07:54:30 -0700 |
| commit | dc10ddf03489e723d94abda953cc65ef680db9cb (patch) | |
| tree | 44c153bf24f61550442ebb4177d606202f045127 /doc/guides/contributing | |
| parent | 0b27cb4a7c91a3ae3269f93a536b1bba170abc14 (diff) | |
| download | android-node-v8-dc10ddf03489e723d94abda953cc65ef680db9cb.tar.gz android-node-v8-dc10ddf03489e723d94abda953cc65ef680db9cb.tar.bz2 android-node-v8-dc10ddf03489e723d94abda953cc65ef680db9cb.zip | |
doc: wrap pull-requests.md at 80 characters
PR-URL: https://github.com/nodejs/node/pull/21361
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Jon Moss <me@jonathanmoss.me>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Diffstat (limited to 'doc/guides/contributing')
| -rw-r--r-- | doc/guides/contributing/pull-requests.md | 7 |
1 files changed, 4 insertions, 3 deletions
diff --git a/doc/guides/contributing/pull-requests.md b/doc/guides/contributing/pull-requests.md index 0da7022d10..0ae30d5b77 100644 --- a/doc/guides/contributing/pull-requests.md +++ b/doc/guides/contributing/pull-requests.md @@ -137,8 +137,8 @@ notes about [commit squashing](#commit-squashing)). A good commit message should describe what changed and why. 1. The first line should: - - contain a short description of the change (preferably 50 characters or less, - and no more than 72 characters) + - contain a short description of the change (preferably 50 characters or + less, and no more than 72 characters) - be entirely in lowercase with the exception of proper nouns, acronyms, and the words that refer to code, like function/variable names - be prefixed with the name of the changed subsystem and start with an @@ -456,7 +456,8 @@ Focus first on the most significant aspects of the change: 1. Does this change make sense for Node.js? 2. Does this change make Node.js better, even if only incrementally? 3. Are there clear bugs or larger scale issues that need attending to? -4. Is the commit message readable and correct? If it contains a breaking change is it clear enough? +4. Is the commit message readable and correct? If it contains a breaking change + is it clear enough? When changes are necessary, *request* them, do not *demand* them, and do not assume that the submitter already knows how to add a test or run a benchmark. |