@@ -45,21 +45,21 @@ and built upon.
45
45
The rules for the master branch are less strict; consult the
46
46
[ stability index] ( ./doc/api/documentation.markdown#stability-index ) for details.
47
47
48
- In a nutshell, modules are at varying levels of API stability. Bug fixes are
48
+ In a nutshell, modules are at varying levels of API stability. Bug fixes are
49
49
always welcome but API or behavioral changes to modules at stability level 3
50
50
(Locked) are off-limits.
51
51
52
52
#### Dependencies
53
53
54
54
Node.js has several bundled dependencies in the * deps/* and the * tools/*
55
- directories that are not part of the project proper. Any changes to files
55
+ directories that are not part of the project proper. Any changes to files
56
56
in those directories or its subdirectories should be sent to their respective
57
- projects. Do not send your patch to us, we cannot accept it.
57
+ projects. Do not send your patch to us, we cannot accept it.
58
58
59
59
In case of doubt, open an issue in the
60
60
[ issue tracker] ( https://github.com/nodejs/node/issues/ ) or contact one of the
61
61
[ project Collaborators] ( https://github.com/nodejs/node/#current-project-team-members ) .
62
- ([ IRC] ( http://webchat.freenode.net/?channels=io.js ) is often the best medium.) Especially do so if you plan to work on something big. Nothing is more
62
+ ([ IRC] ( http://webchat.freenode.net/?channels=io.js ) is often the best medium.) Especially do so if you plan to work on something big. Nothing is more
63
63
frustrating than seeing your hard work go to waste because your vision
64
64
does not align with the project team.
65
65
@@ -81,8 +81,8 @@ $ git config --global user.name "J. Random User"
81
81
$ git config --global user.email "[email protected] "
82
82
```
83
83
84
- Writing good commit logs is important. A commit log should describe what
85
- changed and why. Follow these guidelines when writing one:
84
+ Writing good commit logs is important. A commit log should describe what
85
+ changed and why. Follow these guidelines when writing one:
86
86
87
87
1 . The first line should be 50 characters or less and contain a short
88
88
description of the change prefixed with the name of the changed
@@ -124,15 +124,15 @@ $ git rebase upstream/master
124
124
125
125
### Step 5: Test
126
126
127
- Bug fixes and features ** should come with tests** . Add your tests in the
128
- test/parallel/ directory. Look at other tests to see how they should be
127
+ Bug fixes and features ** should come with tests** . Add your tests in the
128
+ test/parallel/ directory. Look at other tests to see how they should be
129
129
structured (license boilerplate, common includes, etc.).
130
130
131
131
``` text
132
132
$ ./configure && make -j8 test
133
133
```
134
134
135
- Make sure the linter is happy and that all tests pass. Please, do not submit
135
+ Make sure the linter is happy and that all tests pass. Please, do not submit
136
136
patches that fail either check.
137
137
138
138
If you are updating tests and just want to run a single test to check it, you
@@ -160,9 +160,9 @@ $ git push origin my-feature-branch
160
160
Go to https://github.com/yourusername/node and select your feature branch.
161
161
Click the 'Pull Request' button and fill out the form.
162
162
163
- Pull requests are usually reviewed within a few days. If there are comments
163
+ Pull requests are usually reviewed within a few days. If there are comments
164
164
to address, apply your changes in a separate commit and push that to your
165
- feature branch. Post a comment in the pull request afterwards; GitHub does
165
+ feature branch. Post a comment in the pull request afterwards; GitHub does
166
166
not send out notifications when you add commits.
167
167
168
168
@@ -201,7 +201,7 @@ CoC](http://www.rust-lang.org/conduct.html).
201
201
* Please keep unstructured critique to a minimum. If you have solid
202
202
ideas you want to experiment with, make a fork and see how it works.
203
203
* We will exclude you from interaction if you insult, demean or harass
204
- anyone. That is not welcome behavior. We interpret the term
204
+ anyone. That is not welcome behavior. We interpret the term
205
205
"harassment" as including the definition in the [ Citizen Code of
206
206
Conduct] ( http://citizencodeofconduct.org/ ) ; if you have any lack of
207
207
clarity about what might be included in that concept, please read
@@ -211,11 +211,11 @@ CoC](http://www.rust-lang.org/conduct.html).
211
211
you feel you have been or are being harassed or made uncomfortable
212
212
by a community member, please contact one of the channel ops or any
213
213
of the TC members immediately with a capture (log, photo, email) of
214
- the harassment if possible. Whether you're a regular contributor or
214
+ the harassment if possible. Whether you're a regular contributor or
215
215
a newcomer, we care about making this community a safe place for you
216
216
and we've got your back.
217
217
* Likewise any spamming, trolling, flaming, baiting or other
218
218
attention-stealing behavior is not welcome.
219
219
* Avoid the use of personal pronouns in code comments or
220
220
documentation. There is no need to address persons when explaining
221
- code (e.g. "When the developer")
221
+ code (e.g. "When the developer").
0 commit comments