Sharing

We've learned a ton from blog posts, tweets, and newsletters from others in the community. We try to always give back.

Blog

Our blog is called Giant Robots Smashing Into Other Giant Robots.

We track and coordinate our blog post authoring on an Editorial Calendar Trello board:

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 our blog posts either directly in our blog repo or using our internal tool, Hub. 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 in the #blog channel.

When the post is ready to publish, we give it a publication date, merge, and deploy.

Our RSS feed, Zapier, and Buffer accounts are set up to automatically work together to link to the post from Mastodon, Twitter, Facebook, Google+, and LinkedIn. A weekly recap email is sent to all subscribers featuring recent blogs.

We also link to the post from Hacker News, Reddit, Delicious, Pinboard, or other appropriate sites.

Finally, we move the Trello card to the "Live" column.

Twitter

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.

Research

We track our ongoing experiments in GitHub issues with the "Experiment" label.

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.

Open Source

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 at least one leader (codeowner) 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
• Keep the library dependencies up to date
• Blog, post on social media, and otherwise advertise new releases and tips

Additional responsibilities for an active project could include planning and feature work.

We track the current open source leaders of a project in the CODEOWNERS file in the repository.

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 main.
• Try helping out with existing pull requests, bug reports, or testing release candidates.
• Documentation patches are a great way to get familiar with a project.
• Help promote a library by sharing it on conference talks, blog posts, etc.

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 existing project.