meta: merge TSC and CTC back into a single body

PR-URL: #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>

COLLABORATOR_GUIDE.md

@@ -8,7 +8,7 @@
    - [Internal vs. Public API](#internal-vs-public-api)
    - [Breaking Changes](#breaking-changes)
    - [Deprecations](#deprecations)
-   - [Involving the CTC](#involving-the-ctc)
+   - [Involving the TSC](#involving-the-TSC)
 * [Landing Pull Requests](#landing-pull-requests)
    - [Technical HOWTO](#technical-howto)
    - [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
 managing issues and pull requests they feel qualified to handle, as
 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
 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
 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
 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.
 Where there is discussion amongst Collaborators, consensus should be
 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
 the major version number, known as `semver-major` changes) must be
-elevated for review by the CTC. This does not necessarily mean that the
-PR must be put onto the CTC meeting agenda. If multiple CTC members
+elevated for review by the TSC. This does not necessarily mean that the
+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
-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
-put on the CTC meeting agenda.
+put on the TSC meeting agenda.
 
 All bugfixes require a test case which demonstrates the defect. The
 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
 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
-basis by the CTC.
+basis by the TSC.
 
 If it is determined that a currently undocumented object, property, method,
 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
 by analyzing current use and by validating such changes through ecosystem
 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.
 
 If a determination is made that a particular internal API (for instance, an
@@ -183,7 +183,7 @@ breaking changes are made.
 ### Breaking Changes
 
 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,
 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
 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.
 
 Purely additive changes (e.g. adding new events to EventEmitter
@@ -244,7 +244,7 @@ Specifically:
   * Resolving critical security issues.
   * Fixing a critical bug (e.g. fixing a memory leak) requires a breaking
     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
   attempt to fix the issue will be made before the next release; If no fix is
   provided then the commit will be reverted.
@@ -320,7 +320,7 @@ operation of running code and therefore should not be viewed as breaking
 changes.
 
 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.
 
 All Documentation-Only and Runtime deprecations will be assigned a unique
@@ -346,18 +346,18 @@ request adding the deprecation lands in master). All deprecations included in
 a Node.js release should be listed prominently in the "Notable Changes" section
 of the release notes.
 
-### Involving the CTC
+### Involving the TSC
 
-Collaborators may opt to elevate pull requests or issues to the CTC for
-discussion by assigning the `ctc-review` label. This should be done
+Collaborators may opt to elevate pull requests or issues to the TSC for
+discussion by assigning the `tsc-review` label. This should be done
 where a pull request:
 
 - has a significant impact on the codebase,
 - is inherently controversial; or
 - has failed to reach consensus amongst the Collaborators who are
   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
 
@@ -567,7 +567,7 @@ git push upstream master
 
 ### I Just Made a Mistake
 
-* Ping a CTC member.
+* Ping a TSC member.
 * `#node-dev` on freenode
 * With `git`, there's a way to override remote trees by force pushing
 (`git push -f`). This should generally be seen as forbidden (since
@@ -596,17 +596,17 @@ Once a Current branch enters LTS, changes in that branch are limited to bug
 fixes, security updates, possible npm updates, documentation updates, and
 certain performance improvements that can be demonstrated to not break existing
 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
-Committee (CTC) review. Semver-major changes are permitted only if required for
-security related fixes.
+and then only on a case-by-case basis with LTS WG and possibly Technical
+Steering Committee (TSC) review. Semver-major changes are permitted only if
+required for security related fixes.
 
 Once a Current branch moves into Maintenance mode, only **critical** bugs,
 **critical** security fixes, and documentation updates will be permitted.
 
 #### Landing semver-minor commits in 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
 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
@@ -616,7 +616,7 @@ commit will have for the ecosystem.
 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
 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?
 

GOVERNANCE.md

@@ -1,14 +1,15 @@
 # Node.js Project Governance
 
-The Node.js project is governed by its Collaborators, including a Core Technical
-Committee (CTC) which is responsible for high-level guidance of the project.
+The Node.js project is governed by its Collaborators, including a Technical
+Steering Committee (TSC) which is responsible for high-level guidance of the
+project.
 
 ## Collaborators
 
 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
 commit access to the project. Activities taken into consideration include (but
 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
 
 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.
 
 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
   the change. Previously-objecting Collaborators do not necessarily have to
   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
   resolved through discussion.
 
 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
-CTC should serve as the final arbiter where required.
+the TSC by assigning the `tsc-review` label to a pull request or issue. The
+TSC should serve as the final arbiter where required.
 
 * [Current list of Collaborators](./README.md#current-project-team-members)
 * [A guide for Collaborators](./COLLABORATOR_GUIDE.md)
@@ -61,13 +62,13 @@ Typical activities of a Collaborator include:
 * participation in working groups
 * 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
-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:
 
 * Technical direction
@@ -77,109 +78,60 @@ including:
 * Conduct guidelines
 * 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
-should be of such a size as to ensure adequate coverage of important areas of
-expertise balanced with the ability to make decisions efficiently.
+### TSC Meetings
 
-There is no specific set of requirements or qualifications for CTC
-membership beyond these rules.
-
-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
+The TSC meets regularly in a voice conference call. The meeting is run by a
+designated meeting chair approved by the TSC. Each meeting is streamed on
 YouTube.
 
-Items are added to the CTC agenda which are considered contentious or
-are modifications of governance, contribution policy, CTC membership,
+Items are added to the TSC agenda which are considered contentious or
+are modifications of governance, contribution policy, TSC membership,
 or release process.
 
 The intention of the agenda is not to approve or review all patches.
 That should happen continuously on GitHub and be handled by the larger
 group of Collaborators.
 
 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
-meeting chair can bring the issue to the CTC's attention by applying the
-`ctc-review` label. If consensus-seeking among CTC members fails for a
-particular issue, it may be added to the CTC meeting agenda by adding the
-`ctc-agenda` label.
-
-Prior to each CTC meeting, the meeting chair will share the agenda with
-members of the CTC. CTC members can also add items to the agenda at the
-beginning of each meeting. The meeting chair and the CTC cannot veto or remove
+by the TSC by logging a GitHub issue. Any Collaborator, TSC member, or the
+meeting chair can bring the issue to the TSC's attention by applying the
+`tsc-review` label. If consensus-seeking among TSC members fails for a
+particular issue, it may be added to the TSC meeting agenda by adding the
+`tsc-agenda` label.
+
+Prior to each TSC meeting, the meeting chair will share the agenda with
+members of the TSC. TSC members can also add items to the agenda at the
+beginning of each meeting. The meeting chair and the TSC cannot veto or remove
 items.
 
-The CTC may invite persons or representatives from certain projects to
-participate in a non-voting capacity.
+The TSC may invite additional persons to participate in a non-voting capacity.
 
 The meeting chair is responsible for ensuring that minutes are taken and that a
 pull request with the minutes is submitted after the meeting.
 
 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
-[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:
 
-* A CTC member opens an issue explaining the proposal/issue and @-mentions
-  @nodejs/ctc.
-* After 72 hours, if there are two or more `LGTM`s from other CTC members and no
-  explicit opposition from other CTC members, then the proposal is approved.
-* If there are any CTC members objecting, then a conversation ensues until
+* A TSC member opens an issue explaining the proposal/issue and @-mentions
+  @nodejs/tsc.
+* After 72 hours, if there are two or more `LGTM`s from other TSC members and no
+  explicit opposition from other TSC members, then the proposal is approved.
+* If there are any TSC members objecting, then a conversation ensues until
   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.
 
 ## Consensus Seeking Process
 
-The CTC follows a
-[Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making)
-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.
+The TSC follows a [Consensus Seeking][] decision making model as described by
+the [TSC Charter][].
 
-If an agenda item cannot reach a consensus, a CTC member can call for either a
-closing vote or a vote to table the issue to the next meeting. All votes
-(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.
+[TSC Charter]: https://github.com/nodejs/TSC/blob/master/TSC-Charter.md
+[Consensus Seeking]: http://en.wikipedia.org/wiki/Consensus-seeking_decision-making