Skip to content

Latest commit

 

History

History
87 lines (58 loc) · 3.88 KB

CONTRIBUTING.md

File metadata and controls

87 lines (58 loc) · 3.88 KB
Raw

How To Contribute

Thanks for your interest in contributing to this project and for taking the time to read this guide.

TL;DR

Pull requests should have the following guidelines:

  • Fork it https://github.com/ahmedkamals/colorize/fork.

  • Create your feature branch git checkout -b feature/my-awesome-feature.

  • Although it is highly suggested including tests, they are not a hard requirement in order to get your contributions accepted.

  • To be signed off

  • Please be generous describing your changes git commit -am 'Added some feature.'.

  • A logical series of squashed well written commits

  • Push your changes git push origin my-awesome-feature.

  • Create a pull request, and keep it small so other developers can review it quickly.

  • Keep each pull request focused on a specific topic. If you have two things to change, create two pull requests. This helps reviewers to understand the meat of your contribution.

Coding Style

Unless explicitly stated, we follow all coding guidelines from the Go community. While some of these standards may seem arbitrary, they somehow seem to result in a solid, consistent codebase.

It is possible that the code base does not currently comply with these guidelines. We are not looking for a massive PR that fixes this, since that goes against the spirit of the guidelines. All new contributions should make a best effort to clean up and make the code base better than they left it. Obviously, apply your best judgement. Remember, the goal here is to make the code base easier for humans to navigate and understand. Always keep that in mind when nudging others to comply.

The rules:

  1. All code should be pass validation checks with make validate.

  2. All code should pass the default levels of golint.

  3. All code should follow the guidelines covered in Effective Go and Go Code Review Comments.

  4. Comment the code. Tell us the why, the history and the context.

  5. Document all declarations and methods, even private ones. Declare expectations, caveats and anything else that may be important. If a type gets exported, having the comments already there will ensure it's ready.

  6. Variable name length should be proportional to its context and no longer. noCommaALongVariableNameLikeThisIsNotMoreClearWhenASimpleCommentWouldDo. In practice, short methods will have short variable names and globals will have longer names.

  7. No underscores in package names. If you need a compound name, step back, and re-examine why you need a compound name. If you still think you need a compound name, lose the underscore.

  8. No utils or helpers packages. If a function is not general enough to warrant its own package, it has not been written generally enough to be a part of a util package. Just leave it unexported and well-documented.

  9. All tests should run with make test or go test and outside tooling should not be required. No, we don't need another unit testing framework. Assertion packages are acceptable if they provide real incremental value.

  10. Even though we call these "rules" above, they are actually just guidelines. Since you've read all the rules, you now know that.

If you are having trouble getting into the mood of idiomatic Go, we recommend reading through Effective Go. The Go Blog is also a great resource. Drinking the kool-aid is a lot easier than going thirsty.

Acknowledgements

Much of this taken from https://github.com/cloudescape/gowsdl/blob/master/CONTRIBUTING.md