| subsystem | maintainers |

| --- | --- |

| `lib/buffer` | @trevnorris |

| `lib/child_process` | @cjihrig, @bnoordhuis |

| `lib/cluster` | @cjihrig, @bnoordhuis |

| `lib/{crypto,tls,https}` | @nodejs/crypto |

| `lib/domains` | @misterdjules |

| `lib/{_}http{*}` | @indutny, @bnoordhuis, @mscdex, @nodejs/http |

| `lib/net` | @indutny, @bnoordhuis, @nodejs/streams |

| `lib/{_}stream{s|*}` | @nodejs/streams |

| `lib/repl` | @fishrock123 |

| `lib/timers` | @fishrock123, @misterdjules |

| `lib/zlib` | @indutny, @bnoordhuis |

| `src/async-wrap.*` | @trevnorris |

| `src/node_crypto.*` | @nodejs/crypto |

| `test/*` | @nodejs/testing |

| `tools/eslint`, `.eslintrc` | @silverwind, @trott |

| upgrading v8 | @bnoordhuis, @targos, @ofrobots |

| upgrading npm | @thealphanerd, @fishrock123 |

When things need extra attention, are controversial, or `semver-major`: @nodejs/ctc

* `feature request` - Any issue that requests a new feature (usually not PRs)

* `good first contribution` - Issues suitable for newcomers to process

* `semver-{minor,major}`

* be conservative – that is, if a change has the remote *chance* of breaking something, go for semver-major

* when adding a semver label, add a comment explaining why you're adding it

* prefer to make the originating user update the code, since they have it fresh in mind

* first, reattempt with `git am -3` (3-way merge)`

* if `-3` still fails, and you need to get it merged:

* `git fetch upstream pull/N/head:pr-N && git checkout pr-N && git rebase master`