feat(meta): document TSC oversight

[avivkeller]

As per the miscommunications evidenced in #7773, I believe that the best way to prevent such issues in the future is to explicitly document the governance procedures between the Website Team and TSC. This PR adds clear guidelines on:

• The explicit boundaries of decision-making authority
• Types of content requiring formal TSC approval
• Specific approval processes for sensitive content categories
• Procedures for resolving disagreements

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
nodejs-org	❌ Failed (Inspect)		Jun 22, 2025 3:12pm

[Copilot]

Pull Request Overview

This PR formalizes the governance relationship between the Website Team and the TSC by documenting decision authority, approval requirements, feedback handling, and dispute resolution processes.

• Clarifies authority hierarchy and Website Team autonomy vs TSC oversight
• Specifies content categories requiring formal TSC approval and endorsement process
• Adds procedures for handling feedback, resolving disagreements, and documenting approvals

Comments suppressed due to low confidence (2)

GOVERNANCE.md:32

• The contact email uses the deprecated iojs.org domain; update it to tsc@nodejs.org to reflect the current Node.js project email address.

- Sending an email to `tsc@iojs.org`

GOVERNANCE.md:29

• [nitpick] Consider adding an expected response timeframe (for example, seven days) for TSC endorsement requests to set clear expectations on how long approval requests remain open.

Website changes falling under these categories require **formal TSC endorsement** as outlined in the [TSC Charter](https://github.com/nodejs/TSC/blob/main/TSC-Charter.md#section-4-responsibilities-of-the-tsc). Valid approval consists of at least one TSC member's explicit approval with no objections from any TSC members. This endorsement may be secured through either:

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.46%. Comparing base (2fc6472) to head (f08df98).

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7882      +/-   ##
==========================================
+ Coverage   75.45%   75.46%   +0.01%     
==========================================
  Files         101      101              
  Lines        8311     8311              
  Branches      218      218              
==========================================
+ Hits         6271     6272       +1     
+ Misses       2038     2037       -1     
  Partials        2        2              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jasnell]

I want to make sure this has plenty of time to be reviewed by both @nodejs/TSC and @nodejs/marketing before it is landed so I'm dropping the red X on it for the time being. I'll review the changes in detail likely in the next day or so.

[AugustinMauroy]

You should add example here like position tech wise or something else

[ovflowd]

@avivkeller let's not jump the gun please. Also, let any administrative PR against this repo to be done either by the TSC or the maintainers of this team, thank you!

[avivkeller]

@avivkeller let's not jump the gun please. Also, let any administrative PR against this repo to be done either by the TSC or the maintainers of this team, thank you!

I believe that documenting our governance procedures in response to issue #7773 represents a constructive contribution rather than premature action, and it still requires ample time to be reviewed by the TSC. The miscommunication in that issue highlighted a gap in our documentation regarding governance procedures. That directly impacts collaborator experience and team effectiveness.

I believe that clarifying procedures falls under the responsibility of all team members, not exclusively team maintainers. As active collaborators, we all share responsibility for improving our documentation and processes. The current team structure, as documented, does not establish a hierarchical difference between team members and maintainers with respect to process documentation authority.

[bmuenzenmeyer]

the root of the problem, in my opinion, is that content vs code only accounts for two pillars of our site

• content
• code
• UX / design (missing)

This PR should address that

[avivkeller]

Clearly I may have misinterpreted the situation as ready for a path forward via administration document changes, and that was not the case. Let's wait until the next TSC meeting before making any rash decisions.

@ovflowd Apologies if my prior comment was dismissive of your opinion, which I do value.

[aduh95]

IMO it'd be more productive to keep a consensus-seeking (I guess we need to define among what group, IMO it should include Node.js Collaborators) process for all those topics, and have "The TSC serves as the final arbiter where required." for the case where consensus cannot be reached.

[aduh95]

IMO it's weird to treat feedback from TSC members as special, any project member is entitled to an opinion.

[ovflowd]

@avivkeller let's not jump the gun please. Also, let any administrative PR against this repo to be done either by the TSC or the maintainers of this team, thank you!

I believe that documenting our governance procedures in response to issue #7773 represents a constructive contribution rather than premature action, and it still requires ample time to be reviewed by the TSC. The miscommunication in that issue highlighted a gap in our documentation regarding governance procedures. That directly impacts collaborator experience and team effectiveness.

I believe that clarifying procedures falls under the responsibility of all team members, not exclusively team maintainers. As active collaborators, we all share responsibility for improving our documentation and processes. The current team structure, as documented, does not establish a hierarchical difference between team members and maintainers with respect to process documentation authority.

You make solid and good points, and I agree there’s nothing in the website team’s guidelines that restricts opening such PRs only to me or @bmuenzenmeyer.

That said, I do believe that PRs like this benefit from having an issue opened first and some prior conversation, ideally involving maintainers or the TSC. Otherwise, we risk making significant changes—like clarifying TSC oversight—without the input of those who should be involved, which can be a bit ironic given the nature of the change.

I appreciate your contributions and understand that these PRs are complex. My hope is to encourage collaboration and shared awareness so no one feels exposed by tackling these types of changes alone.

At the same time, I recognize there’s a lot of heat around this topic right now. For that reason, it might be best to pause important decisions or changes until we’ve cooled down a bit and had the chance to align.

Again, I agree that any collaborator can open such PRs, and your effort to improve the process is appreciated.

[ovflowd]

Clearly I may have misinterpreted the situation as ready for a path forward via administration document changes, and that was not the case. Let's wait until the next TSC meeting before making any rash decisions.

@ovflowd Apologies if my prior comment was dismissive of your opinion, which I do value.

No harm done 🫶

[aduh95]

There's no such thing as a disagreement between two teams, it's always a disagreement between project members. You could phrase it as "a disagreement between a majority of the Website Team and a majority of the TSC voting members", but IMO it'd be more useful to define a strategy for a disagreement between any project member.