Skip to content

Latest commit

 

History

History
59 lines (40 loc) · 2.91 KB

CONTRIBUTION.md

File metadata and controls

59 lines (40 loc) · 2.91 KB
Raw

Contributing to SYPL

Thank you for your interest in SYPL. Your contributions are highly welcome.

There are multiple ways of getting involved:

Report a bug

Reporting bugs is one of the best ways to contribute. Before creating a bug report, please check that an issue reporting the same problem does not already exist. If there is such an issue, you may add your information as a comment.

To report a new bug you should open an issue that summarizes the bug and set the label to "bug".

If you want to provide a fix along with your bug report: That is great! In this case please send us a pull request as described in section Contribute Code.

Suggest a feature

To request a new feature you should open an issue and summarize the desired functionality and its use case. Set the issue label to "feature".

Contribute code

The following guidelines aim to point to a direction that should drive the codebase to increased quality.

  • Each package should have a doc.go file.
  • Think before you make changes, design, then code. Design patterns, and well-established techniques are your friend. They allow to reduce code duplication and complexity and increase reusability and performance.
  • Documentation is essential! Relevant comments should be added focusing on the why, not in the what. Pay attention to the punctuation and casing patterns
  • Pay attention to how the code is vertically spaced and positioned, also sorted (always ascending) for example, the content of a struct, vars and const declarations, and etc.
  • If you use VSCode IDE, the Go extension is installed, and properly setup, it should obey the configuration file (.golangci.yml) for the linter (golangci) and show problems the right way, otherwise, just run $ make lint. The same thing applies to test. If you open a test file (*_test.go), modify and save it, it should automatically run tests and shows coverage; otherwise, just run $ make test
  • Always run $ make coverage lint before you commit your code; it will save you time!
  • If you spotted a problem or something that needs to be modified/improved, do that right way; otherwise, that with // TODO:
  • Update the CHANGELOG.md but not copying your commits messages - that's not its purpose. Use that to plan changes too.

Release

  1. Create a branch, commit update and push
  2. Once all test pass and PR is approved, merge
  3. Update the changelog
  4. Create a new release by creating a tag
git checkout master
git pull origin master # fetch latest code
git tag -a "vX.X.X"
  1. Push tag
git push origin master --tags
  1. Create a "GitHub release" from tag

Have fun, and happy hacking!