If you believe you have discovered a security vulnerability, please do not open an issue or make a pull request. Follow the instructions in the SECURITY.MD file in this repository.
Thank you for your interest in contributing to a MathWorks repository! We encourage contributions large and small to this repository.
Contributions do not have to be code! If you see a way to explain things more clearly or a great example of how to use something, please contribute it (or a link to your content). We welcome issues even if you don't code the solution. We also welcome pull requests to resolve issues that we haven't gotten to yet!
- Open an issue: Start by creating an issue in the repository that you're interested in. That will start a conversation with the maintainer. When you are creating a bug report, please include as many details as possible. Please remember that other people do not have your background or understanding of the issue; make sure you are clear and complete in your description.
- Work in your own public fork: If you choose to make a contribution, you should fork the repository. This creates an editable copy on GitHub where you can write, test, and refine your changes. We suggest that you keep your changes small and focused on the issue you submitted.
- Sign a Contributor License Agreement (CLA): We require that all outside contributors sign a CLA before we can accept your contribution. When you create a pull request (see below), we'll reach out to you if you do not already have one on file. Essentially, the CLA gives us permission to publish your contribution as part of the repository.
- Make a pull request: "Pull Request" is a confusing term, but it means exactly what it says: You're requesting that the maintainers of the repository pull your changes in. If you don't have a CLA on file, we'll reach out to you. Your contribution will be reviewed, and we may ask you to revise your pull request based on our feedback. Once everyone is satisfied, we'll merge your pull request into the repository.
We don't have best practices for writing MATLAB® code, but we do have some recommendations:
- You should not have any warnings or errors in the code analyzer report
- Loren Shure's blog has great advice on improving your MATLAB code
- Examples should be written as live scripts and then exported as HTML.
- We adhere to the CommonMark specification where it does not conflict with GitHub rendering. If you edit your Markdown in Visual Studio Code or a similar editor, it uses markdownlint to highlight issues in your Markdown.
Again, thanks for contributing, and we look forward to your issues and pull requests!