Developer Guidelines:
- Motivate the changes in the commit log when it's not obvious.
- Commit often. It makes redundant work more unlikely, it allows the other developers to keep track of your activities, and it's easier to see changes this way.
- Don’t hesitate to check in work-in-progress, so long as it is minimally functional.
- Don't be too afraid to break something, everything can be easily undone or fixed.
- One issue per commit: separate commits makes it easier to review, and if necessary undo, specific changes.
- That said, being terse is perfectly ok: "typo" is enough. The aim is to make it easier to find the desired change easily.
- Features that are only availabe in Spring .75 and break or modify the experience for .74b3 players should go in ca-lua.
- Always include the bos file of modified cob scripts. If not, your changes will be overwritten when someone else compiles the bos.
- Ask for feedback often. Don't spend a huge number of hours working on an change and then commit it and expect everyone to approve.
- Don't be afraid if you have a different opinion from everyone else. Don't hesitate to give negative feedback. Also, don't take it personally if other people disagree with you, or don't like you shiny new effect. It's all part of working as a team.
- When buffing or nerfing, try to nerf attributes that are not essential to a units role, and when buffing, try to increase the role-secific traits.For example, the best way to nerf a raider is probably to decrease its HP, not its speed.
- When reverting a change made by another modder, try to consult them first. They may have had a good reason you are not aware of.