Bluesky account & automated social media content management

[joyeecheung]

For context, a huge influx of developers have started on Bluesky since last week. Many Node.js contributors and folks in the bigger Node.js ecosystem have joined. I personally joined on Nov 3 because I saw a flash mob from the JS tooling folks on Twitter/X (the platform people are leaving from), and encouraged others to join in the nodejs-core channel on slack because the community there looked great, many of us who were in NodeConf EU/Node.js collaboration summit have joined Bluesky this week and my impression is that we interacted and posted a lot more than what we did on Twitter/X over the week.

There have been questions about why Node.js still isn't on the platform, @JakobJingleheimer asked on the nodejs-social channel for it on Nov 4 and so far the account has not yet happened - I assumed it was because everyone was busy with the NodeConf EU/collaboration summit this week, but we also had people like @targos at the summit who had access to the website and could finish the domain verification on the spot, the real blocker was that the Node.js official social media accounts had been delegated to OpenJS foundation staff and it felt wrong to go ahead without them (it wasn't always this case, however, since the Node.js accounts predated OpenJS foundation or even the Node.js foundation). We also talked about having a Bluesky at the tooling session during the collaboration summit, and folks generally agree that we should use Bluesky more and use it to interact with the broader developer community.

For another context, AFAIK, none of the Node.js collaborators, not even TSC which usually handles administrative matters, have direct access to the social media accounts. I am not sure when this structure started, but personally (and I think several contributors agree with me) I find it weird that whenever a Node.js contributor wants something posted on the Node.js Twitter/X, even when it's something as important as the release announcement, the best we can do is to ping a staff from OpenJS on the nodejs-social on the slack channel, and wait for them to wake up in another timezone to post it. I have heard from @marco-ippolito that in one occasion, because the staff from OpenJS was sick, we even had trouble sending the release announcement tweet in time. @mhdawson mentioned over the collaboration summit that we only delegated the access to the staff in the foundation because it might be a lot of work to generate content, but so far it seems to backfire if the this structure is more of a bottleneck for content producers like releasers and contributors who have something to promote.

Adjacently, the Node.js official social accounts had been using the OpenJS blog instead of the Node.js blog as the primary channel to post major release announcements. We had 2 incidents in both the 22 and 23 release announcement where the OpenJS blog post was a lot less accurante than the publicly reviewed Node.js blog post or just contained technical errors that incurred questions on social media, and it took a day or two (see slack discussions of 22 and 23) to correct the mistakes because of a similar manual process of content editing. In contrast, to update the Node.js blog posts, I just sent PRs to the nodejs.org repository (like nodejs/nodejs.org#7126), and got them reviewed and published in ~30 minutes because we used automation for the Node.js blog.

This is not a post to complain about the current social media management situation. I believe the staff from OpenJS did the best they could to manage content but since AFAICT many of them are marketing staff that aren't familiar with the technical aspect of Node.js, there will always be a gap like this until the technical contributors can access the content management more directly, and the timezone/sick leaves problem won't go away until we automate this process. Given the past incidents around releases, I think we do need to change something to prevent them from happening again, and I think Bluesky would be a good opportunity/experiment. It's a social app built on open source (even better, it's built on Node.js! See the backend and the frontend) , there are several community-curated GitHub actions e.g. https://github.com/myConsciousness/bluesky-post to post content via GitHub repository events, and I think it would be lovely if we can just review the posts on GitHub and send them once it gets merged, similar to what we already have with the Node.js blog. The OpenJS marketing staff can still have additional access to the account if they aren't familiar with GitHub pull requests, but the manual process should not be the only way and the bottleneck for the Node.js contributors to access the official social media accounts IMO. So this is a post to raise awareness about the current situation, and make sure the ball is rolling.

[joyeecheung]

Correct me if I am wrong, but so far as far as I have heard, it seems there is no such rule that prevents Node.js maintainers from starting an "official" social media account and giving access to foundation later/while we are at it. The usual rule that administrative stuff needs a green light from TSC applies, of course, though the impression I got from collab summit was very positive (in hindsight we probably should've just created the account during NodeConf/summit when lots of TSC members and collaborators are physically in the place but I guess we thought that the foundation would've moved sooner..). So here is what I propose that we do, based on my rough understanding about how account things work:

