Skip to content

Latest commit

 

History

History
61 lines (46 loc) · 3.8 KB

CONTRIBUTING.md

File metadata and controls

61 lines (46 loc) · 3.8 KB
Raw

Contributing to this repository

Getting started

Welcome! We're excited you want to take part in the rusty-falcon community!

Please review this document for details regarding getting started with your first contribution, packages you'll need to install as a developer, and our Pull Request process. If you have any questions, please let us know by posting your question as an issue.

Before you begin

  • Have you read the Code of Conduct? The Code of Conduct helps us establish community norms and how they'll be enforced.

Table of Contents

How you can contribute

  • See something? Say something! Submit a bug report to let the community know what you've experienced or found. Bonus points if you suggest possible fixes or what you feel may resolve the issue. For example: "Attempted to use the XZY API class but it errored out. Could a more descriptive error code be returned?"
  • Submit a Pull Request

Bug reporting and questions are handled using GitHub's issues

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

Pull Requests

All contributions will be submitted under the Unlicense license

When you submit code changes, your submissions are understood to be under the same Unlicense license that covers the project. If this is a concern, contact the maintainers before contributing.

Breaking changes

In an effort to maintain backwards compatibility, we thoroughly unit test every Pull Request for all versions of Python we support. These unit tests are intended to catch general programmatic errors, possible vulnerabilities (via bandit) and potential breaking changes.

If you have to adjust a unit test locally in order to produce passing results, there is a possibility you are working with a potential breaking change.

Please fully document changes to unit tests within your Pull Request. If you did not specify "Breaking Change" on the punch list in the description, and the change is identified as possibly breaking, this may delay or prevent approval of your PR.

Versioning

We use SemVer as our versioning scheme. (Example: 2.1.4)

Pull Request template

Please use the pull request template provided, making sure the following details are included in your request:

  • Is this a breaking change?
  • Are all new or changed code paths covered by unit testing?
  • A complete listing of issues addressed or closed with this change.
  • A complete listing of any enhancements provided by this change.
  • Any usage details developers may need to make use of this new functionality.
    • Does additional documentation need to be developed beyond what is listed in your Pull Request?
  • Any other salient points of interest.

Approval / Merging

All Pull Requests must be approved by at least one maintainer. Once approved, a maintainer will perform the merge and execute any backend processes related to package deployment. At this time, contributors do not have the ability to merge to the main branch.

Suggestions

If you have suggestions on how this process could be improved, please let us know by posting an issue.