mirror of
https://github.com/coder/coder.git
synced 2026-09-24 15:04:27 +08:00
feat: initial docs pages (#1107)
* docs structure and edits to getting started * draft for about page * skeleton for concepts page * attempt at explaining templates * left-align tables * add best practices and variables * update structrure * update structure * templates are shared * workspaces docs * remove coming soon * fix typos * docs structure and edits to getting started * draft for about page * skeleton for concepts page * attempt at explaining templates * left-align tables * add best practices and variables * update structrure * update structure * templates are shared * workspaces docs * remove coming soon * fix typos * fix typos * Update docs/about.md Co-authored-by: Joe Previte <jjprevite@gmail.com> * remove line breaks between bullets * rename variables to parameters * reduce limits * chore: edit text * revert some changes, fix footnotes Co-authored-by: Katie Horne <katie@coder.com> Co-authored-by: Joe Previte <jjprevite@gmail.com>
This commit is contained in:
Ben Potter
co-authored by
Joe Previte
Katie Horne
Joe Previte
Katie Horne
parent
603b7da413
commit
22668c388c
+31
-26
@@ -1,48 +1,53 @@
|
||||
|
||||
# Contributing
|
||||
|
||||
## Requirements
|
||||
|
||||
`coder` requires Go 1.18+, Node 14+, and GNU Make.
|
||||
Coder requires Go 1.18+, Node 14+, and GNU Make.
|
||||
|
||||
### Development Workflow
|
||||
### Development workflow
|
||||
|
||||
The following `make` commands and scripts used in development:
|
||||
Use the following `make` commands and scripts in development:
|
||||
|
||||
- `make bin` builds binaries
|
||||
- `make install` installs binaries to `$GOPATH/bin`
|
||||
- `make test`
|
||||
- `make release` dry-runs a new release
|
||||
- `./develop.sh` hot-reloads for frontend development
|
||||
- `make release` dry runs a new release
|
||||
- `./develop.sh` hot reloads for front-end development
|
||||
|
||||
## Styling
|
||||
|
||||
### Go Style
|
||||
### Use Go style
|
||||
|
||||
Contributions must adhere to [Effective Go](https://go.dev/doc/effective_go). Linting rules should
|
||||
be preferred over documenting styles (run ours with `make lint`); humans are error prone!
|
||||
Contributions must adhere to the guidelines outlined in [Effective
|
||||
Go](https://go.dev/doc/effective_go). We prefer linting rules over documenting
|
||||
styles (run ours with `make lint`); humans are error-prone!
|
||||
|
||||
Read [Go's Code Review Comments Wiki](https://github.com/golang/go/wiki/CodeReviewComments) to find
|
||||
Read [Go's Code Review Comments
|
||||
Wiki](https://github.com/golang/go/wiki/CodeReviewComments) for information on
|
||||
common comments made during reviews of Go code.
|
||||
|
||||
#### No Unused Packages
|
||||
### Avoid unused packages
|
||||
|
||||
Coders write packages that are used during implementation. It's difficult to validate whether an
|
||||
abstraction is valid until it's checked against an implementation. This results in a larger
|
||||
changeset but provides reviewers with an educated perspective on the contribution.
|
||||
Coder writes packages that are used during implementation. It isn't easy to
|
||||
validate whether an abstraction is valid until it's checked against an
|
||||
implementation. This results in a larger changeset, but it provides reviewers
|
||||
with a holistic perspective regarding the contribution.
|
||||
|
||||
## Review
|
||||
## Reviews
|
||||
|
||||
> Taken from [Go's review philosophy](https://go.dev/doc/contribute#reviews).
|
||||
> The following information has been borrowed from [Go's review
|
||||
> philosophy](https://go.dev/doc/contribute#reviews).
|
||||
|
||||
Coders value thorough reviews. Think of each review comment like a ticket: you are expected to
|
||||
somehow "close" it by acting on it, either by implementing the suggestion or convincing the reviewer
|
||||
otherwise.
|
||||
Coder values thorough reviews. For each review comment that you receive, please
|
||||
"close" it by implementing the suggestion or providing an explanation on why the
|
||||
suggestion isn't the best option. Be sure to do this for each comment; you can
|
||||
click **Done** to indicate that you've implemented the suggestion, or you can
|
||||
add a comment explaining why you aren't implementing the suggestion (or what you
|
||||
chose to implement instead).
|
||||
|
||||
After you update the change, go through the review comments and make sure to reply to every one. You
|
||||
can click the "Done" button to reply indicating that you've implemented the reviewer's suggestion;
|
||||
otherwise, click on "Reply" and explain why you have not, or what you have done instead.
|
||||
|
||||
It is perfectly normal for changes to go through several round of reviews, with one or more
|
||||
reviewers making new comments every time and then waiting for an updated change before reviewing
|
||||
again. All contributors, including experienced maintainers, are subject to the same review cycle;
|
||||
this process is not meant to be applied selectively or discourage anyone from contribution.
|
||||
It is perfectly normal for changes to go through several rounds of reviews, with
|
||||
one or more reviewers making new comments every time, then waiting for an
|
||||
updated change before reviewing again. All contributors, including those from
|
||||
maintainers, are subject to the same review cycle; this process is not meant to
|
||||
be applied selectively or to discourage anyone from contributing.
|
||||
|
||||
Reference in New Issue
Block a user