Make contribution rules explicitly

[KimMachineGun]

Now, gramework's contribution rules were unclear. And code style was not unified. It makes problem to contribute to this project. 😢

Needs

1. Explicit documentation rules
2. Unified code style

I think we need to discuss this proposal to make a better project.

[kirillDanshin]

@KimMachineGun I agree.

We need to update contribution rules.

Altho, we need to figure out the list of rules and how exactly we want that to look and feel.

[kirillDanshin]

@toby3d that's all not about linters yet, this is about dos and don'ts

[ninedraft]

My IMHOs:

• code must be formatted
• code must pass all tests
• code must pass minimum test coverage level test? (not sure)
• code must pass some basic linter checks (go vet at least). Maybe custom linters?
• two different commit styles:
  • small granular commits-per-mutation
  • commit-per-feature with big commit message: problem to be solved, short desc, etc.
• every new dependency must be imported by reason, discussed and fixed on a minor version of commit hash
• dependency blacklist: "golang.org/x/net/context", etc.
• benchmark degradation tests?

[KimMachineGun]

@ninedraft LGTM 👍
And, I think we also need more benchmark codes.

[toby3d]

• must be go fmt
  • Indents with tabs (with width 8), no spaces
  • In import external packages are separated from native by empty line
  • Maximum line lenght is 120 characters
• pass all tests
• coverage >=80%
• pass golangci-lint default linters
• optional: pass go-critic default linters
• all new dependends must be explained by go mod why

[jirfag]

JFYI: golangci-lint can run go-critic starting from v1.12 release

[toby3d]

@jirfag Wow, okay 😮

[ninedraft]

Consistency control in Go

Linters:

• go-consistent
• go-namecheck