Update CONTRIBUTING.md

Author: aedwardg

CONTRIBUTING.md

@@ -1,9 +1,52 @@
-## Code Checks Before Committing
+# Contribution Guidelines
 
-We use Husky and lint-staged to check your staged files.
+This project is open to contributors of all levels. While it is primarily geared toward members of the Code Café Discord server,
+anyone with an interest in contributing to open source can pick up create a bug request, feature request, or open a PR that addresses an outstanding issue.
 
-When you commit, Husky triggers lint-staged, which runs tools like ESLint and Prettier on changed files.
+We ask that if you wish to contribute, you follow the best practices listed below.
 
-If any issues are found, the commit is blocked until they’re fixed. Check your terminal output for linting or formatting errors.
+## For All Contributors
+
+General guidance for contributors. For maintainer-specific info, see the [For Maintainters](#for-maintainers) section.
+
+### Dos and Don'ts
+
+Do :heavy_check_mark:
+
+- Read through existing issues before opening a new bug or feature request to avoid creating duplicate issues.
+- Leave a comment on an open issue if you would like to work on it. If the issue is available to work on, a maintainer will assign the issue to you as soon as possible.
+- Keep PRs scoped to a single issue
+  - Always prefer multiple small PRs over one larger PR that addresses multiple things. This helps better prevent "scope creep", and makes it easier for maintainers and contributors alike. It also allows more contributors to work on issues in parallel.
+- Ask for help if you have a question.
+  - Feel free to leave comments on the issue if you have any questions around implementation or if you need help of any kind.
+- Fork the repo and create a new branch on your fork in order to start work on your assigned issue.
+  - If you become a regular contributor, you may request to be added as a collaborator on the project so that you can work from a direct clone rather than a fork.
+- Name your feature branch something descriptive of your task. Including the issue number is common practice.
+  - For example, if you are working on issue number 42 and performing a refactor on the navbar component, a good branch name would be `42-refactor-navbar-component`.
+- Ensure that your code works, tests pass and your code is properly linted and formatted prior to opening a PR.
+  - We use a pre-commit hook on this project to help facilitate this. See the [Code Quality](#code-quality) section below for more information.
+
+Don't :x:
+
+- Do not start work on an issue if it has already been assigned to another contributor
+  - If an issue has been assigned and in progress for a long time, you may comment on the issue and ask the assignee if they are still working on it.
+    If they are not, you may ask a maintainer to assign the issue to you.
+- Do not work on more than one issue ticket at a time.
+  - Doing takes away opportunities for other contributors, and can lead to bottlenecks in the project's ability to move forward.
+- Do not get upset if it takes time for maintainers to review your PR. Maintainers are all volunteers doing this in our free time and sometimes they are busy.
+
+## For Maintainers
+
+TODO
+
+## Additional Information
+
+### Code Quality
+
+We use a git pre-commit hook to ensure all staged files are properly linted and formatted prior to making a git commit.
+
+When you run `git commit`, the pre-commit hook runs tools like ESLint and Prettier on changed files, and tries to automatically fix any linting or formatting errors it finds.
+
+If any issues are found that cannot be auto-fixed by the tool, the commit is blocked until they’re fixed. Check your terminal output for linting or formatting errors that need to be manually addressed.
 
 Once everything passes, you can commit successfully!