1. Use feature branches for all new features and bug fixes.
2. Name feature branches for what the feature does feature/new-buttons
3. Name bugfixes for the bug bugfix/page-blowing-up
4. Merge feature branches into the development branch using pull requests.
5. Keep a high quality, up-to-date development branch.

1. Keep on topic of the branch name and issue when submitting PRs
2. Keep separate functionality in separate PRs and branches
3. Be respectful of code reviewers time and sanity. It's an open source project, short on-topic succinct PRs are easier to review than long PRs with everything and the kitchen sink changed. Your code will go through review faster with smaller PRs.
4. Link to an issue if possible. If there isn't one yet, create one in the Water the Trees Project board

written-unwritten-guide-pull-requests

0. Complexity is a factor going against security and readability and maintainability, follow KISS when refactoring. If something is simple and works, don't add complexity if it doesn't add a huge amount of value. Value readability and maintainability over premature optimization. Keep in mind this is an open source project with short term junior developers passing through or adding small contributions. If they can't understand it easily and quickly, rewrite it so they will.
1. Refactoring should be small and should not break existing code.
2. Always follow the camping rule. Leave the codebase healthier than when you found it. The change can be small.
3. Refactoring should make the code easier to read.
4. Refactoring should be part of a typical developer routine.
5. If we need to refactor a large part of the system or a library, we make it a team effort. Whenever anyone goes near any code in the refactoring zone, we move it a little way in the direction we want to improve. Before you decide you want to refactor or rewrite everything while contributing a feature, please read this: Refactor-vs-Rewrite AND this Pull Request Etiquette. Is the refactor too big, too risky for one PR? If you can break refactor into small bite size chunks, that is better.
6. If there's not a clear need to rename files, functions, variables, leave naming conventions as-is. Name changes that help developers understand the code faster are preferable over generalization and obscuration.

1. Use eslint and prettier. Please conform to our current styles in the linter, it makes it easier to read and less likely to have developer arguments.

1. Try to be descriptive with names but don't go overboard with a 60 character variable! long-names-are-long
2. Don't be overly vague or use super generic names like: data, state, amount, value, manager, engine, object, entity, and instance.
3. Be consistent with the current code base and use the linter!
4. Don't use variable or Component names that are the same as standard HTML syntax or js built in methods.

Please look at the project list for code contributions we need or add a new idea and bring it up at the meeting! Water the Trees Project

THANK YOU for contributing to this project!