Development Team Code of Ethics
Just wanting to share what I've written today for our team's Code of Ethics. This text goes in our project's README.md
.
This list is something we've built and learned over the past few years (some we learned just recently). Although we've been around for 4-5 years already, these principles, workflow, and process has been effective so far on how we're dealing with our recent project with the current team size of 7 developers. Slack being the key driver of all things. Effects to your team may vary.
Code of Ethics
- Always communicate. Always be online on Slack.
- Always work with a Pull Request. Long running PRs are welcome but mark them with [WIP] so we don't merge it.
- Follow the git flow principles.
- We always work with a Milestone. See the current milestone here https://github.com/organization/project/issues/milestones link changed purposely
- Don't hesitate to review other people's work. Always welcome criticism.
- Always get your PR code reviewed by somebody else. Please do not self-merge unless seriously needed (like a critical bug that needs to be deployed ASAP).
- Always keep your PR up to date. Rebase frequently.
- We love screenshots of work, share us what you are working on. It helps the code reviewer understand your work better.
- Follow Ruby/Rails best practices.
- Follow Ruby style guides https://github.com/bbatsov/ruby-style-guide
- Be consistent with other people's way of doing things but feel free to discuss improvements.
- Always be testing. We don't require 100% test coverage but we do take testing really seriously.
- If you can't immediately write a test for a method, make sure to still write a test case and just put
pending 'explain the reason why'
so you or somebody else can return to it later. - Codeclimate is reporting 90% code coverage. We love it if you keep it that way. Team hug if you make it higher.
- We don't need our code to have a lot of comments. Good code is like a good joke, it doesn't need an explanation. Make your code readable instead.
- We put more weight in code clarity.
- We love metaprogramming but stop metaprogramming just for the sake of doing it without any added value. Again, code clarity.
- Make use of special ANNOTATIONS like # TODO:, FIXME:, OPTIMIZE: so
rake notes
can pick it up. - Codeclimate for code smells and security issues.
- Found a bug? Do not wait. File immediately on github issues! We get notified instantly anyway.
- We worship Leeroy Jenkins http://jenkins-url
- Jenkins for CI. http://living-on-the-edge-testing-url/ to view the latest jenkins build.
- When in doubt, ask on Slack.
- Prevent being a blocker to your teammates.
- Bonus points for being proactive.
- Finally, be a good teammate.
Tools
Slack - I can't emphasize more how Slack improved our development workflow and our ability to maintain such a good system of communication and integration among our 3rd party and in-house tools. It's also a great way to share screenshots, code snippets, files and funny gifs. Custom emoticons are awesome :) - All github, jenkins, error notifications constantly streams to different Slack channels keeping us on top of what's happening.
Github Milestones & Issues are so effective in organizing our current backlog. We're now using Github all the way and we're keeping track of features via a PR. We still do use Pivotal Tracker on other projects though but we may have to discard them in the future though.
Evernote for note taking. We have a shared notebook that syncs to the rest of the team. The main tool that our stakeholder is using. We keep track of feature definitions, Sprint and Milestone planning in one Evernote notebook. It's very easy to maintain and one can even simply keep on working even offline.
Codeclimate definitely is an ego breaking Overlord that constantly reminds us that we feeble humans need to get our act together.
Appsignal for error notifications. These guys are the best!
Be ready for criticism
If you're working with a team, I hope you find this list useful and feel free to discuss. It's always a work-in-progress and I'm happy to discuss them with people in the community.
Follow me on Twitter as @jasontorres
Written by Jason Torres
Related protips
4 Responses
Good stuff. I'll have to revisit this the next time we do a team formation or a revision of our team contract. By the way I do like the phrase "Good code is like a good joke, it doesn't need an explanation."
If this kind of ethics sheet and tool set was applied everywhere, we would be 50 years ahead of the current software; 100 if we also forced all software to be open source under a MIT, BSD, or any similar license. But that's just this programmers opinion.
I like this article and its a very good reference towards creating your own teams code ethics if you manage one.It really points the team out of its best.
Good stuff