Proposal: Social Communication Plan

[jasnell]

There's been some discussion lately here and there around different ideas for management of the projects social media and blog footprint. This discussion has focused on misunderstandings over who is largely responsible for the management of these spaces and whether they are the responsibility of the Foundation or the project.

To be certain, the Foundation owns the Node.js brand as well as the responsibility for all marketing efforts around that brand. The TSC (and by extension, the project) owns responsibility for setting the technical direction of the project including technical documentation. Even with this division of responsibilities in place, it is critical to keep in mind that everyone is working in good faith to advance the project and the brand in the ecosystem. There are no bad actors but there have been some disagreements on the process forward.

I'd like to see if we can get beyond those disagreements with a concrete proposed path forward.

Ultimately, it is the Foundation and not the project that ultimately owns all official marketing responsibility in the project. There have been questions raised about whether social media accounts like the Node.js bluesky account qualify as a marketing channel or a technical documentation channel -- and frankly, the answer is: it's both.

Per the TSC charter, the TSC (and by extension the project) has NO responsibility assigned for marketing activities.

Subject to such policies as may be set by the CPC, the TSC is responsible
for all technical development within the Node.js project, including:

* Setting release dates.
* Release quality standards.
* Technical direction.
* Project governance and process.
* GitHub repository hosting.
* Conduct guidelines.
* Maintaining the list of additional Collaborators.
* Development process and any coding standards.
* Mediating technical conflicts between Collaborators or Foundation projects.

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

The charter goes on to say:

The TSC and entire technical community will follow any processes as may be
specified by the OpenJS Foundation Board relating to the intake and license
compliance review of contributions, including the OpenJS Foundation IP Policy.

The TSC itself adopted this charter, with the approval from the CPC and the Foundation -- giving itself NO responsibility for marketing communication.

Unfortunately, however, this has led to a gap in expectations. Does the Foundation or the project determine what content is published on the nodejs.org blog? Does the Foundation or the project determine what content is published in the social media channels. Folks on the Foundation side -- the ones actually responsible for marketing and brand management -- rightfully claim that blog content and social media content are largely brand marketing. Folks on the project side -- the ones responsible for technical communication and documentation about the project -- rightfully claim that blog content and social media content are also technical documentation. Both views are correct and we should act accordingly.

To that end, I propose the following:

Split Social Media Channels

We split the social media presence on each platform into two distinct account handles, e.g. something like @nodejs for the marketing content and @nodejs-dev for the technical content.

While some have argued that splitting the channels like this is not ideal (I agree somewhat) there is significant precedence throughout the ecosystem for such splits)... and the possible downsides of such a split are far outweighed by internal fighting over who gets to control the content. Splitting the accounts is a compromise position.

To facilitate splitting, responsibility for management of the technical channel would be documented within the TSC charter as one of the responsibilities of the TSC, following ratification from the CPC/Foundation. The Foundation would continue with their responsibility for management of the marketing channel.

What exactly we call these channels is not really all that important. We could, for instance, decide (jointly, with the Foundation) that the existing @nodejs channels are the technical channel and that a new @nodejs-brand or @nodejs-marketing channel is necessary. I personally would leave such decisions up to the marketing experts (the folks who have actually been trained and have experience with these matters) at the Foundation to decide.

Clearer Blog Content Categories

Interestingly, the TSC charter does not mention at all who is actually responsible for the nodejs.org website design or content. However, it is the Foundation that owns the domain name, the Foundation that owns the trademark, and the Foundation that has licensed to the project the right to use the trademark. Given that the management responsibility of the website is undocumented, and unestablished, this would clearly suggest that the website is the Foundations responsibility.

That said, it is the Website team (@nodejs/nodejs-website) and Web infra team (@nodejs/web-infra) that have largely taken ownership over the design and general content of the Website.

My proposal is that we make this official. Specifically:

1. We would add to the TSC charter that the TSC will take responsibility for the technical implementation and overall UX of the website subject to all design/visual changes being approved by the Foundation (under the idea that visual design elements are a component of brand management). The TSC would further officially delegate that responsibility to a fully chartered Website Working Group that would be tasked with working with the Foundation marketing team. This would be subject to the same general consensus rules that mean the TSC would serve as the fallback should natural consensus be unreachable, but it also means that the Website Working Group would have a certain amount of autonomy over the actual implementation of the website -- they would still be expected to work with the Foundation marketing and infrastructure teams, however, since the nodejs.org domain is owned by the Foundation and only used by the project under license.

