Skip to content

Latest commit

 

History

History
56 lines (43 loc) · 2.29 KB

Contributing.md

File metadata and controls

56 lines (43 loc) · 2.29 KB

How to contribute to did-jwt

We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:

  • Reporting a bug
  • Discussing the current state of the code
  • Submitting a fix
  • Proposing new features

Report a bug with detail, background and sample code

Great Bug Reports tend to have:

  • A quick summary and/or background
  • Steps to reproduce
    • Be specific!
    • Give sample code if you can.
  • What you expected would happen
  • What actually happens
  • Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
  • You get extra kudos if you attach a failing test demonstrating that bug

Submitting improvements

Commit messages

We use github to host code, to track issues and feature requests, as well as accept pull requests. We Use semantic-release and commitlint to automate our release process. Versioning, changelogs and publication is all covered by this automation. Please see some commit message examples

Commit messages are really important in this process, and the build will fail if your commits don't adhere to this.

Code style

Use the built in code formatter (npm run format) before committing code. It makes lives much easier.

Submitting a fix

  • Branch off of master
  • Wherever possible, commit at least one test to demonstrate the bug
  • Commit your code to fix that bug
  • Create a PR for it
    • Mention the issue you're fixing in the PR (Example: Closes #17)

Submitting a proposal

We prefer to discuss proposals before accepting them into the codebase. Open an issue with as much detail and background as possible to make your case. Small proposals can come in directly as PRs, but it's generally better to discuss before starting work.

Any contributions you make will be under the Apache-2.0 License

Posting PRs

  • Describe your changes in the PR description.
  • Mention issues that should be fixed or closed when the PR is merged.
  • Make sure any new code has tests associated!
  • Make sure the documentation is still valid if your changes get included.

Thank you for your contribution!