- Submit an issue describing your proposed change.
- Discuss and wait for proposal to be accepted.
- Fork this repo, develop and test your code changes.
- Submit a pull request.
Please read through below conventions before contributions.
- Use Conventional Commits specification to standardize PR title.
- Go Code Review Comments
- Effective Go
- Know and avoid Go landmines
- Commenting
- Go's commenting conventions
- If reviewers ask questions about why the code is the way it is, that's a sign that comments might be helpful.
- Naming
- Please consider package name when selecting an interface name, and avoid redundancy. For example,
storage.Interface
is better thanstorage.StorageInterface
. - Do not use uppercase characters, underscores, or dashes in package names.
- Please consider parent directory name when choosing a package name. For example,
pkg/controllers/autoscaler/foo.go
should saypackage autoscaler
notpackage autoscalercontroller
.- Unless there's a good reason, the
package foo
line should match the name of the directory in which the.go
file exists. - Importers can use a different name if they need to disambiguate.
- Unless there's a good reason, the
- Locks should be called
lock
and should never be embedded (alwayslock sync.Mutex
). When multiple locks are present, give each lock a distinct name following Go conventions:stateLock
,mapLock
etc.
- Please consider package name when selecting an interface name, and avoid redundancy. For example,
- All filenames should be lowercase.
- Go source files and directories use underscores, not dashes.
- Package directories should generally avoid using separators as much as possible. When package names are multiple words, they usually should be in nested subdirectories.
- Document directories and filenames should use dashes rather than underscores.
- All source files should add a license at the beginning.