1. We pick the email to register the account.
   • It could either be an existing email in https://github.com/nodejs/email/blob/main/iojs.org/aliases.json
   • Or we add a new one with a PR (the latter needs some operations to get it set up, likely by @mhdawson )
   • I don't know who should have access to it but likely just a mix of subset of TSC/moderation team member/foundation staff
2. We put the password in a 1password vault
   • Basically not too different from how we manage npm/pypi accounts, see Create a Node.js org account on pypi registry #863
3. We draft the arrival post somewhere, either on the nodejs-social slack channel or just in this thread
4. Someone (maybe @targos) finish the domain verification and point it to nodejs.org.
5. We post the arrival post
6. We create a repository to help automating the posts via GitHub PRs. Likely using https://github.com/myConsciousness/bluesky-post since it seems popular.
7. Profit 🚀

So following the general rules, any opinions about the plans above? @nodejs/tsc @nodejs/moderation Please go ahead without me if people seem to agree in ~a couple of days. Just trying to get things started before I went on vacation/maybe disappear in the Chinese GFW black hole for a week.

[JakobJingleheimer]

That sounds good!

I would like to have access to post.

Perhaps Releasers should have access too.

[joyeecheung]

I would like to have access to post.
Perhaps Releasers should have access too.

To clarify: do you mean admin access (to carry out actions agreed upon by others), or carrying out actions as one wishes?

I believe we should make the decisions on actions reviewed somewhere (publicly unless it needs to be private e.g. for security announcements), and ideally automated once approved. We should be careful about allowing any individual to perform actions without consulting others. A GitHub action may be enough for most to propose actions without actually having access to credentials. Though of course we always need some people to be admins (setting up the token for the automation to use, for instance) and for swift actions (e.g. reporting spams, deleting buggy posts due to automation malfunction), maybe the moderation team could use admin access.

[mcollina]

An official account carries a lot of power, especially with a project such as Node.js. The primary reason I think it's a good idea to have it managed by the Foundation staff outside is to avoid biases (who/what to repost, how to respond to mentions, etc).

What we can do if no one objects:

1. create an account, put the password in our 1Password
2. open a ticket to the Foundation to have the DNS record added (or maybe use the HTTP verification instead) - more details here https://bsky.social/about/blog/4-28-2023-domain-handle-tutorial.
3. automate every and set up some ground rules

Until a more formal process is set up, I would recommend we keep to the rule of "a post/repost must be approved by at least another TSC member before going out".

We could also add an account tsc.nodejs.org, and a bunch of official accounts created in the same way.

[JakobJingleheimer]

To clarify: do you mean admin access (to carry out actions agreed upon by others), or carrying out actions as one wishes?

Access in some capacity to post. I'm not intending to go rogue, and I don't foresee wanting to re-post. I merely want to be able to post things like "Incoming change alert" or solicit community input on a feature design.

We could also add an account tsc.nodejs.org, and a bunch of official accounts created in the same way.

I mentioned this option on Slack. I could see a @release.nodejs.org for release and feature-related things, a @meet.nodejs.org for conference/meet-up related things we want to publicly advertise, etc. If we do the contrib spotlight, I would do that from a root @nodejs.org account (which could also re-post especially notable posts from sub-accounts, like a major release). I don't see the purpose of a @tsc.nodejs.org account.

With the delineated accounts, we could then give different people access.

Requiring a TSC member to approve every post will be very cumbersome; I expect if we codify that, no-one will post at all. Surely we can find a group of trusted people to manage not going mad with power. Perhaps if we are super worried, require that for only the root @nodejs.org account (and allow good judgment from a trusted group for the sub-accounts).

[richardlau]

2. open a ticket to the Foundation to have the DNS record added (or maybe use the HTTP verification instead) - more details here https://bsky.social/about/blog/4-28-2023-domain-handle-tutorial.

FYI DNS management for *.nodejs.org at the moment is still Build WG.

3. automate every and set up some ground rules

FWIW we used to have https://github.com/nodejs/tweet set up so that tweets could be done via pull requests (see the Previous instructions at the bottom of the README). I think that repository was owned by the old social team (which included some CommComm people) before we asked the Foundation to take over management of the Twitter account. My recollection of that was that there were still delays (as it needed approvals and then someone from the team to merge) but the PR workflow was nice as its the same as a developer workflow.

[AugustinMauroy]

FYI DNS management for *.nodejs.org at the moment is still Build WG.

