1-
21#Contributing
32
43##Requirements
@@ -16,7 +15,9 @@ Use the following `make` commands and scripts in development:
1615
1716##Styling
1817
19- ###Use Go style
18+ ###Backend
19+
20+ ####Use Go style
2021
2122Contributions must adhere to the guidelines outlined in[ Effective
2223Go] ( https://go.dev/doc/effective_go ) . We prefer linting rules over documenting
@@ -26,13 +27,27 @@ Read [Go's Code Review Comments
2627Wiki] ( https://github.com/golang/go/wiki/CodeReviewComments ) for information on
2728common comments made during reviews of Go code.
2829
29- ###Avoid unused packages
30+ #### Avoid unused packages
3031
3132Coder writes packages that are used during implementation. It isn't easy to
3233validate whether an abstraction is valid until it's checked against an
3334implementation. This results in a larger changeset, but it provides reviewers
3435with a holistic perspective regarding the contribution.
3536
37+ ###Frontend
38+
39+ ####Follow component conventions
40+
41+ Each component gets its own folder. Make sure you add a test and Storybook
42+ stories for the component as well. By keeping these tidy, the codebase will
43+ remain easy-to-navigate, healthy and maintainable for all contributors.
44+
45+ ####Keep accessibility in mind
46+
47+ We strive to keep our UI accessible. When using colors, avoid adding new
48+ elements with low color contrast. Always use labels on inputs, not just
49+ placeholders. These are important for screen-readers.
50+
3651##Reviews
3752
3853> The following information has been borrowed from[ Go's review