lukechilds
/
node
mirror of https://github.com/lukechilds/node.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
Browse Source

meta: merge TSC and CTC back into a single body 

PR-URL: https://github.com/nodejs/node/pull/14973
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: Shigeki Ohtsu <ohtsu@ohtsu.org>
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
canary-base
James M Snell 7 years ago
parent
689a643198
commit
f3eb193a30
5 changed files with 82 additions and 126 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Unified View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 48
      COLLABORATOR_GUIDE.md
  2. 132
      GOVERNANCE.md
  3. 20
      README.md
  4. 6
      doc/onboarding.md
  5. 2
      src/node_revert.h

48
COLLABORATOR_GUIDE.md
View File

@ -8,7 +8,7 @@
- [Internal vs. Public API](#internal-vs-public-api) - [Internal vs. Public API](#internal-vs-public-api)
- [Breaking Changes](#breaking-changes) - [Breaking Changes](#breaking-changes)
- [Deprecations](#deprecations) - [Deprecations](#deprecations)
- [Involving the CTC](#involving-the-ctc) - [Involving the TSC](#involving-the-TSC)
* [Landing Pull Requests](#landing-pull-requests) * [Landing Pull Requests](#landing-pull-requests)
- [Technical HOWTO](#technical-howto) - [Technical HOWTO](#technical-howto)
- [I Just Made a Mistake](#i-just-made-a-mistake) - [I Just Made a Mistake](#i-just-made-a-mistake)
@ -30,7 +30,7 @@ pull requests to the Node.js project.
Collaborators should feel free to take full responsibility for Collaborators should feel free to take full responsibility for
managing issues and pull requests they feel qualified to handle, as managing issues and pull requests they feel qualified to handle, as
long as this is done while being mindful of these guidelines, the long as this is done while being mindful of these guidelines, the
opinions of other Collaborators and guidance of the CTC. opinions of other Collaborators and guidance of the TSC.
Collaborators may **close** any issue or pull request they believe is Collaborators may **close** any issue or pull request they believe is
not relevant for the future of the Node.js project. Where this is not relevant for the future of the Node.js project. Where this is
@ -46,7 +46,7 @@ necessary.
All modifications to the Node.js code and documentation should be All modifications to the Node.js code and documentation should be
performed via GitHub pull requests, including modifications by performed via GitHub pull requests, including modifications by
Collaborators and CTC members. Collaborators and TSC members.
All pull requests must be reviewed and accepted by a Collaborator with All pull requests must be reviewed and accepted by a Collaborator with
sufficient expertise who is able to take full responsibility for the sufficient expertise who is able to take full responsibility for the
@ -70,16 +70,16 @@ For non-breaking changes, if there is no disagreement amongst
Collaborators, a pull request may be landed given appropriate review. Collaborators, a pull request may be landed given appropriate review.
Where there is discussion amongst Collaborators, consensus should be Where there is discussion amongst Collaborators, consensus should be
sought if possible. The lack of consensus may indicate the need to sought if possible. The lack of consensus may indicate the need to
elevate discussion to the CTC for resolution (see below). elevate discussion to the TSC for resolution (see below).
Breaking changes (that is, pull requests that require an increase in Breaking changes (that is, pull requests that require an increase in
the major version number, known as `semver-major` changes) must be the major version number, known as `semver-major` changes) must be
elevated for review by the CTC. This does not necessarily mean that the elevated for review by the TSC. This does not necessarily mean that the
PR must be put onto the CTC meeting agenda. If multiple CTC members PR must be put onto the TSC meeting agenda. If multiple TSC members
approve (`LGTM`) the PR and no Collaborators oppose the PR, it can be approve (`LGTM`) the PR and no Collaborators oppose the PR, it can be
landed. Where there is disagreement among CTC members or objections landed. Where there is disagreement among TSC members or objections
from one or more Collaborators, `semver-major` pull requests should be from one or more Collaborators, `semver-major` pull requests should be
put on the CTC meeting agenda. put on the TSC meeting agenda.
All bugfixes require a test case which demonstrates the defect. The All bugfixes require a test case which demonstrates the defect. The
test should *fail* before the change, and *pass* after the change. test should *fail* before the change, and *pass* after the change.
@ -150,7 +150,7 @@ Exception to each of these points can be made if use or behavior of a given
internal API can be demonstrated to be sufficiently relied upon by the Node.js internal API can be demonstrated to be sufficiently relied upon by the Node.js
ecosystem such that any changes would cause too much breakage. The threshold ecosystem such that any changes would cause too much breakage. The threshold
for what qualifies as "too much breakage" is to be decided on a case-by-case for what qualifies as "too much breakage" is to be decided on a case-by-case
basis by the CTC. basis by the TSC.
If it is determined that a currently undocumented object, property, method, If it is determined that a currently undocumented object, property, method,
argument, or event *should* be documented, then a pull request adding the argument, or event *should* be documented, then a pull request adding the
@ -171,7 +171,7 @@ making and reviewing such changes. Before landing such commits, an effort
must be made to determine the potential impact of the change in the ecosystem must be made to determine the potential impact of the change in the ecosystem
by analyzing current use and by validating such changes through ecosystem by analyzing current use and by validating such changes through ecosystem
testing using the [Canary in the Goldmine](https://github.com/nodejs/citgm) testing using the [Canary in the Goldmine](https://github.com/nodejs/citgm)
tool. If a change cannot be made without ecosystem breakage, then CTC review is tool. If a change cannot be made without ecosystem breakage, then TSC review is
required before landing the change as anything less than semver-major. required before landing the change as anything less than semver-major.
If a determination is made that a particular internal API (for instance, an If a determination is made that a particular internal API (for instance, an
@ -183,7 +183,7 @@ breaking changes are made.
### Breaking Changes ### Breaking Changes
Backwards-incompatible changes may land on the master branch at any time after Backwards-incompatible changes may land on the master branch at any time after
sufficient review by collaborators and approval of at least two CTC members. sufficient review by collaborators and approval of at least two TSC members.
Examples of breaking changes include, but are not necessarily limited to, Examples of breaking changes include, but are not necessarily limited to,
removal or redefinition of existing API arguments, changing return values removal or redefinition of existing API arguments, changing return values
@ -209,7 +209,7 @@ Exception to this rule is given in the following cases:
Such changes *must* be handled as semver-major changes but MAY be landed Such changes *must* be handled as semver-major changes but MAY be landed
without a [Deprecation cycle](#deprecation-cycle). without a [Deprecation cycle](#deprecation-cycle).
From time-to-time, in particularly exceptional cases, the CTC may be asked to From time-to-time, in particularly exceptional cases, the TSC may be asked to
consider and approve additional exceptions to this rule. consider and approve additional exceptions to this rule.
Purely additive changes (e.g. adding new events to EventEmitter Purely additive changes (e.g. adding new events to EventEmitter
@ -244,7 +244,7 @@ Specifically:
* Resolving critical security issues. * Resolving critical security issues.
* Fixing a critical bug (e.g. fixing a memory leak) requires a breaking * Fixing a critical bug (e.g. fixing a memory leak) requires a breaking
change. change.
* There is CTC consensus that the change is required. * There is TSC consensus that the change is required.
* If a breaking commit does accidentally land in a Current or LTS branch, an * If a breaking commit does accidentally land in a Current or LTS branch, an
attempt to fix the issue will be made before the next release; If no fix is attempt to fix the issue will be made before the next release; If no fix is
provided then the commit will be reverted. provided then the commit will be reverted.
@ -320,7 +320,7 @@ operation of running code and therefore should not be viewed as breaking
changes. changes.
Runtime Deprecations and End-of-life APIs (internal or public) *must* be Runtime Deprecations and End-of-life APIs (internal or public) *must* be
handled as semver-major changes unless there is CTC consensus to land the handled as semver-major changes unless there is TSC consensus to land the
deprecation as a semver-minor. deprecation as a semver-minor.
All Documentation-Only and Runtime deprecations will be assigned a unique All Documentation-Only and Runtime deprecations will be assigned a unique
@ -346,10 +346,10 @@ request adding the deprecation lands in master). All deprecations included in
a Node.js release should be listed prominently in the "Notable Changes" section a Node.js release should be listed prominently in the "Notable Changes" section
of the release notes. of the release notes.
### Involving the CTC ### Involving the TSC
Collaborators may opt to elevate pull requests or issues to the CTC for Collaborators may opt to elevate pull requests or issues to the TSC for
discussion by assigning the `ctc-review` label. This should be done discussion by assigning the `tsc-review` label. This should be done
where a pull request: where a pull request:
- has a significant impact on the codebase, - has a significant impact on the codebase,
@ -357,7 +357,7 @@ where a pull request:
- has failed to reach consensus amongst the Collaborators who are - has failed to reach consensus amongst the Collaborators who are
actively participating in the discussion. actively participating in the discussion.
The CTC should serve as the final arbiter where required. The TSC should serve as the final arbiter where required.
## Landing Pull Requests ## Landing Pull Requests
@ -567,7 +567,7 @@ git push upstream master
### I Just Made a Mistake ### I Just Made a Mistake
* Ping a CTC member. * Ping a TSC member.
* `#node-dev` on freenode * `#node-dev` on freenode
* With `git`, there's a way to override remote trees by force pushing * With `git`, there's a way to override remote trees by force pushing
(`git push -f`). This should generally be seen as forbidden (since (`git push -f`). This should generally be seen as forbidden (since
@ -596,9 +596,9 @@ Once a Current branch enters LTS, changes in that branch are limited to bug
fixes, security updates, possible npm updates, documentation updates, and fixes, security updates, possible npm updates, documentation updates, and
certain performance improvements that can be demonstrated to not break existing certain performance improvements that can be demonstrated to not break existing
applications. Semver-minor changes are only permitted if required for bug fixes applications. Semver-minor changes are only permitted if required for bug fixes
and then only on a case-by-case basis with LTS WG and possibly Core Technical and then only on a case-by-case basis with LTS WG and possibly Technical
Committee (CTC) review. Semver-major changes are permitted only if required for Steering Committee (TSC) review. Semver-major changes are permitted only if
security related fixes. required for security related fixes.
Once a Current branch moves into Maintenance mode, only **critical** bugs, Once a Current branch moves into Maintenance mode, only **critical** bugs,
**critical** security fixes, and documentation updates will be permitted. **critical** security fixes, and documentation updates will be permitted.
@ -606,7 +606,7 @@ Once a Current branch moves into Maintenance mode, only **critical** bugs,
#### Landing semver-minor commits in LTS #### Landing semver-minor commits in LTS
The default policy is to not land semver-minor or higher commits in any LTS The default policy is to not land semver-minor or higher commits in any LTS
branch. However, the LTS WG or CTC can evaluate any individual semver-minor branch. However, the LTS WG or TSC can evaluate any individual semver-minor
commit and decide whether a special exception ought to be made. It is commit and decide whether a special exception ought to be made. It is
expected that such exceptions would be evaluated, in part, on the scope expected that such exceptions would be evaluated, in part, on the scope
and impact of the changes on the code, the risk to ecosystem stability and impact of the changes on the code, the risk to ecosystem stability
@ -616,7 +616,7 @@ commit will have for the ecosystem.
Any collaborator who feels a semver-minor commit should be landed in an LTS Any collaborator who feels a semver-minor commit should be landed in an LTS
branch should attach the `lts-agenda` label to the pull request. The LTS WG branch should attach the `lts-agenda` label to the pull request. The LTS WG
will discuss the issue and, if necessary, will escalate the issue up to the will discuss the issue and, if necessary, will escalate the issue up to the
CTC for further discussion. TSC for further discussion.
#### How are LTS Branches Managed? #### How are LTS Branches Managed?

132
GOVERNANCE.md
View File

@ -1,14 +1,15 @@
# Node.js Project Governance # Node.js Project Governance
The Node.js project is governed by its Collaborators, including a Core Technical The Node.js project is governed by its Collaborators, including a Technical
Committee (CTC) which is responsible for high-level guidance of the project. Steering Committee (TSC) which is responsible for high-level guidance of the
project.
## Collaborators ## Collaborators
The [nodejs/node](https://github.com/nodejs/node) GitHub repository is The [nodejs/node](https://github.com/nodejs/node) GitHub repository is
maintained by Collaborators who are added by the CTC on an ongoing basis. maintained by Collaborators who are added by the TSC on an ongoing basis.
Individuals identified by the CTC as making significant and valuable Individuals identified by the TSC as making significant and valuable
contributions across any Node.js repository may be made Collaborators and given contributions across any Node.js repository may be made Collaborators and given
commit access to the project. Activities taken into consideration include (but commit access to the project. Activities taken into consideration include (but
are not limited to) the quality of: are not limited to) the quality of:
@ -22,7 +23,7 @@ are not limited to) the quality of:
* other participation in the wider Node.js community * other participation in the wider Node.js community
If individuals making valuable contributions do not believe they have been If individuals making valuable contributions do not believe they have been
considered for commit access, they may log an issue or contact a CTC member considered for commit access, they may log an issue or contact a TSC member
directly. directly.
Modifications of the contents of the nodejs/node repository are made on Modifications of the contents of the nodejs/node repository are made on
@ -40,13 +41,13 @@ be accepted unless:
* Discussions and/or additional changes result in no Collaborators objecting to * Discussions and/or additional changes result in no Collaborators objecting to
the change. Previously-objecting Collaborators do not necessarily have to the change. Previously-objecting Collaborators do not necessarily have to
sign-off on the change, but they should not be opposed to it. sign-off on the change, but they should not be opposed to it.
* The change is escalated to the CTC and the CTC votes to approve the change. * The change is escalated to the TSC and the TSC votes to approve the change.
This should only happen if disagreements between Collaborators cannot be This should only happen if disagreements between Collaborators cannot be
resolved through discussion. resolved through discussion.
Collaborators may opt to elevate significant or controversial modifications to Collaborators may opt to elevate significant or controversial modifications to
the CTC by assigning the `ctc-review` label to a pull request or issue. The the TSC by assigning the `tsc-review` label to a pull request or issue. The
CTC should serve as the final arbiter where required. TSC should serve as the final arbiter where required.
* [Current list of Collaborators](./README.md#current-project-team-members) * [Current list of Collaborators](./README.md#current-project-team-members)
* [A guide for Collaborators](./COLLABORATOR_GUIDE.md) * [A guide for Collaborators](./COLLABORATOR_GUIDE.md)
@ -61,13 +62,13 @@ Typical activities of a Collaborator include:
* participation in working groups * participation in working groups
* merging pull requests * merging pull requests
The CTC periodically reviews the Collaborator list to identify inactive The TSC periodically reviews the Collaborator list to identify inactive
Collaborators. Past Collaborators are typically given _Emeritus_ status. Emeriti Collaborators. Past Collaborators are typically given _Emeritus_ status. Emeriti
may request that the CTC restore them to active status. may request that the TSC restore them to active status.
## Core Technical Committee ## Technical Steering Committee
The Core Technical Committee (CTC) has final authority over this project The Technical Steering Committee (TSC) has final authority over this project
including: including:
* Technical direction * Technical direction
@ -77,59 +78,19 @@ including:
* Conduct guidelines * Conduct guidelines
* Maintaining the list of additional Collaborators * Maintaining the list of additional Collaborators
* [Current list of CTC members](./README.md#current-project-team-members) * [Current list of TSC members](./README.md#current-project-team-members)
## CTC Membership The operations of the TSC are governed by the [TSC Charter][] as approved by
the Node.js Foundation Board of Directors.
CTC seats are not time-limited. There is no fixed size of the CTC. The CTC ### TSC Meetings
should be of such a size as to ensure adequate coverage of important areas of
expertise balanced with the ability to make decisions efficiently.
There is no specific set of requirements or qualifications for CTC The TSC meets regularly in a voice conference call. The meeting is run by a
membership beyond these rules. designated meeting chair approved by the TSC. Each meeting is streamed on
The CTC may add additional members to the CTC by a standard CTC motion.
When a CTC member's participation in [CTC activities](#ctc-activities) has
become minimal for a sustained period of time, the CTC will request that the
member either indicate an intention to increase participation or voluntarily
resign.
CTC members may only be removed by voluntary resignation or through a standard
CTC motion.
Changes to CTC membership should be posted in the agenda, and may be
suggested as any other agenda item (see [CTC Meetings](#ctc-meetings) below).
No more than 1/3 of the CTC members may be affiliated with the same
employer. If removal or resignation of a CTC member, or a change of
employment by a CTC member, creates a situation where more than 1/3 of
the CTC membership shares an employer, then the situation must be
immediately remedied by the resignation or removal of one or more CTC
members affiliated with the over-represented employer(s).
### CTC Activities
Typical activities of a CTC member include:
* attending the weekly meeting
* commenting on the weekly CTC meeting issue and issues labeled `ctc-review`
* participating in CTC email threads
* volunteering for tasks that arise from CTC meetings and related discussions
* other activities (beyond those typical of Collaborators) that facilitate the
smooth day-to-day operation of the Node.js project
Note that CTC members are also Collaborators and therefore typically perform
Collaborator activities as well.
### CTC Meetings
The CTC meets weekly in a voice conference call. The meeting is run by a
designated meeting chair approved by the CTC. Each meeting is streamed on
YouTube. YouTube.
Items are added to the CTC agenda which are considered contentious or Items are added to the TSC agenda which are considered contentious or
are modifications of governance, contribution policy, CTC membership, are modifications of governance, contribution policy, TSC membership,
or release process. or release process.
The intention of the agenda is not to approve or review all patches. The intention of the agenda is not to approve or review all patches.
@ -137,49 +98,40 @@ That should happen continuously on GitHub and be handled by the larger
group of Collaborators. group of Collaborators.
Any community member or contributor can ask that something be reviewed Any community member or contributor can ask that something be reviewed
by the CTC by logging a GitHub issue. Any Collaborator, CTC member, or the by the TSC by logging a GitHub issue. Any Collaborator, TSC member, or the
meeting chair can bring the issue to the CTC's attention by applying the meeting chair can bring the issue to the TSC's attention by applying the
`ctc-review` label. If consensus-seeking among CTC members fails for a `tsc-review` label. If consensus-seeking among TSC members fails for a
particular issue, it may be added to the CTC meeting agenda by adding the particular issue, it may be added to the TSC meeting agenda by adding the
`ctc-agenda` label. `tsc-agenda` label.
Prior to each CTC meeting, the meeting chair will share the agenda with Prior to each TSC meeting, the meeting chair will share the agenda with
members of the CTC. CTC members can also add items to the agenda at the members of the TSC. TSC members can also add items to the agenda at the
beginning of each meeting. The meeting chair and the CTC cannot veto or remove beginning of each meeting. The meeting chair and the TSC cannot veto or remove
items. items.
The CTC may invite persons or representatives from certain projects to The TSC may invite additional persons to participate in a non-voting capacity.
participate in a non-voting capacity.
The meeting chair is responsible for ensuring that minutes are taken and that a The meeting chair is responsible for ensuring that minutes are taken and that a
pull request with the minutes is submitted after the meeting. pull request with the minutes is submitted after the meeting.
Due to the challenges of scheduling a global meeting with participants in Due to the challenges of scheduling a global meeting with participants in
several timezones, the CTC will seek to resolve as many agenda items as possible several timezones, the TSC will seek to resolve as many agenda items as possible
outside of meetings using outside of meetings using
[the CTC issue tracker](https://github.com/nodejs/CTC/issues). The process in [the TSC issue tracker](https://github.com/nodejs/TSC/issues). The process in
the issue tracker is: the issue tracker is:
* A CTC member opens an issue explaining the proposal/issue and @-mentions * A TSC member opens an issue explaining the proposal/issue and @-mentions
@nodejs/ctc. @nodejs/tsc.
* After 72 hours, if there are two or more `LGTM`s from other CTC members and no * After 72 hours, if there are two or more `LGTM`s from other TSC members and no
explicit opposition from other CTC members, then the proposal is approved. explicit opposition from other TSC members, then the proposal is approved.
* If there are any CTC members objecting, then a conversation ensues until * If there are any TSC members objecting, then a conversation ensues until
either the proposal is dropped or the objecting members are persuaded. If either the proposal is dropped or the objecting members are persuaded. If
there is an extended impasse, a motion for a vote may be made. there is an extended impasse, a motion for a vote may be made.
## Consensus Seeking Process ## Consensus Seeking Process
The CTC follows a The TSC follows a [Consensus Seeking][] decision making model as described by
[Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making) the [TSC Charter][].
decision making model.
When an agenda item has appeared to reach a consensus, the meeting chair will
ask "Does anyone object?" as a final call for dissent from the consensus.
If an agenda item cannot reach a consensus, a CTC member can call for either a [TSC Charter]: https://github.com/nodejs/TSC/blob/master/TSC-Charter.md
closing vote or a vote to table the issue to the next meeting. All votes [Consensus Seeking]: http://en.wikipedia.org/wiki/Consensus-seeking_decision-making
(including votes to close or table) pass if and only if more than 50% of the CTC
members (excluding individuals who explicitly abstain) vote in favor. For
example, if there are 20 CTC members, and 5 of those members indicate that they
abstain, then 8 votes in favor are required for a resolution to pass.

20
README.md
View File

@ -35,7 +35,7 @@ If you need help using or installing Node.js, please use the
* [Building Node.js](#building-nodejs) * [Building Node.js](#building-nodejs)
* [Security](#security) * [Security](#security)
* [Current Project Team Members](#current-project-team-members) * [Current Project Team Members](#current-project-team-members)
* [CTC (Core Technical Committee)](#ctc-core-technical-committee) * [TSC (Technical Steering Committee)](#tsc-technical-steering-committee)
* [Collaborators](#collaborators) * [Collaborators](#collaborators)
* [Release Team](#release-team) * [Release Team](#release-team)
@ -55,9 +55,9 @@ If you need help using or installing Node.js, please use the
channel. channel.
_Please note that unofficial resources are neither managed by (nor necessarily _Please note that unofficial resources are neither managed by (nor necessarily
endorsed by) the Node.js TSC/CTC. Specifically, such resources are not endorsed by) the Node.js TSC. Specifically, such resources are not
currently covered by the [Node.js Moderation Policy][] and the selection and currently covered by the [Node.js Moderation Policy][] and the selection and
actions of resource operators/moderators are not subject to TSC/CTC oversight._ actions of resource operators/moderators are not subject to TSC oversight._
## Release Types ## Release Types
@ -176,11 +176,11 @@ handling your report.
## Current Project Team Members ## Current Project Team Members
The Node.js project team comprises a group of core collaborators and a sub-group The Node.js project team comprises a group of core collaborators and a sub-group
that forms the _Core Technical Committee_ (CTC) which governs the project. For that forms the _Technical Steering Committee_ (TSC) which governs the project.
more information about the governance of the Node.js project, see For more information about the governance of the Node.js project, see
[GOVERNANCE.md](./GOVERNANCE.md). [GOVERNANCE.md](./GOVERNANCE.md).
### CTC (Core Technical Committee) ### TSC (Technical Steering Committee)
* [addaleax](https://github.com/addaleax) - * [addaleax](https://github.com/addaleax) -
**Anna Henningsen** &lt;anna@addaleax.net&gt; (she/her) **Anna Henningsen** &lt;anna@addaleax.net&gt; (she/her)
@ -200,6 +200,8 @@ more information about the governance of the Node.js project, see
**Fedor Indutny** &lt;fedor.indutny@gmail.com&gt; **Fedor Indutny** &lt;fedor.indutny@gmail.com&gt;
* [jasnell](https://github.com/jasnell) - * [jasnell](https://github.com/jasnell) -
**James M Snell** &lt;jasnell@gmail.com&gt; (he/him) **James M Snell** &lt;jasnell@gmail.com&gt; (he/him)
* [joshgav](https://github.com/joshgav) -
**Josh Gavant** &lt;josh.gavant@outlook.com&gt;
* [joyeecheung](https://github.com/joyeecheung) - * [joyeecheung](https://github.com/joyeecheung) -
**Joyee Cheung** &lt;joyeec9h3@gmail.com&gt; (she/her) **Joyee Cheung** &lt;joyeec9h3@gmail.com&gt; (she/her)
* [mcollina](https://github.com/mcollina) - * [mcollina](https://github.com/mcollina) -
@ -225,7 +227,7 @@ more information about the governance of the Node.js project, see
* [Trott](https://github.com/Trott) - * [Trott](https://github.com/Trott) -
**Rich Trott** &lt;rtrott@gmail.com&gt; (he/him) **Rich Trott** &lt;rtrott@gmail.com&gt; (he/him)
### CTC Emeriti ### TSC Emeriti
* [chrisdickinson](https://github.com/chrisdickinson) - * [chrisdickinson](https://github.com/chrisdickinson) -
**Chris Dickinson** &lt;christopher.s.dickinson@gmail.com&gt; **Chris Dickinson** &lt;christopher.s.dickinson@gmail.com&gt;
@ -235,6 +237,8 @@ more information about the governance of the Node.js project, see
**Alexis Campailla** &lt;orangemocha@nodejs.org&gt; **Alexis Campailla** &lt;orangemocha@nodejs.org&gt;
* [piscisaureus](https://github.com/piscisaureus) - * [piscisaureus](https://github.com/piscisaureus) -
**Bert Belder** &lt;bertbelder@gmail.com&gt; **Bert Belder** &lt;bertbelder@gmail.com&gt;
* [nebrius](https://github.com/nebrius) -
**Bryan Hughes** &lt;bryan@nebri.us&gt;
### Collaborators ### Collaborators
@ -508,7 +512,7 @@ Previous releases may also have been signed with one of the following GPG keys:
### Working Groups ### Working Groups
Information on the current Node.js Working Groups can be found in the Information on the current Node.js Working Groups can be found in the
[CTC repository](https://github.com/nodejs/CTC/blob/master/WORKING_GROUPS.md). [TSC repository](https://github.com/nodejs/TSC/blob/master/WORKING_GROUPS.md).
[npm]: https://www.npmjs.com [npm]: https://www.npmjs.com
[Website]: https://nodejs.org/en/ [Website]: https://nodejs.org/en/

6
doc/onboarding.md
View File

@ -43,7 +43,7 @@ onboarding session.
* Use [https://github.com/notifications](https://github.com/notifications) or set up email * Use [https://github.com/notifications](https://github.com/notifications) or set up email
* Watching the main repo will flood your inbox (several hundred notifications on typical weekdays), so be prepared * Watching the main repo will flood your inbox (several hundred notifications on typical weekdays), so be prepared
* `#node-dev` on [webchat.freenode.net](https://webchat.freenode.net/) is the best place to interact with the CTC / other Collaborators * `#node-dev` on [webchat.freenode.net](https://webchat.freenode.net/) is the best place to interact with the TSC / other Collaborators
* If there are any questions after the session, a good place to ask is there! * If there are any questions after the session, a good place to ask is there!
* Presence is not mandatory, but please drop a note there if force-pushing to `master` * Presence is not mandatory, but please drop a note there if force-pushing to `master`
@ -67,7 +67,7 @@ onboarding session.
* [**See "Labels"**](./onboarding-extras.md#labels) * [**See "Labels"**](./onboarding-extras.md#labels)
* There is [a bot](https://github.com/nodejs-github-bot/github-bot) that applies subsystem labels (for example, `doc`, `test`, `assert`, or `buffer`) so that we know what parts of the code base the pull request modifies. It is not perfect, of course. Feel free to apply relevant labels and remove irrelevant labels from pull requests and issues. * There is [a bot](https://github.com/nodejs-github-bot/github-bot) that applies subsystem labels (for example, `doc`, `test`, `assert`, or `buffer`) so that we know what parts of the code base the pull request modifies. It is not perfect, of course. Feel free to apply relevant labels and remove irrelevant labels from pull requests and issues.
* Use the `ctc-review` label if a topic is controversial or isn't coming to * Use the `tsc-review` label if a topic is controversial or isn't coming to
a conclusion after an extended time. a conclusion after an extended time.
* `semver-{minor,major}`: * `semver-{minor,major}`:
* If a change has the remote *chance* of breaking something, use the `semver-major` label * If a change has the remote *chance* of breaking something, use the `semver-major` label
@ -166,7 +166,7 @@ onboarding session.
* Almost any mistake you could make can be fixed or reverted. * Almost any mistake you could make can be fixed or reverted.
* The existing Collaborators trust you and are grateful for your help! * The existing Collaborators trust you and are grateful for your help!
* Other repositories: * Other repositories:
* [https://github.com/nodejs/CTC](https://github.com/nodejs/CTC) * [https://github.com/nodejs/TSC](https://github.com/nodejs/TSC)
* [https://github.com/nodejs/build](https://github.com/nodejs/build) * [https://github.com/nodejs/build](https://github.com/nodejs/build)
* [https://github.com/nodejs/nodejs.org](https://github.com/nodejs/nodejs.org) * [https://github.com/nodejs/nodejs.org](https://github.com/nodejs/nodejs.org)
* [https://github.com/nodejs/readable-stream](https://github.com/nodejs/readable-stream) * [https://github.com/nodejs/readable-stream](https://github.com/nodejs/readable-stream)

2
src/node_revert.h
View File

@ -8,7 +8,7 @@
/** /**
* Note that it is expected for this list to vary across specific LTS and * Note that it is expected for this list to vary across specific LTS and
* Stable versions! Only CVE's whose fixes require *breaking* changes within * Stable versions! Only CVE's whose fixes require *breaking* changes within
* a given LTS or Stable may be added to this list, and only with CTC * a given LTS or Stable may be added to this list, and only with TSC
* consensus. * consensus.
* *
* For *master* this list should always be empty! * For *master* this list should always be empty!

Write Preview
Loading…
Cancel
Save