Skip to content

Commit

Permalink
meta: merge TSC and CTC back into a single body
Browse files Browse the repository at this point in the history 
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>
  • Loading branch information
@jasnell @MylesBorins
jasnell authored and MylesBorins committed Sep 12, 2017
1 parent b946693 commit 01846a0
Show file tree
Hide file tree
Showing 5 changed files with 82 additions and 126 deletions.
48 changes: 24 additions & 24 deletions COLLABORATOR_GUIDE.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand All @@ -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
Expand All @@ -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
Expand All @@ -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.
Expand Down Expand Up @@ -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
Expand All @@ -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
Expand All @@ -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
Expand All @@ -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
Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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
Expand All @@ -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

Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand All @@ -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?

Expand Down
132 changes: 42 additions & 90 deletions GOVERNANCE.md
View file
Original file line number Diff line number Diff line change
@@ -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:
Expand All @@ -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
Expand All @@ -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)
Expand All @@ -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
Expand All @@ -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
Loading

0 comments on commit 01846a0

Please sign in to comment.