2. In this, the Foundation retains the right to request, or even insist, on the inclusion of certain pieces of Foundation-related content in the blog. This may include links and other content elements that the Foundation deems necessary.

3. Content in the nodejs.org blog would fall under five distinct categories, each of which falling under a different groups responsibility:

• Foundation Announcements -- Messages/posts from the Foundation itself. These fall entirely under the responsibiity of the Foundation marketing team.
• Project Announcements -- Messages/posts from the TSC/projects. These are expected to essentially be technical communication.
• Release Announcements -- Messages/posts about Node.js releases, falling entirely under the responsibility of the Release team. These are a subset of the Project Announcements.
• Vulnerability/Security Annoucenements -- Messages/posts about Node.js security updates, reported vulnerabilities etc. These are a subset of the Project Announcements.
• Event Announcements -- Messages/posts about Events/Conferences. These are a subset of the Foundation Announcements.

Project Announcements are expected to be limited to technical documentation, technical communication about the project. It would not be appropriately, for instance, for something to be published under the "Project Announcement" categories that announces some new community ambassador program (which is really a form of marketing program) or fund raising effort, etc. Examples of "Project Announcements" that aren't Release or Vulnerabilities would be technical descriptions of improvements recently landed in the codebase, descriptions of ongoing technical efforts such as where things are at with the implementation of QUIC, the implementation of pointer compression, or reports about ongoing discussions and collaborator summits, etc. Specifically, these deal with technical communication and not brand communication.

Foundation Announcements are expected to be limited to marketing/brand/event management. These may include posts discussing third party strategic partnerships, fund raising efforts launched by the Foundation, etc. Specifically, these deal with marketing/brand communication and not technical subjects.

Content that straddles the line between these would fall jointly in both categories.

The idea here is that, ultimately, it is the Foundation that is responsible for Foundation Announcement content and the project for Project Announcements.

Content Review Team

While all responsibility for reviewing all posts made to the node.js blog and social media channels are technically the responsibility of the Foundation marketing team, I am proposing that a joint Project + Foundation Content Review team, composed of Foundation Marketing team members and Project collaborators approved by the TSC, be established. The responsibility of this team is to review and approve content posts to all media (blogs, social channels, etc). The idea is that it really shouldn't be one or the other making decisions, given that we're all working towards a common goal, it should be a combined, cooperative effort to decide what content ends up where, with everyone assuming good faith on the part of everyone else.

Note that this plan would need the explicit approval of both the TSC and the Foundation in order to move forward.

@nodejs/tsc @nodejs/marketing

[RaisinTen]

In the joint content review team, who will have the final say if there is a disagreement between the project and the foundation?

[avivkeller]

Content in the nodejs.org blog would fall under five distinct categories, each of which falling under a different groups responsibility

I don't think these categories accurately cover the range of content we publish on the blog. For example, what category would the Pride blog posts (as per the vote) fall under?

I feel that a sixth, "Community"-like category should also be added to encompass posts like this.

[jasnell]

The Pride post would likely fall jointly under both Foundation and Project Announcements.

[ovflowd]

The Pride post would likely fall jointly under both Foundation and Project Announcements.

Right now posts can only be under one category (just a technical FYI that we can change, if needed)

[mcollina]

I’m +1 on this proposal.

[ovflowd]

We split the social media presence on each platform into two distinct account handles, e.g. something like @nodejs for the marketing content and @nodejs-dev for the technical content.

From an end-user perspective, I believe this would be quite confusing. Having split social media handles could unintentionally suggest a divide within the project itself. Personally, I strongly prefer the idea of a single unified account. Most of the content we publish—release updates, security advisories, and broader marketing material—belongs together in one place for the sake of clarity and visibility. Splitting this up risks important updates being missed, even if the main handle reposts them. I also appreciate the current model, where a coordinated social/media team works closely with project stakeholders to curate content that goes out via the official channel.

That said, it is the Website team (@nodejs/nodejs-website) and Web infra team (@nodejs/web-infra) that have largely taken ownership over the design and general content of the Website.

That’s an interesting observation. Within the Website team, we’ve intentionally drawn a line between “content” and “code” responsibilities, as described in the content vs code guidelines. While some UX topics can lean into either technical or marketing spheres, we’ve been mindful not to position ourselves as owners of content decisions. That said, there's an ongoing tension: the Website team often feels like unpaid laborers executing decisions made by the TSC or Foundation—without always being consulted or having sufficient say in those decisions. A recent example of that dynamic is issue #7773, which placed us in a difficult and unclear position.

