Node.js TSC: the governance map of the Node.js project

A repository of process rather than code

The nodejs/TSC repository holds the documentation of the Node.js Technical Steering Committee, which is described as the technical governing body of Node.js, with the scope set out in the TSC Charter. The repository contents reflect that. There is no source code, only documents: TSC-Charter.md, WORKING_GROUPS.md, Strategic-Initiatives.md, OpenSSL-Strategy.md, ONBOARDING.md, Moderation-Policy.md, CODE_OF_CONDUCT.md, Member-Travel-Fund.md, Nodejs-Bug-Bounty-Security-Fund.md and Nodejs-Funding-Sources.md. Alongside them sit directories that record the committee's actual work, with `meetings/`, `votes/` and `surveys/` directories, and a `Streaming/` directory. The package.json in the root is a formality for a private package whose only script is a lint pass over the Markdown using remark, with the `remark-preset-lint-node` preset and `remark-cli` as the two development dependencies. In short, this is where the Node.js project's rules live as prose, and reading it is how you learn which process applies to the change you want to make.

Three tiers of responsibility

The scope is described in three layers. Node.js Core is defined precisely as the contents of the nodejs/node repository from which the `node` executable and associated packages are built, excluding the vendored projects in the `deps` and `tools` directories that are copied in from externally maintained repositories. That exclusion is a real boundary rather than a formality, because a change in a vendored dependency is not a Node.js Core change and is not decided the same way. Dependent projects are those that are dependencies of Node.js Core in the sense that they are required to plan, test, build, document and ship Node.js releases, and the TSC has autonomy in managing them while seeking agreement from the OpenJS Foundation Board on any change to the scope of those responsibilities. Adjacent projects are the third tier, and they are not required for shipping a release; they are either created from within the technical organization the TSC manages or adopted into it from outside, and adoption requires agreement from the OpenJS Foundation Board because it affects the scope of the Foundation's technical activities.

Where the real work is delegated

The lists in the charter are not a flat inventory, because most entries carry a note about who administers them. The dependent project list names `nodejs/build` with administration delegated to the Build Working Group, `nodejs/citgm` and `nodejs/Release` to the Release Working Group, `nodejs/docker-node` to the Docker Working Group, `nodejs/http-parser` and `nodejs/node-eps` to the Core Technical Committee, `nodejs/nodejs-dist-indexer`, `nodejs/nodejs-latest-linker` and `nodejs/nodejs-nightly-builder` to the Build Working Group, `nodejs/nodejs.org` to the Website Working Group, and `nodejs/secrets`, which is described as private, to the Build Working Group. The adjacent list follows the same pattern with the API Working Group covering `abi-stable-node`, `abi-stable-node-addon-examples` and `api`, the Diagnostics Working Group covering `diagnostics` and `node-inspect`, the Post Mortem Working Group covering `node-report`, `post-mortem` and `llnode`, the Addon API Working Group covering `nan` and `node-addon-examples`, the Streams Working Group covering `readable-stream`, and the Website Working Group covering `nodejs.org` again. Projects such as `code-and-learn`, `docs`, `education`, `email`, `github-bot`, `help`, `http`, `http2`, `installer`, `node-chakracore`, `node-gyp`, `promises`, `summit` and `testing` appear with no delegation note, which means they sit directly with the TSC.

The responsibilities the committee actually holds

The charter enumerates what the TSC is responsible for, and the list reads like a constitution. It manages code and documentation creation and changes for the listed projects and resources. It sets and maintains standards covering contributions of code, documentation and other materials. It manages code and binary releases, including their types, schedules, frequency and delivery mechanisms. It makes decisions about the dependencies of Node.js Core, including what those dependencies are and how they are bundled with the source code and the releases, which is a broader mandate than it first appears. It creates new repositories and projects under the nodejs GitHub organization as required. It sets overall technical direction for Node.js Core, at both the level of high-level goals and low-level specifics about features and functionality. It maintains standards for community discourse across the media it controls, and it sets and maintains governance rules for the conduct and make-up of the TSC, the working groups and other bodies in its domain. The charter also notes that many of these responsibilities are delegated to appropriate bodies such as the working groups, which is the practical answer to the question of who to ask.

Who the members are and what the role is

The charter describes TSC members as responsible for top-level technical community concerns, with the role being mostly administrative and covering admitting new working groups and advocating for technical needs to the OpenJS Foundation Board of Directors. That last clause is the interesting one, because it makes the TSC the interface between the Node.js project and the foundation that funds and hosts it. The document is candid about who the role suits. Members can nominate new members at any time, and candidates tend to be people with a competency for community management and a high tolerance and patience for process minutiae, because the TSC delegates most of its responsibilities to other working groups. So the committee is a small group of coordinators rather than a group of senior engineers making design calls, and the actual design work sits with the working groups and with the Core Technical Committee. The current member list is not kept in this repository at all; it is maintained in the main Node.js repository, which is worth knowing before you go looking for it here.

Why this repository matters for a contributor

The practical value for an outside developer is diagnostic. When a change to Node.js feels like it is going nowhere, the likely reason is a routing mistake rather than a rejection, and this repository is the map that says where it should have gone. A change to the `http` module is a different conversation from a change to the addon API, and the delegation notes in the charter are how you tell them apart before you write a proposal. The governance documents are also where you find the less glamorous requirements that bite contributors: the contribution standards, the code of conduct, the moderation policy, the onboarding document for new people, and the funding sources document. The `meetings/`, `votes/` and `surveys/` directories record what the committee actually decided and when, and the `Streaming/` directory holds the meeting recordings that the YouTube section refers to, since many teams post their meeting videos to the Node.js channel and any GitHub team maintainer can, per the charter, arrange to have those videos streamed.

What this repository is not

Two limits are worth naming so that expectations are set correctly. First, this is not where the roadmap lives. Strategic-Initiatives.md is a document in the repository, but a strategic initiative document is not a schedule, and the charter's mention of release types, schedules, frequency and delivery mechanisms is a statement about who decides those things rather than a list of dates. Anyone looking for a shipping date will not find one here. Second, the repository is not a self-contained rulebook, because the TSC charter itself is referenced as a separate document and the member list is maintained elsewhere, in the main Node.js repository. The governance structure also sits inside a wider body. The TSC exercises autonomy over its responsibilities but seeks agreement from the OpenJS Foundation Board for changes to scope, and that two-level structure is the part of the model that is hardest to read from the outside. The metadata records the licence as unknown for the repository, while the package.json declares ISC, and for a documentation repository the distinction is academic until you decide to republish the text.

Editorial conclusion

The TSC repository is worth reading before you file an issue or a pull request against Node.js, because it tells you which body owns what, and the answer is often a working group rather than the committee itself. It is not useful for learning how the runtime works, and it is not a place to find roadmap dates. Before acting, read TSC-Charter.md for the scope, WORKING_GROUPS.md for the delegation map, and the charter in the main Node.js repository for the current member list. The last push was on 2026-10-15, the repository publishes no GitHub releases, and the metadata records the licence as unknown while the package.json declares ISC.

Frequently asked questions

Official sources

1. Issues
2. nodejs/TSC on GitHub
3. README