Skip to content

Latest commit

 

History

History
68 lines (35 loc) · 5.18 KB

CONTRIBUTING.md

File metadata and controls

68 lines (35 loc) · 5.18 KB

Contributing Guidelines

Contents

This guide serves to set clear expectations for everyone involved with the project so that we can improve it together while also creating a welcoming space for everyone to participate. Following these guidelines will help ensure a positive experience for contributors and maintainers.

📖 Code of Conduct

Please review our Code of Conduct. It is in effect at all times. We expect it to be honored by everyone who contributes to this project.

📥 Opening an Issue

🪲 Bug Reports

A great way to contribute to the project is to send a detailed issue when you encounter a problem using our models. We always appreciate a well-written, thorough bug report. ✌️

Please open an issue with the Bug Report template and fill out all the required information.

  • Do not open a duplicate issue! Search through existing issues to see if your issue has previously been reported. If your issue exists, comment with any additional information you have.

  • Fully complete the provided issue template. The bug report template requests all the information we need to quickly and efficiently address your issue. Be clear, concise, and descriptive. Provide as much information as you can, including steps to reproduce, stack traces, compiler errors, library versions, OS versions, and screenshots (if applicable).

💌 Feature Requests

Feature requests are welcome! We will consider all requests, and get back on whether we are able to accept the request and if it fits in with the vision of the project. We may ask you to create a pull request and contribute the desired feature in some cases.

To create a feature request, open an issue with Feature Request template.

  • Do not open a duplicate feature request. Search for existing feature requests first. If you find your feature (or one very similar) previously requested, comment on that issue.

  • Fully complete the provided issue template. The feature request template asks for all necessary information for us to begin a productive conversation.

  • Be precise about the proposed outcome of the feature and how it relates to existing features. Include implementation details if possible.

🔁 Submitting Pull Requests

We encourage pull requests! Before forking the repo and creating a pull request for non-trivial changes, it is usually best to first open an issue to discuss the changes, or discuss your intended approach for solving the problem in the comments for an existing issue.

  • Smaller is better. Submit one pull request per bug fix or feature. A pull request should contain isolated changes pertaining to a single bug fix or feature implementation. Do not refactor or reformat code that is unrelated to your change. It is better to submit many small pull requests rather than a single large one. Enormous pull requests will take enormous amounts of time to review, or may be rejected altogether.

  • Coordinate bigger changes. For large and non-trivial changes, open an issue to discuss a strategy with the maintainers.

  • Follow existing coding style and conventions. If contributing any code, keep your code consistent with the style, formatting, and conventions in the rest of the code base. If contributing to other repositories linked from this one, follow the contributing guidelines of those repos. Add unit tests or UI tests when possible. Follow existing patterns for implementing tests.

  • Update the example project or any documentation if one exists to exercise any new functionality you have added.

  • Use the repo's default branch. Branch from and submit your pull request to the repo's default branch. Usually this is main, but it could be dev, develop, or master.

  • Resolve any merge conflicts that occur.

  • Promptly address any CI failures. If your pull request fails to build or pass tests, please push another commit to fix it.

  • When writing comments, use properly constructed sentences, including punctuation.

  • Write detailed commit messages. Commit messages should explain what is being solved.

✅ Code Review

Once you've created a pull request, maintainers will review your code and may make suggestions to fix before merging. It will be easier for your pull request to receive reviews if you consider the criteria the reviewers follow while working.

Maintainers are encouraged to perform "squash and merge" actions on PRs in this repository. Thus, it doesn't matter how many commits your PR has, as they will end up being a single commit after merging.