Thank you for contributing to Fidelity's Homebrew tap! 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)
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 [email protected].
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.
Please follow the instructions in our security policy (also visible in the Security tab on the project's repo).
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.
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 beginnerhelp wanted- More involved changes This will help match your request with others who are looking for a way to get involved.
Code contributions are welcome in all of our projects as long as you follow a few rules:
- 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.
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.
If you have other questions about this project, please open an issue. To reach the Fidelity OSPO directly, please email [email protected].