Wednesday, May 17, 2023 From rOpenSci (https://ropensci.org/blog/2023/05/17/scheduling-mastodon/). Except where otherwise noted, content on this site is licensed under the CC-BY license.
A lot of what I do as rOpenSci’s community assistant is related to social media. I check for posts about rOpenSci packages, invite people to share usecases, advertise upcoming events, as well as promoting new packages which completed software peer review.
Up until this past year most of this work was focused on Twitter and because we want to reach an international audience, we used Tweetdeck to schedule posts for different timezones1. Being able to see when posts were queued was also important for us as a team to better plan our post timing.
However, we’re also now developing a presence on Mastodon. We’ve enjoyed exploring this new community, but unfortunately there aren’t as many tools for working with Mastodon posts as there are for Twitter. There are some schedulers available, but we thought this might be an opportunity to develop one of our own; one that worked programatically and allowed us to design it the way we wanted it to work.
In particular, we wanted a workflow that allowed us to…
and did not
This led us to create a workflow for scheduling Mastodon posts using R, rtoot, and GitHub actions 🎉!
By using this workflow we can
This workflow does have some limitations
Incorporating the Mastodon API scheduler
The Mastodon API and
rtoot::post_toot() do have options to schedule posts,
but I’m unclear how easy it is to see the queue. One thing I like about our
existing workflow is that we can easily see and modify the queue as a team.
However, it might be a good idea to incorporate the scheduler API into this tool
at least when posting multiple posts at the same time. Currently, we wait 5 min
Sys.sleep()) between posts in order to space things out a bit more
gradually. But this still uses 5 GitHub Action minutes 🤔.
Interacting with posts
Right now our workflow doesn’t have the capability to interact with posts on Mastodon. However, I’ve been toying with the idea of adding a YAML key for post id, so we could set up scheduled replies to existing posts.
Boosting and favouriting seem possible, but would probably require using
rtoot::rtoot() to create a custom
API queries. For this workflow
that may be a bit too clunky, but it could be possible to set up a different type
of issue template where post ids to be boosted/favourited could be listed.
Finally, although post threads aren’t common on Mastodon (due to the generally sufficient character limit), it should be possible to use comments on an issue to create a threaded post. I don’t think we’ll implement this as we like to be able to use the comments for notes to each other or to our future selves, but depending on your workflow, this could be a useful feature to add!
And that’s that! There are definitely other options out there, but I have to admit that I thoroughly enjoyed the experience of making our own system. Even if testing it was a bit terrifying 😉
I already get up early for the European Central Coworking session and am not excited about getting up even earlier just to tweet the 1-hr reminder! ↩︎