We've learned a ton from blog posts, tweets, and newsletters from others in the
community. We try to always give back.
Our blog is called Giant Robots Smashing Into Other Giant
We track and coordinate our blog post authoring on an Editorial Calendar Trello
When someone wants to write a post, they write its headline as a Trello card
in the "Next Up" list of the board, and assign the card to their Trello user.
Spend time writing and re-writing a great
headline. It helps narrow
focus, figure out the purpose of the post, and grab people's attention in
the first place.
When we begin writing, we move the Trello card to the "Drafts" list.
We write posts in Markdown, and store them in our blog's GitHub repo.
We add tags to the post, which help our readers find related blog posts.
When we're ready for feedback from the team, we move the card to an "In Review"
list and share the Trello card's URL with the team in Slack. We make changes
based on their feedback and our judgement.
When the post is ready to publish, we give it a publication date, merge, and
Our RSS feed, Zapier, and Buffer accounts are set up to automatically work
together to link to the post from Twitter, Facebook, Google+, and LinkedIn.
We also link to the post from Hacker News, Reddit, Delicious, Pinboard, or other
Finally, we move the Trello card to the "Live" column.
Everyone on the team has access to our
thoughtbot Twitter account and can tweet at any
time. If the tweet is not time-sensitive, we use Buffer
to queue up tweets and keep a schedule.
We try to be conversational, casual, and real on our Twitter account. We talk
the same way as we would in person among ourselves and be good-humored. Puns
are encouraged. We aim to keep the quality high and for every tweet to be a
hit. We want to avoid spelling mistakes, and use proper punctuation. We
should respect the people who follow us.
To reach the largest audience, don't begin a tweet with a Twitter username.
Some tweet ideas include announcing meetups, open source releases, enthusiasm
about a new tool or technique, tips on Git, Unix, and Vim, links to our blog
posts, links to others' blog posts if they are excellent and not on the current
Hacker News or Twitter cycle at the moment, and Funkmaster Flex.
We have a verified Twitter account and are a Twitter
Ads customer. With this we can see analytics such as
number of retweets, favorites, replies, clicks, follows, unfollows, and how
tweets compare in terms of engagement.
Promoted Tweets campaigns are best for short term campaigns to drive traffic to
a website. Target 10-25 similar, relevant @usernames in each campaign. Create
different campaigns for different themes of people so that we can track
performance per theme.
We track our ongoing experiments in a "Research" Trello board:
We rigorously conduct experiments on new tools and techniques. Once an
experiment has concluded we try to share the results in the appropriate
channels. That may be this Playbook, our blog, twitter, or elsewhere.
We've created a number of open source libraries
to help us perform common tasks and give back to the community.
Our open source libraries do better when there's one person that really steps up
to maintain them. Each of our repositories has a leader that tries to keep the
repository moving forward. The leader doesn't necessarily do the bulk of the
actual work; responsibilities include:
- Understand the underlying code and goal of the library
- Review and merge pull requests
- Respond to and close issues
- Push new releases of gems when appropriate
- Encourage people to take on useful tasks for the library
- Blog, tweet, and otherwise advertise new releases and tips
We track the current open source leaders on our Investment Time
Every thoughtbot developer, designer, and apprentice has commit access to our
open source repositories. We follow these guidelines:
- You may want to check with the project leader to see what would be most
useful, or whether or not they're on board with your idea.
- Send pull requests rather than committing straight to master.
- Try helping out with existing pull requests or bug reports.
- Documentation patches are a great way to get familiar with a project.
Got an idea for a new library? Found something useful in a client project that
you think is reusable? Great! Some guidelines:
- Extractions are likely to be more useful than Brave New World ideas, because
you're extracting something that has already proven useful once.
- If you create a new library, you're expected to lead it, at least for the
beginning of its life. Make sure you have time to maintain it.
- Try not to duplicate something that's already been done well. Look around to
make sure your problem hasn't already been solved.
- Fixing bugs that affect client projects or introducing small features that
would really help a client project is fine during client time. Most open
source work should be conducted during investment time.
- Think about whether your idea makes more sense as a pull request to an