| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
1 parent cbd358c commit efa19bd
1 file changed
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -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 "j.random.user@example.com" | |
| 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"). | ||
| Back | FazBrowse Home | New Git URL |
0 commit comments