This is a living document of common, company-wide practices for smooth operation day-to-day. I think we should encourage conversation around this document -- what works, what doesn't, and how we can change for the better. The items below will be written in a pseudo-RFC format, utilizing the keywords listed in the IETF's RFC 2119.
The services below provide really solid baseline support for operating a business. They also provide really wonderful APIs, so if there's a feature that's missing or that could improve our workflow we can totally build it.
- Harvest, time tracking and cost analysis
- Tracker, project management and planning (review the philosophy behind this tool here)
- Google Apps, email, calendar, file store
- GitHub, codebases and other versioned resources
- Slack, team chat
- organization
- how they relate to services listed above
...
...
...
- when to use what
- best practices
...
...
These can get unweildy quickly, and we've all got limited space in our heads, so let's keep them as simple and understandable as possible. When you need to add a calendar event you SHOULD follow these steps:
- prefix the event with the client code e.g.
[JAKO]or[COG]-- this makes it easy to see what the meeting is about at a glance. Use[CC]for Code & Craft internal meetings. - include the purpose of the meeting in the description.
- include links to relevant items in our PM tool.
- add the event to Code & Craft Google calendar so it's visible to everyone. screenshot
- invite everyone (including yourself) that needs to be involved.
- allow guests to modify the meeting so anyone can keep it updated. screenshot
Note: many suggest keeping meetings to 15 minutes or less, so unless it's a whiteboarding session (or something similar) try to stick to a timeline.
- add accounts for tools listed above
- ???
...
...
We keep common styleguides accessible here so we can maintain consistency across projects, prototypes, etc. You SHOULD include the linter files in any new project and maintain coding style.
- JavaScript, styleguide and JSCS config
- SCSS, styleguide and Sass Lint config
...
We use Git and employ a fairly basic branching model.
The master branch is the source-of-truth and SHOULD be "staging-ready" and
presentable -- if it's a user-facing app, clients will be looking at it.
When working on a feature or fix you SHOULD create a separate branch with a
description name e.g. account-management or fix-broken-images. We do
utilize pull requests
and you SHOULD open one up onto the master branch as soon as you've branched
away with the intention of eventually merging. It's meant to be a discussion
and will evolve with the feature or fix.
...
Some type of continuous integration SHOULD be employed for each code base. Implementing these tools up front eliminates a lot of opportunities for mistakes down the road, especially if your test suite is kept up-to-date (as it should be). Here are some options:
Continuous deployment can be accomplished by our hosting platform, Heroku. Set up the app to monitor the related Github repository and run an automated deploy to staging after the CI has completed.
- test