Skip to content

Latest commit

 

History

History
95 lines (69 loc) · 3.77 KB

CONTRIBUTING.md

File metadata and controls

95 lines (69 loc) · 3.77 KB
Raw

Contributing Providers

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

  • Reporting a bug
  • Contributing a new provider
  • Submitting a fix
  • Proposing new features

Do you want to learn how to create your own provider? Follow the tutorial or have a look at the sample provider.

We Develop with GitHub

We use GitHub to host code, to track issues and feature requests, as well as to accept pull requests.

We Use Github Flow, So All Code Changes Happen Through Pull Requests

Pull requests are the best way to propose changes to the codebase (we use Github Flow). We actively welcome your pull requests:

  1. Before creating a pull request, please make sure it is in line with the projects' goals. If you have doubts about this, feel free to open a discussion first before spending time on a pull request that may get rejected.
  2. Fork the repo and create your branch from main.
  3. If you've added code that should be tested, add tests.
  4. Be mindful of breaking changes, please discuss these first with the maintainers. This is mainly a concern when a PR touches the PDK, but for individual providers you should be careful when changing the supported query types, or the format of the returned data.
  5. Ensure the test suite passes.
  6. Make sure your code is correctly formatted (see below).
  7. Issue that pull request!

Contributions you make will be under the Apache 2.0 License and the MIT License

In short, when you submit code changes, your submissions are understood to be under the same Apache License and MIT License that cover the project. Feel free to contact the maintainers if that's a concern.

Report bugs using GitHub's issues

We use GitHub issues to track public bugs. Report a bug by opening a new issue!

Use GitHub's discussions for other feedback

Do you want to request a new feature, or suggest another kind of change? Maybe you have a question about how to approach something? Please start a new discussion!

Write bug reports 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)

The better you help us understand your problem, the better we can help you!

Use a Consistent Coding Style

Please follow the Rust Coding Conventions.

We run cargo fmt -- --check to verify pull requests confirm to the expected style and you can use this command locally to verify your changes before pushing. In addition, we use cargo clippy to detect common issues with the code itself.

Documentation

Be careful editing any of the README.md files directly. Some contain <!-- cargo-rdme start/end --> directives, in which case you should follow these instructions to update those blocks:

  • Make modifications to <crate>/src/lib.rs
  • Make sure cargo-rdme is installed: cargo install cargo-rdme
  • Run cargo-rdme in the crate folder where you wish to update the README.

References

This document was adapted from the contribution guidelines for Transcriptase.