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 CodeCarrot Blog (opens new window).
We track and coordinate our blog post authoring on an CodeCarrot Editorial 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 (opens new window). 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 Flock. 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 deploy.
Our RSS feed, Zapier, 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 appropriate sites.
Finally, we move the Trello card to the "Live" column.
Everyone on the team has access to our CodeCarrot Twitter account (opens new window) and can tweet at any time. If the tweet is not time-sensitive, we use Buffer (opens new window) 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 (opens new window) 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.
# Open Source
We've created a number of open source libraries (opens new window) 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 Trello Board.
Every CodeCarrot 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 existing project.