Skip to content

Latest commit

 

History

History
105 lines (77 loc) · 3.96 KB

CONTRIBUTING.rst

File metadata and controls

105 lines (77 loc) · 3.96 KB
Raw

Contributing

If you would like to contribute to Provider API Example, please take a look at the current issues. If there is a bug or feature that you want but it isn't listed, make an issue and work on it.

Bug reports

Before raising an issue, please ensure that you are using the latest version of provider-pact-example.

Please provide the following information with your issue to enable us to respond as quickly as possible.

  • The relevant versions of the packages you are using.
  • The steps to recreate your issue.
  • The full stacktrace if there is an exception.
  • An executable code example where possible

Guidelines for bug reports:

  • Use the GitHub issue search — check if the issue has already been reported.
  • Check if the issue has been fixed — try to reproduce it using the latest main branch in the repository.
  • Isolate the problem — create a reduced test case and a live example.

A good bug report shouldn't leave others needing to chase you up for more information. Please try to be as detailed as possible in your report. What is your environment? What steps will reproduce the issue? What OS experience the problem? What would you expect to be the outcome? All these details will help people to fix any potential bugs.

Feature requests

Feature requests are welcome. But take a moment to find out whether your idea fits with the scope and aims of the project. It's up to you to make a strong case to convince the project's developers of the merits of this feature. Please provide as much detail and context as possible.

Pull requests

Good pull requests - patches, improvements, new features - are a fantastic help. They should remain focused in scope and avoid containing unrelated commits.

Follow this process if you'd like your work considered for inclusion in the project:

  1. Check for open issues or open a fresh issue to start a discussion around a feature idea or a bug.
  2. Fork the repository on GitHub to start making your changes to the main branch (or branch off of it).
  3. Write a test which shows that the bug was fixed or that the feature works as expected.
  4. Send a pull request and bug the maintainer until it gets merged and published.

If you are intending to implement a fairly large feature we'd appreciate if you open an issue with GitHub detailing your use case and intended solution to discuss how it might impact other work that is in flight.

We also appreciate it if you take the time to update and write tests for any changes you submit.

By submitting a patch, you agree to allow the project owner to license your work under the same license as that used by the project.

Commit messages

Provider API Example is adopting the Conventional Commits convention. Please ensure you follow the guidelines.

Take a look at the git history (git log) to get the gist of it.

If you'd like to get some CLI assistance there is a node npm package. Example usage is:

$ npm install -g commitizen
$ npm install -g cz-conventional-changelog
$ echo '{ "path": "cz-conventional-changelog" }' >| ~/.czrc

When you commit with Commitizen, you'll be prompted to fill out any required commit fields at commit time. Simply use git cz or just cz instead of git commit when committing. You can also use git-cz, which is an alias for cz.

See https://www.npmjs.com/package/commitizen for more info.

Resources