nodejs
Add blog post publishing guidelines
After discussing with @rginn, I'm adding the updated guidelines for publishing blog posts on the Node.js website.
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 |
![vercel[bot] avatar](https://avatars.githubusercontent.com/in/8329?v=4 "Published by a pub.dev verified publisher"){kind=small}
Codecov Report
:white_check_mark: All modified and coverable lines are covered by tests.
:white_check_mark: Project coverage is 73.40%. Comparing base (c375408) to head (b395a81).
:warning: Report is 184 commits behind head on main.
:white_check_mark: All tests successful. No failed tests found.
Additional details and impacted files
@@ Coverage Diff @@
## main #7860 +/- ##
==========================================
- Coverage 75.44% 73.40% -2.04%
==========================================
Files 101 173 +72
Lines 8305 14949 +6644
Branches 218 468 +250
==========================================
+ Hits 6266 10974 +4708
- Misses 2037 3973 +1936
Partials 2 2
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
![codecov[bot] avatar](https://avatars.githubusercontent.com/in/254?v=4 "Published by a pub.dev verified publisher"){kind=small}
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.
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.
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.
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.
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
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.
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...
Explaining my suggestions somewhere else in case it gets folded:
- 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.
- 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.
- 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.
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.
We've never applied this same rubric to any other teams that I'm aware of. We shouldn't single out the marketing team just for this.
We've never applied this same rubric to any other teams that I'm aware of.
I do remember this was brought up in the build team before (which was where I learned the word "bus factor") in the context of sharing accesses to various resources and there is a vague consensus to increase the bus factor whenever we can (as in, I never saw anyone against increasing the bus factor in the limited build team discussions I was in).
