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!

Read

[Go's Code Review Comments Wiki](https://github.com/golang/go/wiki/CodeReviewComments)

to find common comments made during reviews of Go code.

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.

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.

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.