BTW: node.js mastodon uses lfx.dev.

[joyeecheung]

Some thoughts about automation:

1. There are various different posts we could automate. e.g. some are time-sensitive like the release announcement, some can be reviewed more thoroughly like technical content. If we go with “post via merged PR” We can use different labels for the PR and set up different review periods for them.
2. We can add another automation to post to the slack channel whenever a PR is opened (similar to the review-requested automation we use for the core repo)
3. I don’t think we need to wait for all the rules to set up properly to create the account. We can just register the account and make it happen now, with the first post being some uncontroversial content - I propose we just post a 🦋 like many do! All the discussions about the automation can happen after the account is created. But it’s important to send a message to the community that Node.js has a presence on Bluesky now and we are with the community that decide to migrate, and we shouldn’t delay that arrival with a whole month of bikeshed of automation or something. This is time-sensitive and I think being late behind all other OSS projects is not great for Node.js, especially when many contributors have already switched to Bluesky.

[aduh95]

I don’t think we need to wait for all the rules to set up properly to create the account.

I very much agree with that, lets first create the account (as IIUC this has consensus), and figure out the rules for posting later. If we want to be safe, we can start with very strict rules and loosen them where it makes sense later.

[joyeecheung]

open a ticket to the Foundation to have the DNS record added (or maybe use the HTTP verification instead) - more details here https://bsky.social/about/blog/4-28-2023-domain-handle-tutorial.

As others have pointed out, it’s not the foundation who has access to this. I think this is also something we should change in our thought process. I also just realized after the summit that we could’ve done everything proposed in #932 (comment) at the summit with @mhdawson (who managed the emails) and @targos (who can set up the DNS record) and their laptops. We were just thinking that the foundation staff had to be involved somehow (only Robin was there, but not the people who usually handle the Twitter account) and got blocked by it. Otherwise it would’ve been wonderful if we just created the account at the summit, and give additional access to foundation staff afterwards. I think the thought process that foundation somehow owns the social media content and everything must go through them should change. They should be collaborators of our social medial content, not owners.

[joyeecheung]

It seems we have consensus here to create the account, @targos went ahead and created https://bsky.app/profile/nodejs.org with the TSC email address for now (we can change it to another one afterwards) and put the password in 1password. Shall we post a 🦋?

[joyeecheung]

A blue butterfly has been posted (by @targos I believe)! https://bsky.app/profile/nodejs.org/post/3lamaiolj2s2r

Next step should be setting up automation and content curation rules...should we create a new repository for this? nodejs/bluesky or nodejs/bsky?

[mcollina]

Either works.

[ovflowd]

I'm too late here but I wish the CPC was consulted first; As Matteo pointed before the Foundation handles socials for many reasons, the major one been to protect us contributors (I have a lot of experience on that matter unfortunately, and know how dangerous this is) and ensure that correct copies (copywriting) are done.

I know I am no TSC, but would really appreciate if the control over the socials was given to the Foundation. This was never an issue before and shouldn't be now.

+ Im against of us having multiple handles on Bluesky, who's going to maintain them long term? I don't think it makes sense to have them (like one for releasers and one for this and whatnot), we tried on Twitter and never worked.

[joyeecheung]

If we have no problem publishing reviewed content on the Node.js blog via automation, why would microblogging using the same process be a problem? Is the foundation controlling the social media of all projects or is it just Node.js? Node.js's social media accounts predated the OpenJS foundation, I don't recall there was any written rule about the foundation controlling the social media accounts of Node.js. @mhdawson mentioned in the collaboration summit that we are merely delegating access to the foundation, and we don't really need to ask if we just want a new account on another platform.

This was never an issue before and shouldn't be now.

See the OP for multiple issues of the current structure managing Twitter content. I think the current structure has been proven to be actively hurting the project (promoting content with technical error manually edited by non-technical staff in a different timezone and delayed release announcements caused by sick staff) and we should do better with automation and technical reviews.

Also, comparing the Node.js twitter feed with the twitter feed of other vibrant open source projects, I would say we should definitely do better and it's worth experimenting collaborative content curation done on GitHub again with Bluesky. The fact that so many other projects in the JS ecosystem have already migrated to Bluesky and have been posting interesting content in the past week, while we are still struggling with setting up an account due to bureaucracy (actual or assumed) and getting questions on Bluesky about the slowness already says a lot about the current structure.