Personally, I’d be okay with the Website team being formally chartered, but it does raise important considerations. For instance, the Web Infra team owns several pieces of key infrastructure (e.g. the website build pipeline, API docs tooling, and release Cloudflare workers), while the Website team handles the day-to-day development of the site. If we were to charter something, it might make more sense to charter the broader Web Team (which includes both Website and Web Infra), rather than just the Website team in isolation.

Importantly, I believe the Website team—or any future Web Working Group—should not have formal ownership over project content. That responsibility should continue to sit with the TSC or Foundation, depending on the nature of the content (e.g. technical blog posts vs marketing announcements).

There are gray areas, like “how big should a button be for the ESP program?”—which touches both UX and marketing. These cases highlight the need for clear, documented boundaries and expectations.

Lastly—and I say this with care—since this proposal directly affects a team I help maintain, I’d appreciate if we could be included in the decision-making process early and clearly. Otherwise, it ends up feeling like our team is just being moved around without context or agency. I’m +1 on the broader direction of the proposal. All I’m hoping for is better collaboration, less friction, and a shared sense of ownership between the project and the Foundation. We’re all working toward the same goal.

[avivkeller]

Personally, I’d be okay with the Website team being formally chartered, but it does raise important considerations. For instance, the Web Infra team owns several pieces of key infrastructure (e.g. the website build pipeline, API docs tooling, and release Cloudflare workers), while the Website team handles the day-to-day development of the site. If we were to charter something, it might make more sense to charter the broader Web Team (which includes both Website and Web Infra), rather than just the Website team in isolation.

I'd be more than happy to draft a charter in #972 (a nodejs/web / nodejs/web-team repository)?

[ovflowd]

Personally, I’d be okay with the Website team being formally chartered, but it does raise important considerations. For instance, the Web Infra team owns several pieces of key infrastructure (e.g. the website build pipeline, API docs tooling, and release Cloudflare workers), while the Website team handles the day-to-day development of the site. If we were to charter something, it might make more sense to charter the broader Web Team (which includes both Website and Web Infra), rather than just the Website team in isolation.

I'd be more than happy to draft a charter in #972 (a nodejs/web / nodejs/web-team repository)?

Appreciate that, but let's not jump ourselves ahead and let the right people work on this and the right time.

[joyeecheung]

I personally would leave such decisions up to the marketing experts (the folks who have actually been trained and have experience with these matters) at the Foundation to decide.

I feel that this should be something decided by the followers, not by marketing experts. At the end of the day, if most people are following @nodejs for technical content (my hunch is that that's what they want to see, based on limited responses in the Bluesky survey opened yesterday, but it already gives me enough clue. I doubt how much the Twitter audience would differ), filling the timeline with sponsorship announcement/request and promotional content would diminish the value of the account for them. And I don't think it's something that either the marketing team or the project contributors have enough insight about without a survey.

Content in the nodejs.org blog would fall under five distinct categories, each of which falling under a different groups responsibility:

I agree more categories with different review responsibility would be an improvement, though I think the five categories aren't very exhaustive and we should intentionally allow iteration of the categories (personally I would like to see a comeback of https://nodejs.org/en/blog/weekly/, for example)

Regarding charter changes, I think we need to clarify and explicitly include "technical communication" into the scope of TSC responsibilities, and it should be the TSC that defines the development process of the technical communication. Whenever there is an intersection of technical and marketing content, it should be reviewed by the technical side of the project - either the TSC itself, or a WG/team delegated by the TSC - and I would suggest it must be done on GitHub, no matter public or private, to prevent marketing staff from editing the technical communication by paraphrasing and publishing without further technical review, leading to technical errors in the communication, which happened to the 22 and 23 release announcements.

[ljharb]

@joyeecheung wouldn't polling the much larger set of twitter followers give better insight into what content builds a following?

[joyeecheung]

wouldn't polling the much larger set of twitter followers give better insight into what content builds a following?

To clarify that is what I suggested too - we need to have a larger scale of survey about whether followers want to see a split and if they do, whether they'd prefer to see technical content or marketing content from nodejs account. I am just taking the Bluesky survey as an early hint, not suggesting to use that to decide how other platforms operate.