Skip to content

Update charter with communication responsibilities #1754

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 20 commits into
base: main
Choose a base branch
from
Open

Update charter with communication responsibilities #1754

Changes from 15 commits
Commits
Show all changes
20 commits
Select commit Hold shift + click to select a range
dafb146
Update charter with communication responsibilities
RaisinTen Jun 27, 2025
04b59af
Update TSC-Charter.md
RaisinTen Jun 27, 2025
45fe537
Update TSC-Charter.md
RaisinTen Jun 27, 2025
3eecd4f
Update TSC-Charter.md
RaisinTen Jun 27, 2025
b74e810
Update TSC-Charter.md
RaisinTen Jun 28, 2025
2107db1
Update TSC-Charter.md
RaisinTen Jun 28, 2025
a198eee
Update TSC-Charter.md
RaisinTen Jun 28, 2025
934c437
Update TSC-Charter.md
RaisinTen Jun 28, 2025
d0b783c
Update TSC-Charter.md
RaisinTen Jul 1, 2025
eee844d
Update TSC-Charter.md
RaisinTen Jul 1, 2025
30fd079
Update TSC-Charter.md
RaisinTen Jul 1, 2025
5eb3c7c
Update TSC-Charter.md
RaisinTen Jul 2, 2025
3a75b16
Update TSC-Charter.md
RaisinTen Jul 2, 2025
ad6cace
Update TSC-Charter.md
RaisinTen Jul 2, 2025
d6c528c
Update TSC-Charter.md
RaisinTen Jul 2, 2025
29dc949
Update TSC-Charter.md
RaisinTen Jul 2, 2025
a59433e
Update TSC-Charter.md
RaisinTen Jul 3, 2025
ec7ff6e
Update TSC-Charter.md
RaisinTen Jul 3, 2025
e2d0b70
Update TSC-Charter.md
RaisinTen Jul 3, 2025
35266ac
Update TSC-Charter.md
RaisinTen Jul 3, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions TSC-Charter.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -74,9 +74,32 @@ including:
* Development process and any coding standards.
* Mediating technical conflicts between Collaborators or Foundation
projects.
* Establishing and stewarding a consensus-seeking process to represent the technical community and its work in external communications.

The TSC will define Node.js project’s release vehicles.

The communication oversight responsibilities include:

* Technical development processes of the project
* Releases and release announcements
* Technical documentation
* Contributor onboarding and conduct
* Project governance
* Technical direction

Specific exclusions from the communication oversight responsibilities include:

* Brand marketing
* Fundraising and financial sponsorship (including, but not limited to, the OpenJS Foundation's financial sponsorship of the project)
* Legal matters
* Marketing/ community events

Communication on excluded oversight areas that intersect with included responsibilities will be handled in collaboration with the OpenJS Foundation.

The community may establish project-specific communication channels, such as social media accounts and discussion forums, subject to the above requirements. If the communication channels are used to represent the project, administrator access should be granted to both the TSC and the Foundation for oversight, while the day-to-day operation can be delegated to another party as long as they respect the consensus seeking process of the project.

If the TSC becomes aware of external communications that appear inconsistent with the project’s consensus, it may engage with the communicating party, directly or through appropriate channels, to help align the message with the project’s consensus-seeking processes.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This mixes responsibilities and a consensus-seeking approach. If this needs to be written somewhere, it's not in this section of this document.

You can't do marketing and brand management by committee; it's too slow and it doesn't work (we tried this in the past).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This documents that when someone speaks on behalf of the project on social media that is inconsistent with the project’s consensus, or without confirming consensus, the TSC would communicate and align the two. For example if someone that’s seen as a representative of the project - or the official account itself - declares “we’ll deprecate this feature in the next release” but there is no consensus within the project whether it should be deprecated, the TSC would communicate to them to get it corrected. This is what we’ve already been doing (not necessarily deprecation but I think you'd probably remember similar things that happened in the past).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly, this is tending towards way too much bureaucracy and process than what is going to be helpful/useful. Yes, we should all be careful about what we say before we're certain there's consensus but it's not something we need formal processes around.

Copy link
Member

@joyeecheung joyeecheung Jul 3, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's case by case on whether there needs formal process:

  1. In the case of technical work, the process already happens on GitHub and likely is very obvious to TSC members who know what seals the consensus and when there's no clear consensus (e.g. removing/keeping corepack, standards body representation).
  2. In the case of community representation, IMO a org-wide vote was already a good enough precedence.

The idea isn't that the TSC must be very hands-on on how the representation is manifested, just that those who declares representation should ensure, at least by themselves, that the representation aligns with the consensus that's already been built, that part doesn't need involvement from the TSC, but obviously they can always ask for help from the TSC. And when the two aren't aligned, the TSC is in a position to remind them. Without granting TSC this in the charter, for example I could just go to TC39 and frame my own opinion as the Node.js's project opinion (I would not need to be explicit, just some misleading use of "we" would be more than enough, and one does not need to bring up the trademark because .js is silent), and no one has the right to correct me as long as I didn't go there as a OpenJS delegate - not that I would do it at TC39, or I generally try to open my words with "I don't speak for the project and this is just my personal impression" whenever people ask me "what's Node.js's opinion", but I don't see anything this charter or that of the CPC that grants anybody a position to correct me, so I would only be bound by my own conscience.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are also cases where there is consensus within the project to externally communicate something which hasn't been communicated yet. When someone wants to drive such communication forward, if it gets blocked by the foundation, it is really hard to make any progress as individuals. There needs to be some process for the TSC to engage with the communicating party to resolve such cases.


## Section 5. Node.js Project Operations

The TSC will establish and maintain a development process for the
Expand Down