Add blog post publishing guidelines

[mcollina]

After discussing with @rginn, I'm adding the updated guidelines for publishing blog posts on the Node.js website.

[vercel]

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

Name	Status	Preview	Updated (UTC)
nodejs-org	✅ Ready (Inspect)	Visit Preview	Jun 12, 2025 2:01pm

[mcollina]

cc @nodejs/tsc

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.44%. Comparing base (c375408) to head (b395a81).
Report is 8 commits behind head on main.

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7860   +/-   ##
=======================================
  Coverage   75.44%   75.44%           
=======================================
  Files         101      101           
  Lines        8305     8305           
  Branches      218      218           
=======================================
  Hits         6266     6266           
  Misses       2037     2037           
  Partials        2        2           

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

[Copilot]

Pull Request Overview

This PR adds a new section to the governance document outlining the process and approvals required for publishing blog posts on the Node.js website.

• Introduces a "Blog post publishing guidelines" section.
• Specifies mandatory steps for scheduling and approvals.
• Defines an exception for minor/patch release announcements.

Comments suppressed due to low confidence (2)

GOVERNANCE.md:94

• [nitpick] Consider adding a comma after "blog posts" for clarity: "The following guidelines apply to all blog posts, except minor or patch release announcements:"

The following guidelines apply to all blog posts except minor or patch release announcements:

GOVERNANCE.md:96

• [nitpick] List items should start with a capital letter—change "each" to "Each" to match sentence casing.

1. each blog post _must_ have a target publishing date and time. If scheduled publishing is not possible, _the author_ (if privileged enough) or another delegated member would be responsible for landing.

[AugustinMauroy]

Why not putting tsc as code owner ?

[mcollina]

Why not putting tsc as code owner ?

That's an implementation detail, which is governed by governance. This PR updates the governance.
Surely, lets' do that as well.

[jasnell]

If we can pull together a nodejs/marketing team that has members from both the TSC and the foundation marketing staff, would it be enough here to say that the nodejs/marketing team must approve it... then that team can work out whatever process makes the most sense to it.

[bmuenzenmeyer]

does https://github.com/orgs/nodejs/teams/social suffice?

[mcollina]

@jasnell if both the TSC and OpenJS staff are members of the team, technically the TSC could approve this without asking them. This has a different meaning.

[jasnell]

Fair. If the new @nodejs/marketing team, then, is made up of Foundation marketing staff, I agree that requiring an approval from at least one person in both the @nodejs/tsc and @nodejs/marketing teams is ideal.

[joyeecheung]

I wonder if we should label the blog posts somehow differently between "official" content and community content, and give project contributors sufficient trust to manage the community content. Putting an approval chain on every blog post gives me the "you need to get approval from the management for everything you do" megacorp vibes and seems out of place for a community-driven OSS project.

[mcollina]

What kind of community content are we publishing on this blog? The vast majority posts are releases, and the rest are various kind of official announcements that represents the project in one form or another.

[joyeecheung]

What kind of community content are we publishing on this blog?

For example https://nodejs.org/en/blog/announcements/making-nodejs-downloads-reliable

The vast majority posts are releases, and the rest are various kind of official announcements that represents the project in one form or another.

I think that's because we are mostly only doing the bare minimum for content curation, which is not to say this is the best content we could put out. Personally I want to see the Node.js blog to be more like https://v8.dev/ - I participated in the writing of some of the content there despite not being a V8 team member/Google employee and I appreciated that we only needed technical review from V8 team members that reviewed the same technical work the posts were talking about. I think that's the kind of community content we should try to nurture, even if they are dwindling now, and treating everything on the blog as if they can only be official announcements means that the content would be biased towards official announcements. That's why I suggest the approval process should be based on the category of the content, unless we want to fully abandon the official blog as a channel to put out technically insightful content.

[avivkeller]

I don't think we need these guidelines explicitly stated, they seem to be implied. I feel like if we set @nodejs/TSC @nodejs/marketing as the CODEOWNERS of non-release blogs, it implies all of this information.

If we do insist on the inclusion of these guidelines, maybe they can go in the new "Adding Pages" document

[jasnell]

For example https://nodejs.org/en/blog/announcements/making-nodejs-downloads-reliable

I'm not sure how this counts as "community content". It was written by a member of the website team discussing the changes that were made to improve release downloads. That would put it in the project content category.

[joyeecheung]

I'm not sure how this counts as "community content". It was written by a member of the website team discussing the changes that were made to improve release downloads. That would put it in the project content category.

I think we might just have different definition of the community - here I mean "people who are not employed by the foundation or chartered to take on responsibilities, free of charge". I think even in this case, we should grant people sufficient trust. For example, I would say a review from the TSC or the marketing team for this article doesn't look super helpful unless any of us was specifically involved in the work described. Even as a member of the TSC I would trust the website team on the reviews of content about the development of the website more than myself.

What I am seeing from the current guideline is a lack of trust. I think there is a better way to go about this that would be closer to how PRs work in the organization in general...

[joyeecheung]

Suggested change

	2. each blog post _must_ be approved by @nodejs/tsc members _and_ OpenJS Foundation marketing staff.
	2. the pull requests adding or changing blog posts should notify @nodejs/tsc and @nodejs/marketing for reviews. In addition, reviews can be requested from teams with corresponding expertise.
	- Release announcements: `@nodejs/releasers`
	- Website: `@nodejs/website`
	- Security: `@nodejs/security`
	If there are no change requests and at least two approvals from the reviewing teams, after 48 hours on business days, the blog post is considered approved. If there is only one approval, the blog post needs to wait for at least 7 days. If the blog post needs to be fast tracked, a comment should be posted to request fast track, at least two thumbs up from the reviewing teams to the fast track request are needed to approve the blog post.

[joyeecheung]

Explaining my suggestions somewhere else in case it gets folded:

1. The marketing team has a bus factor of 2. AFAIK they are both based on U.S. west coast and seem to be in proximity to each other quite often. This is not a very optimal set up IMO.
2. There is no fast track in case incorrect information is missed during reviews and gets published. And again it's not great if this is bottlenecked on two people based on the U.S. west coast.
3. We should recognize neither the TSC nor the marketing team necessarily have the correct expertise to review all content. I think in that case we should trust the teams that have the correct expertise on this. That also altogether lower the bus factor even further.

If there is anything not compliant with the legal and branding requirements, 48 hours on business days + 7 days should be sufficient to catch problems, if that's already considered adequate for Node.js core reviews done by people who are not bound by employment to review PRs.