-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bluesky account & automated social media content management #932
Comments
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:
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. |
That sounds good! 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. |
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:
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 |
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.
I mentioned this option on Slack. I could see a 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 |
FYI DNS management for
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. |
BTW: node.js mastodon uses |
Some thoughts about automation:
|
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. |
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. |
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 🦋? |
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? |
Either works. |
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. |
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.
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. |
The current process of posting on Twitter is: someone drafts something -> paste on nodejs-socal on slack -> wait for someone from the foundation to copy-paste it and send it via hubspot (sometimes involving obscure manual editing back-and-forth). I am not sure how the current process would offer more protection than the proposed process. The social channel is public, you can see every discussions made there as long as you join the OpenJS slack. And personally, I don't mind the content on Bluesky don't get copied into other platforms (many projects have even shutdown their X accounts to migrate to Bluesky, surely only posting better/more content on Bluesky over X isn't a radical idea...) |
Hi! Jetlagged Robin here. Yes, extra busy between CityJS Medellin and Node.js events in Ireland. We’ve also had teammates out on family leave and covid this month, so please give us some grace to catch up. The Node.js social handles reach nearly a million people between twitter and LinkedIn so it's a big responsibility. We’ve learned a lot over the past 5 years about how to manage between the foundation staff and Node.js project. Our goal is to be flexible and agile, yet responsibly managed with password access, etc. We can’t have "marketing by committee" nor unnecessary churn. I support updating our process for a few maintainers to have access, but this is a marketing function that should be focused and coordinated. I’ll follow up with y’all this week on Bluesky. I literally have blue sky outside my home right now that I plan to go out and enjoy. |
@rginn I hope we haven't come across ungrateful! |
@joyeecheung I understand your perspective, and with respect, I won't argue as I literally have no reason to; My role here is not to argue regarding what the TSC decides, just trying to provide my 2cents, plus I unfortunately have no time to spend on this topic. -- but just wanted to mention that my suggestions are based on numerous years on working on Engagement and Outreach with Open Source organisations. Plus, see another example, with the Discord server creation we went super careful, all things that can affect the project as a whole should be done carefully. This was a rushed decision over a weekend and I do not think a Bsky account should have so quickly be created nor the decision making of who accesses it or has control over it. The TSC tends to be slow and very careful for certain things and then for this particular topic which is very sensitive it went way too fast and over a weekend. So, apologies if I'm a bit uneasy with the turnaround here. You also asked the moderation team for input but didn't even wait for us to actually write anything here. Anyhow, account created, and we can always iterate on the management processes and who has access to it. I'm with Robin here when it comes to just a few people should have access to it. |
I believe the accounts credentials should be available on 1password for transparency like everything else we do, but I agree we should not allow everyone to create posts. The idea is to make the social media posting process more accessible to review, more transparent and easier. |
We all believe on different things, that's fine. Again, I couldn't care less what y'all decide in where to store the password or access or whatnot. I am just extremely frustrated with how this got handled and wish this was properly done over time. Otherwise it is a brute dishonest violation of the TSC charter and the project governance. Plus a disrespect of the people working on the project and their time and knowledge and experience on such matters. |
It is about deferring the access and who make the posts (to someone outside of the project) that allows us to remove a single contributor or set or contributors as being the authors of said post; It is more a protective measure, even if a 1:1 copy. |
That is an unfair statement, this issue got opened 2 days ago, and the account got created already... Where that this is slow 😅? There are no processes and we should take our time creating processes and ensure things are done smoothly. Would you like that a PR to merge a new shiny feature from Ecma262 got merged here just because everyone is now excited about said feature? 😅 |
I would not say this is a rushed decision. As OP already mentioned, the request was sent on Nov 4 on slack. We discussed about this offline many times during NodeConf EU and the collab summit, including bringing it up in the Nov 8 tooling group session which was available to the public to attend remotely or follow the notes remotely, and we had been discussed it in various posts on Bluesky over the week. It should not be news to anyone who check out nodejs-social, or to the >30+ contributors who went to the summit (and even more because many checked out the notes), or to the growing community that are already on Bluesky. This issue was opened to raise awareness about how inefficient we had been to carry out an action that many contributors already achieved consensus on. It was already very late from the beginning of a request.
I don't see how different this is between the two processes. Even when proposed on nodejs-social, a public channel, it's hardly a secret who requests a post to be tweeted out. Once reviewed, the posts came from a joint responsibility. We don't even remove authorship in our blog posts, and Bluesky/Twitter are just microblogs. |
I was referring to how slow the project was to react to the migration compared to other projects in the JS ecosystem. Even express already joined Bluesky on Nov 8, so Node.js was not even the first project under OpenJS joining Bluesky. TBH it feels embarrassing how slow Node.js already is to join Bluesky behind so many projects (even if we don’t count popular downstream projects like Vite or React, other JS runtimes like Deno and Bun already joined more than a week ago). IMO we should not be content with this inefficiency.
I don't think ECMA262 would be a fair comparison because its process is famously slow since it's a standard. A more fair comparison would be our usual consensus seeking period in the project which is in the 2-7 days range, and see the OP about the timeline - the request was sent on Nov 4 on nodejs-social where the social requests are always handled. Technically, it has been about a week, so I think that we already have given it ample time for discussion, and were merely carrying out a decision that had been agreed upon by many contributors over the week. |
Thanks for being understanding! As I mentioned in the OP, this is not to complain about the current situation. I believe the foundation staff had been doing the best they could. The automation proposed should help reducing the burden of the foundation staff as well - humans are brittle, they get tired, they get sick and they have things that are more important than work, and it is unfair/illegal to expect any human to be 24/7 online to carry out what we want them to do. But GitHub actions don't get sick and usually don't have other things better to do other than finishing what we tell it to do, and it's usually available 24/7 (unless GitHub goes down)! I believe we can do much better with the process by using automation more, and Bluesky is the best place to experiment precisely because of a relatively small and dev-focused tech community it has right now. |
I know several people are upset here, and I hope everyone knows we appreciate you (especially Robin, who I know has been run-run-run, and already was looking into facilitating this), and no-one is slighting the foundation or its stewards. I believe Joyee (who was party to the discussion where Robin mentioned attempts to sign us up) was assisting those attempts. I feel like Joyee is getting ganged up on for facilitating the unanimous and overwhelmingly enthusiastic consensus at the collab summit. I hope everyone can take a step back and consider the well intended actions that very likely would have been ultimately taken anyway, regardless of which T was or was not crossed. Is anyone ultimately objecting to node joining BlueSky, and was anyone actually hurt by the potentially premature joining of BlueSky? If not, may we accept the correct action happened and everyone respects and appreciates our team. |
I haven't seen any objections about #932 (comment) and we have multiple thumb ups - will create BTW, I took a look at https://github.com/myConsciousness/bluesky-post and it seems that one and many existing actions only provides basic functions, probably only the post action would be interesting for us but it would also be nice to be able to repost/reply/quote post via an action. Bluesky has an official Node.js SDK and it only takes a couple of lines of JavaScript/TypeScript to implement said actions, so we could also look into maintaining our own actions in the new repo. |
To prevent confusion, among other issues, I filed a copyright infringement notice with Bluesky - as the authorized Node.js copyright owner - for the following account https://bsky.app/profile/nodejs.bsky.social, following the Bluesky Copyright Policy guidance https://bsky.social/about/support/copyright. @targos please work with me offline to add the official Node.js Bluesky account credentials password to the OpenJS 1Password account. |
Many thanks @targos for working with me to add the Bluesky password credentials to the OpenJS 1Password. I'll work with the TSC on process. |
I'm not sure if this is the right place/time to bring this up but since we are creating a new account and discussing automation it may be as good a time as any. In the past there were some different ideas on what kind of content should be posted to the Node.js social accounts, with one view being that people on the main Node.js social account were not really interested in content related to the working of the project itself including working groups, team meetings, etc. versus information related to using Node.js itself. If that is still the case then we might want 2 accounts: Adding that to the discussion for consideration. EDIT: I do see @ovflowd earlier comment about multiple handles, but I think this might be different in having 2 is not the same as having N (N being some larger number) |
I recall we own nodejs.dev (or another .dev? At least nodejs.dev redirects to nodejs.org so I assume it’s this one). Since many projects use the .dev domain on Bluesky and you know, .dev kinda just says its about devs, maybe we can also register nodejs.dev and use it for the automated project updates, community outreach etc. and update the profile of nodejs.org to point developers to nodejs.dev. One concern I have about it is that many other OSS projects only have just one account to post everything and most projects just post about latest updates and do community outreach all the time in that main account. Having a separate account with a less familiar domain could reduce our outreach. At least as a regular OSS user I would expect nodejs.org post the same kind of content that bun.sh and deno.land and vite.dev and astro.build do, or feel that nodejs.org is a bit too boring to follow if it’s less dev-minded compared to the other ones. |
We do own |
I think it makes sense for @nodejs.org to be used for community outreach and release notifications, and @nodejs.dev to be used for more hardcore development-specific things like forewarnings of notable-changes and soliciting library author feedback. |
Created https://github.com/nodejs/bluesky and opened some issues there to transfer the discussions. I tried to open a PR to add README/LICENSE/COC/DOC there, but couldn't make a PR work without creating an empty main branch first, and I ended up creating the init branch with said files, then renaming init to main, then they were effectively merged. Anyway, the files added there are pretty standard. If you see anything problematic, please send a PR to correct them. I'll close this issue so that we move the discussions there. |
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.
The text was updated successfully, but these errors were encountered: