👍🎉 Thanks for taking the time to contribute! 🎉👍
Feel free to open issues if you...
- ...found a problem with
fritzctl
or the documentation, - ...have a question about
fritzctl
or the documentation, - ...want a new feature in
fritzctl
.
If the issue should not be disclosed in public, contact the maintainer and encrypt the message using PGP with the public key 4096R/8A896560
Contributions to the codebase of fritzctl
should be proposed in the form of a pull request using
GitHub. To this end create a fork of this repository.
Within git...
- Keep the number of commits small. Ideally, "one commit = one feature" or "one commit = one bugfix".
- Try to follow the 7 rules of a great commit message.
- If a commit addresses a known issue, include the issue number in the commit message.
- Don't worry if something went wrong, most mistakes can be fixed.
The coding conventions...
- Format code according to
gofmt
. - Test your code.
- If new 3rd party dependencies arise, reflect if those can be avoided.
make codequality
gives a hint on common problems.- Further reading: golang/CodeReviewComments.
When changes make a large impact...
- Do the changes break backward compatibility of the cli? The commit message and pull request description should say so. It may be that these changes are delayed until the next major version release.
- Do the changes break backward compatibility of the API? The same comments from above apply.