Skip to content

Latest commit

 

History

History
73 lines (44 loc) · 5.28 KB

CONTRIBUTING.md

File metadata and controls

73 lines (44 loc) · 5.28 KB
Raw

Contributing to MABWiser

Thank you for contributing to MABWiser! This guide will help you get started and know what to expect. All contributions and project spaces are subject to our Code of Conduct.

We welcome all types of contributions, including:

  • Code contributions
  • Bug reports
  • Responsibly disclosed security concerns
  • Documentation fixes
  • Feature requests and user stories (although we can't guarantee we'll get to all requests, it's helpful to know where we can improve)

If you end up using our library in a project, give us a star on GitHub!

Please note that we periodically fork upstream repos to stage contributions from Fidelity. We do not accept contributions against these forked repos, and request you make contributions against upstream projects directly.

If you have any questions, please contact opensource@fmr.com.

How to report a bug

Please open an issue unless you are making a significant security disclosure.

When reporting a bug, please start from a fresh pull of the default branch and document how you encountered the issue. Reports with insufficient detail and which we can't reproduce may be closed without action.

While bugs can be frustrating, we ask participants to contribute positively and professionally to the discourse. While we commit to take the contents of the report seriously, abusive behavior be will not be tolerated.

How to disclose security concerns responsibly

Please follow the instructions in our security policy (also visible in the Security tab on the project's repo).

How to contribute documentation fixes

Minor documentation fixes can be submitted directly as a pull request without filing an issue in advance. More significant changes (e.g., refactoring to support a new documentation format, major reorganizations of content, etc.) should first be discussed in an issue to ensure everyone's time is used effectively.

When opening a PR or issue with a documentation change, please add a documentation label.

How to request features or submit a user story

To request a feature please open an issue and tag it as feature enhancement. If you already have an implementation, please link the pull request to the issue.

Please include as much information and context as you can. Understanding how the feature solves a specific problem will help us prioritize the request. Please understand that we will not be able to provide an implementation timeline on all requests, although requests that include an implementation are more likely to land sooner.

If you won't do the work yourself, please also add a good first issue or help wanted label. These are special issue tags which are intended to help new and existing contributors get involved in a meaningful and accessible way.

  • good first issue - Small changes that are suitable for a beginner
  • help wanted - More involved changes This will help match your request with others who are looking for a way to get involved.

Code contributions

Code contributions are welcome in all of our projects as long as you follow a few rules:

  • With any piece of code, please adhere to PEP-8 standards.
  • If you're fixing an issue with an existing piece of code, please make sure all the tests pass, and there is no change in functionality.
  • If you want to add a new feature, please open up an issue first.
  • When adding a new feature, make sure you have relevant test coverage.
  • Any changes to the public API should conform to the current standards, be properly documented, typed, and be intuitive.
  • Your contribution must be received under the project's open source license.
  • You must have permission to make the contribution. We strongly recommend including a Signed-off-by line to indicate your adherence to the Developer Certificate of Origin.
  • All code contributions must be made via PR, and all checks must pass before merging.

While not strictly necessary, we encourage you to open an issue prior to your pull request to let the project know to expect your code. This helps the team plan for the next release and may result in your feature being a higher priority, and also decreases the likelihood of two independent contributions that do the same thing.

Documentation contributions

  • Make sure you follow the standards set by the rest of the repo.
  • Be concise, but do not omit details. Verbose documentation is preferred to incomplete documentation.

Getting started (and helping others find their footing)

Anyone may open an issue and apply a good first issue or help wanted label for others to work on. We only ask that when someone else picks up your issue and decides to work on it that you be responsive to their questions.

Getting help

If you have other questions about this project, please open an issue. To reach the Fidelity OSPO directly, please email opensource@fmr.com.