admin
admin copied to clipboard
nodejs
Proposal: Social Communication Plan
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:
-
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.
-
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.
-
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
In the joint content review team, who will have the final say if there is a disagreement between the project and the foundation?
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.
The Pride post would likely fall jointly under both Foundation and Project Announcements.
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)
We split the social media presence on each platform into two distinct account handles, e.g. something like
@nodejsfor the marketing content and@nodejs-devfor 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.
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)?
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-teamrepository)?
Appreciate that, but let's not jump ourselves ahead and let the right people work on this and the right time.
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.
@joyeecheung wouldn't polling the much larger set of twitter followers give better insight into what content builds a following?
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.
It should be stressed that social media polls are in no way statistically representative and, while they can be anecdotally informative, they should not be used as the basis of formal decision making. They serve a purpose, yes, but let's not make the mistake of relying on them.
I personally prefer to pay attention to the advice and guidance of trained marketing experts (who know more about the node.js ecosystem than some appear willing to give them credit for) over hunches and unreliable Twitter polls.
Not sure if my comment was missed, so I'll just ask again:
In the joint content review team, who will have the final say if there is a disagreement between the project and the foundation?
It should be stressed that social media polls are in no way statistically representative and, while they can be anecdotally informative, they should not be used as the basis of formal decision making. They serve a purpose, yes, but let's not make the mistake of relying on them.
I agree that they are not always representative, especially when it comes to matters that happen outside the social media space, but this is a special case where it's about the social media account itself and strictly about social media space. Reaching out to the community for feedback before making a decision also helps us build an image of being transparent and acceptive to feedback from the community, which the project has been criticized of lacking on social media quite frequently as far as I can tell from my timeline.
However, for bluesky, it's not about the current follower base as much as it's about the much larger existing twitter follower base, and how to repeat that success on bluesky. Social media here is acting as a broadcast channel - it's not really aimed at contributors or potential contributors (we have github for that), it's aimed at users, which are a much much larger group.
However, for bluesky, it's not about the current follower base as much as it's about the much larger existing twitter follower base, and how to repeat that success on bluesky. Social media here is acting as a broadcast channel - it's not really aimed at contributors or potential contributors (we have github for that), it's aimed at users, which are a much much larger group.
I am confused, where is the bluesky v.s. Twitter perspective from? Or why is it about contributors, not users? Aren't we talking about a proposed survey across social media, targetting followers, that has not yet happened?
I'm speaking to the underlying goals of even doing a survey. Since Twitter has the largest following, surveying anything but that isn't going to be helpful (since the primary point of a social media brand account is to increase the legit-follower base); since the Twitter account is doing well, it seems like the folks running it have made good choices, and we should just be repeating those choices on bluesky.
since the Twitter account is doing well, it seems like the folks running it have made good choices, and we should just be repeating those choices on bluesky.
I think we need to recognize that in the past year, the Twitter account has missed multiple release announcements, and some announcements were missing details about the release because they were posted in a hurry, some contained inappropriate descriptions such as being excited to announce ending of active LTS, it also posted content with factual errors, and these has led to questions on Twitter. I wouldn't go as far as saying these are good choices that we should repeat on Bluesky. What we can say is probably that the follower count is growing. How much of that is attributed to marketing efforts and how much of that is attributed to Node.js itself being maintained and improved reasonably well is uncertain. And we need to do better to prevent these mistakes from happening again and raising questions on Twitter.
@joyeecheung I think the root cause that lead to those problem was resolved, and things have been running smoothly again.
I'm pretty sure those temporary personnel issues have been resolved and aren't likely to happen again.
I think the root cause that lead to those problem was resolved, and things have been running smoothly again.
I wouldn't say the root cause is fixed - the root cause is the low bus factor, which is still low. I think that is close to claiming that the deadlock issue has been fixed by the v8 task priority patch, just because the deadlock is not showing up in the CI for now doesn't mean the root cause is fixed, the architecture can still lead to deadlocks in the next V8 upgrade, we are just procrastinating a real fix. It can also be described as the current situation is temporary and are likely to happen again when there are any personnel changes.
Also, since it was suggested that we should repeat the same choices on Bluesky - how do we make sure Bluesky doesn't end up like Mastodon? Unless you think the Mastodon account is doing very well.
I'm not quite following the concerns being asserted here and feel like this is straying just a bit off topic.
Are there reasons folks believe the proposal as stated would not lead to improvements, or would not be an improvement over the current or past states? Are there concrete suggestions folks have to improve this proposal? Are there specific reasons you believe this proposal would make things worse? Are there parts of this proposal that we can agree on as a basis for forming a better proposal?
I'd rather not dwell on past issues here as there are better venues for that for those who feel it necessary. Instead, I'd like for us to focus on concrete positive steps for moving forward.
In the joint content review team, who will have the final say if there is a disagreement between the project and the foundation?
I would expect the proposed content team to develop its own processes for making content decisions. I would consider it inappropriately premature to try imposing a conflict resolution strategy for a committee that doesn't exist yet and wouldn't find it productive or positive to assume there would be conflicts in advance. It's best to let that team decide that for themselves.
That said, I would generally expect the process to be no different than if the disagreement were between two members of the project or two members of the Foundation representation. I can't see a reason to think a disagreement between a project representative and a foundation representative requires any special call-out here.
Overall, however, my assumption is that on matters relating to marketing, brand, finances, fundraising, events, and community engagement, etc it is only right to defer to the Foundation's representatives; and for matters relating to technical content and project operations, it would be only right to defer to the project representatives. That is, after all, their respective roles and the topics on which each has the most context/expertise.
Are there reasons folks believe the proposal as stated would not lead to improvements, or would not be an improvement over the current or past states? Are there specific reasons you believe this proposal would make things worse?
I think so far at least two people (and some thumb ups) stated that splitting the accounts would make things worse. The compromise I proposed was to run a follower survey and let followers decide, or at least use that as a basis, though it was dismissed with the grounds that we should appeal to authority, and I was providing justifications for the alternative.
Are there concrete suggestions folks have to improve this proposal?
To quote https://github.com/nodejs/admin/issues/977#issuecomment-3001258778
the five categories aren't very exhaustive and we should intentionally allow iteration of the categories 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.
AFAICT there's no response to these suggestions so far
Are there parts of this proposal that we can agree on as a basis for forming a better proposal?
See the above points
I was more referring to the most recent additional follow on conversation that seemed to me to be starting to stray off course. My comment here https://github.com/nodejs/admin/issues/977#issuecomment-3011887567 is an attempt to steer the conversation back onto a productive course.
... though it was dismissed with the grounds that we should appeal to authority, and I was providing justifications for the alternative.
I'm confused.. nothing has been dismissed so I'm not sure what you're referring to with this. It would imply that decisions have been made which is not the case. Different opinions and perspectives have been expressed but that's hardly a dismissal. I appreciate the concrete on-topic feedback received so far. There are some comments I personally haven't yet directly responded to because I haven't yet formulated an opinion on those and I'd like to see what additional relevant input we receive.
So far, for the social channels, the options are the table are, as I understand them are:
- Split the channels as proposed.
- Ask current followers of the channels via some form of survey.
- Maintain the status quo.
Likewise with the content categories. I personally haven't reponded because I don't yet have response. I'm waiting to see what other constructive feedback is received before forming and stating an opinion.
So far, for the content categories, it appears the options on the table are:
- Adopt the categories as proposed.
- Expand the categories to some as yet undefined set? (referring to your suggestion here: https://github.com/nodejs/admin/issues/977#issuecomment-3001258778)
- Maintain the status quo.
For the charter, the options appear to be:
- Update the TSC charter to address technical communication responsibilities (tho we appear to disagree a bit on exactly what this covers maybe?.. so we'd need clarification on that.. that actual details of what process we'd follow are likely best deferred to later but I could be mistaken on that).
- Maintain the status quo
Have I missed any?
FWIW, I believe the comments that started to stray off topic (not entirely but also not in a way that I feel has been constructive to the conversation) include: https://github.com/nodejs/admin/issues/977#issuecomment-3005947751, https://github.com/nodejs/admin/issues/977#issuecomment-3005971783, https://github.com/nodejs/admin/issues/977#issuecomment-3006029767, and https://github.com/nodejs/admin/issues/977#issuecomment-3006508067 ... these don't seem to be focused on the actual details of the proposal but instead focus on past issues that, while admittedly generally related, are likely better discussed in other threads. Again, just my point of view.
(FWIW, I may have inadvertently contributed to helping the conversation stray off course with my comment here https://github.com/nodejs/admin/issues/977#issuecomment-3003112702 perhaps?)
FWIW, I believe the comments that started to stray off topic (not entirely but also not in a way that I feel has been constructive to the conversation) include:
Feel free to fold them if you think they are off topic (can't say about the others, but you can fold mine).
Maybe we should also add:
Content that would be interpreted as representing the opinion of a project should be reviewed by the TSC and the designated foundation staff, and preferably not reposted from personal accounts unless agreed that it would be better reposted than posted.
(tho we appear to disagree a bit on exactly what this covers maybe?.. so we'd need clarification on that.. that actual details of what process we'd follow are likely best deferred to later but I could be mistaken on that).
I think maybe a easy rule of thumb would be: does this involve using, or running/administering a Node.js instance? The motivations is:
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.
One of the key reason to why the incident happened was, IMO, that the marketing staff do not know necessarily have the expertise to tell the difference between "a feature X is enabled by default" or "feature Y that improves the usage of feature X is enabled by default" (it's Y being enabled by default, not X), or "X is enabled by default" itself is a very ambiguous concept that cannot be used on its own. This is a case where review from the technical side of the project is needed to ensure accuracy and cannot be paraphrased without review. And this is best done on GitHub IMO, one of the reasons why the major release announcements contained these errors was that it was reviewed in private Google docs shared to only a few people, and later communication was done on Slack.
One of the motivation that we were given for using private Google doc was that major release should go through embargo for publicity, it might be a valid expert marketing opinion in a non-technical context, but in subsequent meetings we explained that major release aren't even necessarily the ones that should be publicized the most - many important features come out in minor releases, not major, or this is imposed by the nature of semver (IMO https://bsky.app/profile/antfu.me/post/3lfovdpfu322s put it quite well). I think this is also where technical insight about releases is needed and why it should be the TSC that defines the development process of these communications - technical contributors would be more likely to notice that the entire release is developed in public and the community likely already catch wind about important things as PR lands or even right after PR is opened, so embargo is somewhat meaningless. Also only those more knowledgable about the release process would be likely to notice that by nature, major releases isn't necessarily the most exciting release (it only sounds "major" if you take the English word at face value as a marketing term, but the actual meaning of major in the context of semver is "breaking" which is probably the opposite of..exciting, depending on who you ask)
I have created a PR with the charter change in https://github.com/nodejs/TSC/pull/1754 and added Joyee as a co-author. It would be better if discussions specifically about that happens there.
I would expect the proposed content team to develop its own processes for making content decisions. I would consider it inappropriately premature to try imposing a conflict resolution strategy for a committee that doesn't exist yet and wouldn't find it productive or positive to assume there would be conflicts in advance. It's best to let that team decide that for themselves.
While the specific formation of committee does not yet exist, I think disagreement of the potential formation already happened in the past.
- Whether to repost a personal opinion from a personal account from the official account, and whether it's necessary to consult the opinion of other project members before doing so
- Whether to spread the word about the dire financial situation of a non-profit organization supporting our CI infra.
- Whether to highlight the work done by an individual contributor, even when they are not employed by a foundation member company
- Whether the content review should be done on GitHub, or should be done using Google forms and Slack
As I wrote in https://github.com/nodejs/TSC/pull/1754#issuecomment-3019952423 I think the TSC's role is to
The TSC's role is to establish process to build representation via consensus seeking, and make sure everyone, including itself, respect the process before a representation of the project is made. It's what we've effectively been doing for years.
On the TSC's side I think we can establish some principles based on how we generally already operate in the project space, to make sure the communication is always aligned with the representation of the project. It does not have to be a TSC member to personally enforce the principles and could be delegated to someone not on the TSC as long as the principles are respected. AFAICT, these seem to be the principles we already abide in the project and can be used as a basis:
- The communication of the project should reflect the project itself - both the work and the collective behind the work - as closely as possible
- Representation of the project should be built by collecting consensus among project members. It can be delegated to a smaller group to speed up day-to-day operation, but when in doubt, the smaller group should actively seek feedback from the wider group.
- Whether a request should be accepted should be primarily based on whether it helps/hurts the project itself, no matter it's affiliated with a specific organization or not. Just like project development, the communication development shouldn't be pay-to-play.
- Decision making should be done in public as much as possible, and should be collaborative. Whenever there is a doubt about whether the final draft is sufficiently agreed, ask instead of assume.