Failure is the greatest teacher there is. Other people's failures, when sufficiently well documented, are even better, because you get the education without personally paying the price. So, what can we learn about managing social media from Raspberry Pi's self-immolation on Mastodon?
For the vast majority of the world who hasn't been following, Raspberry Pi launched a Mastodon server under their own brand on the distributed social media service Mastodon, and managed to get that server "defederated" (isolated from most Mastodon users) in less than 24 hours, which is some kind of record for the platform. Aurynn Shaw has a great writeup of the actual details of the incident if you're curious.
This article is about "how do we not repeat Pi's failure with our own official project accounts on social media?" Pi failed in multiple ways here, so it makes for a terrific object lesson in how you should run your social media presence differently. Let's go over the lessons:
1. Your social media needs to be managed by a team with a playbook and a code of conduct
This is Pi's core failure, if one is looking for a "root cause". It's clear from the tone, rapidity of replies, and other cues that the Pi Mastodon account was being controlled by a single individual with no supervision or handbook. Basically, whoever was posting using the account treated the brand account as if it was their own personal Twitter account, rather than speaking for an organization. A lot of open source projects make the same mistake, assigning social media to whoever volunteers first and leaving them to their own devices.
Every individual has biases, triggers, blind spots, and bad days. Whenever you equip an individual to speak for the organization, you need to give them the tools to behave like a voice for the group and not like themselves. The main tool to make this happen is to have a team. Ideally, this is a team that jointly controls the account, but even if only one person is on a specific account, have a social media or comms team that meets and works together, like the
Kubernetes Contributor Comms team.
In addition to reminding each volunteer that they are speaking for a greater whole, teams have standards. One of those is your project's Code of Conduct (you have one, right?) which being on the team makes it clear applies to project social media accounts. A second is a "playbook" or "handbook" that tells the individual contributor how to use the account, including things like who has to review a post before it goes up, and what to do if you get caught in a flamewar.
2. Be aware of controversial topics in the social media environment and never wade into them without planning
Author Charlie Stross summed this up rather well:
Pi boosted their 1-month-old presence on Mastodon with a post about police surveillance. There is no way that the organization was unaware that police surveillance was a controversial topic. And, importantly, the issue of police surveillance has little or nothing to do with the mission of Raspberry Pi. Thus, with little preparation, they inaugurated their presence on a new media channel by sparking a wholly unrelated controversy. For some portion of the Mastodon audience, it has now been rebranded in their minds as "that cop thing".
If your project account is going to be involved in a controversy on social media, there needs to be something to gain for the project. The best time is when you're defending one of your project's core values, such as a security software project defending responsible reporting practices. You may also be speaking up for a key part of your own community, like the Kubernetes project's public statements supporting Black Lives Matter. In each one of those, there is a benefit to the project in taking sides which justifies the cost in being part of angry arguments that may alienate potential users and contributors.
Whenever your project does embrace a controversial topic, though, it needs to happen as part of a set of deliberate decisions by the entire project leadership which includes a written plan. You need to have a plan of exactly what your messaging will be, and exactly how your social media contributors will respond to any backlash.
3. If a post draws a lot of angry responses, it's time for a comms team meeting before any replies go out
A handful of Mastodon domains blocked Raspberry Pi because of their original posts. Dozens blocked them because of their responses to criticisms of those posts, which were seen as more offensive than the original post. If the account owner had simply ignored the criticism, it's entirely possible that the Pi account would not be cut off.
On social media, there's a tendency to want to respond immediately to every comment. Your comms contributors need to be trained to overcome that impulse. When something unexpected happens, replying off-the-cuff is almost always the worst thing you can do. Instead, it's time to call an impromptu meeting of your comms team, or whatever group of contributors you can get to hash out what your well-considered response should be.
If you're worried about silence seeming rude, have a very neutral boilerplate response in your social media handbook. Something along the lines of "Thank you for your feedback." You do not need to say anything else until you have deliberated on what to say.
4. Educate yourself on the different mechanics of how each social media platform works
Much of Raspberry Pi’s social media response here was drawn completely
from how they behaved on Twitter, where blocking and telling people to
unfollow works, due to Twitter’s lack of moderation. -- Aurynn Shaw
Prior to joining Mastodon, the same people at Raspberry Pi weathered a similar firestorm on Twitter. However, as a brand account on Twitter they were able to hide a lot of the critical replies to controversial posts, and there was no way for people who were still angry with them to escalate. Pi clearly believed that the same approach would work on Mastodon, and hadn't checked that Mastodon's moderation system works differently.
Each social medium has its own technical mechanics, conventions, rules, and taboos. It's critically important that before your project officially adds another social medium to your list of outlets, that you research and understand it. This will mean that your project will have no presence on some social media, and on others will be only holding the project name and not posting, and that's OK.
This is why I am not recommending that every project get a Mastodon account next week; you need someone in your project who understands Mastodon and can develop your playbook for how to post and interact there.
Your project's social media presence is an important part of the project and needs to be taken as seriously as you take your unit tests. It needs to be deliberative, run by a team, and based on goals for the project. Social media can be a great way to make new users and contributors aware of your project, but it can also be a way to ruin your project's reputation in ways that are expensive to undo. Learn from Raspberry Pi's example and don't repeat their mistakes, on Mastodon or on any other medium.
