Thank you for considering contributing to Hanko! Following are the guidelines we would like you to follow:
- Code of Conduct
- Communication
- Reporting Issues
- Feature Requests
- Submitting Code
- Commit Message Guidelines
- Style Guidelines
We expect all contributors to adhere to our Code of Conduct.
If you have any questions, want to discuss bugs or feature requests, or just want talk to other Hanko users you are welcome to join our Slack community or use the Hanko Discussions (especially useful for long term discussion or larger questions).
Reporting issues requires a GitHub account. Please do not use the issue tracker for general support questions but use the above mentioned communication channels.
Pursuant to our security policy, any security vulnerabilities should be reported directly to
security@hanko.io
instead of using the issue tracker.
Bugs are tracked as GitHub issues. When reporting a bug choose "Bug Report" when creating a new issue. Doing so will present you with a template form to fill out. Be as detailed as possible. Good bug reports are vital, so thank you for taking the time!
Before reporting a bug:
- Take a look at the existing issues and make sure the issue hasn't already been reported. If you find a similar bug and the issue is still open, consider adding a comment providing any new information that you might be able to report.
- Make sure the issue hasn't been fixed already. Try to reproduce it using the latest
main
branch in the repository if you were not working with the latest version. - Make sure the bug is really a bug. If you need general support or are unsure whether some behaviour represents a bug please do not file a bug ticket but reach out through the above mentioned communication channels.
- Gather as much information about the bug as you can. Logs, screenshots/screen captures, steps to reproduce the bug can be vital for a useful bug report.
If you already have suggestions on how to fix the bug, do not hesitate to include them in the bug description.
Just like bugs, feature requests are tracked as GitHub issues. When suggesting an enhancement choose "Feature Request" when creating a new issue and fill out the template form.
Before making a feature request:
- Take a look at the existing issues and make sure the issue hasn't already been reported.
- Make sure the issue hasn't been implemented already. Always try using the latest
main
branch in the repository if to confirm the feature is not already in place.
When filling out the template form, be sure to be as detailed as possible. Describe the current behavior and explain which behavior you expect to see instead. Explain why this enhancement would be useful to Hanko users.
Contributing code requires a GitHub account. All contributions are made via
pull requests.
Pull requests should target the main
branch.
To submit your code:
- Fork the repository.
- Clone the forked repository.
- Configure remotes.
- Create a new branch
off of the
main
branch.git checkout -b <new-branch-name>
- Make your changes. Make sure to follow the Style Guidelines. Commit your changes.
Commit messages should follow the Commit Message Guidelines.
git add -A git commit
- Make sure to update, or add to any tests where appropriate. Try to run tests locally first (
go test ./...
for thebackend
, see the README for thee2e
tests on how to run them). - If you added or changed a feature, make sure to document it in the README.md file. If your change
affects the
backend
API update the Open API spec(s). If your changes affect thebackend
configuration, update the Config.md. - Push your feature branch up to your fork:
git push origin <feature-branch-name>
- Create a pull request from your fork.
- Submit the pull request by filling out the pull request template (note: the template should be displayed automatically once you open a pull request; take account of the comments in the displayed template).
- If a pull request is not ready to be reviewed it should be marked as a "Draft".
When pull requests fail test checks, authors are expected to update their pull requests to address the failures until the tests pass. If you have trouble or questions on how to add to existing tests, reach out through our communication channels.
Commit messages should adhere to the Conventional Commits specification. The commit message should be structured as follows:
<type>(<optional scope>): <description>
<optional body>
<optional footer(s)>
The commit message headline should have the following structure:
<type>(<optional scope>): <description>
│ │ │
│ │ └─⫸ Summary in present tense. Not capitalized. No period at the end.
│ │
│ └─⫸ Commit Scope: optional
│
└─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test|chore
The <type>
should be one of the following:
- build: Changes that affect the build system
- ci: Changes that affect the CI workflows (e.g. changes to
.github
CI configuration files) - docs: Documentation only changes (this includes both content in the
docs
as well as changes to readmes) - feat: A new feature
- fix: A bug fix
- perf: A code change that improves performance
- refactor: A code change that neither fixes a bug nor adds a feature
- test: Adding missing tests or correcting existing tests
- chore: Anything that cannot be categorized properly using the above prefixes (e.g. increasing versions)
The <scope>
is optional. If present, it should be the name of the (npm) package or directory affected by the changes of
the commit.
Go files should be formatted according to gofmt's rules.
# single file
go fmt path/to/changed/file.go
# all files, e.g. in 'backend' directory
go fmt ./...