1
-
2
1
# Contributing
3
2
4
3
## Requirements
@@ -16,7 +15,9 @@ Use the following `make` commands and scripts in development:
16
15
17
16
## Styling
18
17
19
- ### Use Go style
18
+ ### Backend
19
+
20
+ #### Use Go style
20
21
21
22
Contributions must adhere to the guidelines outlined in [ Effective
22
23
Go] ( https://go.dev/doc/effective_go ) . We prefer linting rules over documenting
@@ -26,13 +27,27 @@ Read [Go's Code Review Comments
26
27
Wiki] ( https://github.com/golang/go/wiki/CodeReviewComments ) for information on
27
28
common comments made during reviews of Go code.
28
29
29
- ### Avoid unused packages
30
+ #### Avoid unused packages
30
31
31
32
Coder writes packages that are used during implementation. It isn't easy to
32
33
validate whether an abstraction is valid until it's checked against an
33
34
implementation. This results in a larger changeset, but it provides reviewers
34
35
with a holistic perspective regarding the contribution.
35
36
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
+
36
51
## Reviews
37
52
38
53
> The following information has been borrowed from [ Go's review
0 commit comments