1. Use branches for all new features, bug fixes, and patches.
2. Name branches after the new functionality gitusername/(feature/patch/bugfix)/new-buttons
3. Commit early and often. We are using squash and merge so your commits will get squashed when merging to main
4. Write tests
5. Get Code Review.
6. Resolve all conversations
7. Once approved, squash and merge to main

1. Keep on topic of the branch name and issue when submitting PRs,
2. Have separate branches and PRs for separate functionality, lean towards small PRs
3. Create detailed commit messages.
4. Short on-topic succinct PRs are faster to review, keep git history clean, and are easier to regress if we find bugs.
5. Explain in detail everything you've tested, show screenshots if relevant.
6. Link to an issue in the description if possible. Ex: Fixes #20. 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. There are usually plugins/extensions for your IDE of choice. Please conform to our current styles in the linter, it makes it easier to read and less likely to have developer arguments.
2. For JavaScript and React style guidelines that compliment eslint/prettier, the Airbnb style guide is usually a good rule of thumb.
3. For styling components, we are currently using SASS with BEM syntax and Material UI.

1. Prefer Functional paradigm vs Object Oriented Programming
2. What is Functional Programming
3. Functional Programming 101
4. Functional Programming in Javascript
5. Functional programming Avoids 'this'
6. Functional programming has easier faster readability
7. Functional programming Maintainability - its easy to change a single function than to extend a giant class
8. Testing is easier

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!