Contribution Guide
Table of contents
- Welcome
- Things you’ll need
- Before contributing
- How to contribute?
- Non-code related contributions
- Continuous Integration
- Organization
- Styleguide
Welcome
I am very happy to see you’ve taken the interest to look at the guidelines for contributing to Cryptor. The topics covered below are simple guidelines and nothing is set in stone, use your judgment to save everyone time, always ask yourself “is X something I would do?”, before proposing it.
Please note this is not a Development Guide (an introduction to bits of code and how to handle the project), but a set of instructions and recommendations for getting started with adding changes to the codebase and community. A Developer Guide will be provided on the wiki.
Things you’ll need
- Git, version control
- Copy of the project
- Go programming language
- Installation instructions, source code and releases for the major operating system can be found here
- Check your version by running
go version
in your terminal- Cryptor is being developed to work using the latest version (
v1.12
) - Soon, I’ll post the oldest Go version Cryptor can run on
- Cryptor is being developed to work using the latest version (
- To get started with Go I recommend the Go Tour, an interactive tutorial
- You can work from any IDE you prefer, there are no IDE dependencies
- Certain IDEs are recommended (or certain plugins for your favourite IDE)
- The code style used in all Go source files must respect
vet
andfmt
standards, see this for more information - Golang FAQ
- Websites for researching packages or documentation
Before contributing
- Check the F.A.Q. over on the wiki
- If you wish, reach out to the community over on Discord.
- Check the issues, projects and PRs for any existing materials
- If in doubt, contact me
[email protected]
(please useCryptor:
in your subject) - Make sure you have your development setup working and you can run the Cryptor tests (
make test
)
How to contribute?
Report bugs and issues
In order to open new issues head over to the GitHub issues page and select “New Issue”, use the “Bug report” template. Make sure the label bug
is used and any other relevant labels (see below).
Propose enhancement or optimizations
Before proposing any enhancement or optimizations have some arguments and demo/prototype/benchmark/… to improve the chances of being considered. These proposals are also created on the GitHub issues page using the “Enhancement/Optimizations Proposal” template. Make sure the right label is used (optimization
or enhancement
, see explanation below)
Propose new features
Consider the security, privacy and costs of implementing the feature you dream of. After that open a new issue on the GitHub issues page. Use the “Feature request” template and appropriate labels.
Propose tests
Feel free to skip opening an issue for adding or changing tests. You can skip straight to a PR.
How to PR
Not many rules for Pull Requests. Make sure your version is compiling, respecting all language standards, all tests are passing and code is up to the Style Guidelines. After that open a PR and wait 3-5 days. Longer than that, feel free to @
mention me or drop me an email.
Non-code related contributions
Documentation
New documentation, spell checking, overall layout improvements, etc, are all welcome too. Issues can be opened as discussions
but I would rather you join the Discord server and discuss ideas openly there.
Network volunteer
The Cryptor Network will require nodes to function and test the initial versions. Any node helps, no matter the hardware, it can be a Raspberry Pi, a supercomputer, a VPS or your home desktop/laptop.
Continuous Integration
The current continuous integration pipeline is simple:
- Push changes to GitHub
- Travis-CI runs tests and pushes code coverage to coveralls
- Coveralls detects any major drop in coverage
Organization
Labels
All issues must be labeled accordingly. You can see the live list of issue labels over here with their respective descriptions. If in doubt don’t worry, a collaborator will fix any misused labels.
Projects
Projects and [milestones](https://github.com/cpl/cryptor/milestones_ give a sense of progress and direction to the overall Cryptor project. The boards are basic Kanbans with Backlog
(todo), In Progress
(doing) and Done
for organizing issues and other notes.
Styleguide
Commit Messages
- Pad your commit subject with the package in which the modifications are
p2p/node: extend SetAddr argument validation to cover special case
foo/bar/zulu: refactor legacy code to v1.2.3 standards
- Please do not include emojis (or any Unicode runes) in commit messages, I wish for the git history to be accessible in any environment
- Limit the commit subject to 72 characters or less
- Keep the subject simple and clear
- For any message longer than that use the commit description
git commit -m "Subject string" -m "Description string"
- Use the present tense and imperative mood
add test for special case
, notadded test for ...
... to move files ...
, not... that moves files ...
- Use
[ci skip]
[skip ci]
to skip certain CI builds which are mainly documentation or non-sourcecode related, Travis-CI doc
Golang Code
- Respect
fmt
(link)Gofmt formats Go programs. It uses tabs for indentation and blanks for alignment. Alignment assumes that an editor is using a fixed-width font.
- Respect
vet
Vet examines Go source code and reports suspicious constructs, such as Printf calls whose arguments do not align with the format string. Vet uses heuristics that do not guarantee all reports are genuine problems, but it can find errors not caught by the compilers.
- Respect
godoc
(link) - Respect
gofumpt
(link)- An unofficial backwards compatible (with the official
fmt
) formatting guideline
- An unofficial backwards compatible (with the official