M.O. ★
No matter how complex the processes or magical the output is, ultimately, it can and should be reduced to a set of rules, for continuity sake. These are guidelines/recommendations for getting things done in a collaborative/community environment and programming in style.
Guidelines
- Best Practice - techniques that have consistently shown results
- Code Review - how to examine each others code
- Convention - that which is considered acceptable or polite to most
- Style - easy to read and good to look at
The Top Layer
- Be consistent.
- Teach, if you can.
- Publish what you learn.
- Many heads are inevitably better than one.
- Don't violate a guideline without a good reason.
- A reason is good when you can convince a teammate.
- Don't rewrite existing code to follow the code guidelines.
- Code well. Everyone leaves. Your last duty should be to hand it off to a competent successor.
- Don't wait for crisis to change, adopt an M.O. asap and stay safe.
Language
- "Avoid" means don't do it unless you have good reason.
- "Don't" means there's never a good reason.
- "Prefer" indicates there's a better option, you can evaluate it's pros and cons.
- "Use" is a positive instruction.
- "Limit" is a caution against excesses.
- "Team" comprises a group of people linked in a common purpose.
- Lack of "Avoid", "Don't", "Prefer", "Use" or "Limit" implies a rule.
Credits
Direct and indirect influences:
- Thoughbot, Inc - from which this was heavily borrowed from
- Foundation by Zurb
- The Cathedral And The Bazaar by Eric S. Raymond
- Semantic Versioning by Tom Preston-Werner
- The iHub
License
King'ori J. Maina © 2013. The MIT License bundled therein is a permissive license that is short and to the point. It lets people do anything they want as long as they provide attribution and waive liability.