Together with launching our blog, we have recently created (or better: reactivated) our Engineering team’s Twitter account. We are planning to use it as the default broadcaster for the work we do at Loadsmart. And although we may have different channels (as this blog itself is one of them) and possibly different forms of content, Twitter is great at notifying what’s new, regardless of form or platform.
One of the biggest concerns I had when we settled on the idea of sharing our work was to not let our account be managed by a single person or a small group in the company. Having specific people responsible for creating those tweets would likely create bottlenecks that could lead to lack of engagement in generating new content. And to make this initiative successful, we need to make sure content creation comes from everyone. It should be accessible to anyone willing to contribute. I believe this is what creates a collective sense of ownership.
Twitter is a microblogging platform so I thought: "Why not having a similar experience from regular blogs where multiple authors write multiple articles?" Well, that would be nice. But unfortunately, different from regular blogs, we can only post content from a single account.
The easiest solution would be sharing the credentials, some may think. That would work, but that wouldn’t be enough. Collective ownership is also about making sure decisions are made and agreed upon. We would at least need people reviewing their peers.
What I envisioned was a flow that would allow us to:
Because these reviewers are mostly engineers, the closer this whole process is to their natural habitat, the better. We use GitHub and Slack all day so the solution would definitely be somewhere in there.
I have used Danger and Peril quite a lot in the past. They are great tools to automate many of the workflows we have, especially those involving review of Pull Requests. In fact, Loadsmart has its own set of settings that are used across many of our repositories on GitHub. But this time I decided to give GitHub actions a try.
Surprisingly, most of the things I was planning to implement were already done by Gregor Martynus in their twitter-together project. From the steps of the diagram above, the Action takes care of 1, 2, and 4. The only step missing here is the Slack notification.
There are a few Actions to interact with Slack on GitHub’s marketplace. They are all very similar to each other and most of them are not as flexible as I wanted when it comes to customization of the content for the notification. You can have this full flexibility by using Slack’s Block Kit API though, but apparently it is not possible if I have already decided to use one of the available Actions. Also, the fact that there’s no concept of "official" Actions made me think twice.
So to achieve what I had in mind, I decided to implement this one myself. I would need to create a custom action to glue all the work together anyway, passing to Slack the content of the tweet in the PR. In fact, this would be only one extra step in the workflow. Here’s the preview of the notification that is sent when someone is suggesting a new tweet:
The example above presents a notification for a Pull Request that when opened (and identified as a valid tweet-type PR), sends a message to our team asking for reviews. Once it gets approved, it is merged into master and then the content is finally tweeted.
If you want to know more about the implementation details, check the code and the project we have just open-sourced at https://github.com/loadsmart/tweets