Skip to content

Latest commit

 

History

History
85 lines (61 loc) · 4.71 KB

CONTRIBUTING.org

File metadata and controls

85 lines (61 loc) · 4.71 KB

Contributing

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!

How to contribute

  • 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. We would also appreciate if you create a new (lightweight) branch for your changes, and please make sure that the branch name is not already used in the original repository.
  • 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.

Guidelines

  1. Emacs LISP code
    • Should be indented using the default Emacs indentation.
    • Use Unix (LF) line endings in *.el files
    • Pass emacs-lisp syntax checker in flycheck.
    • Have no warnings (make should produce no warnings)
    • Add tests when possible
    • Pass make tests
  2. MATLAB code

    We don’t have best practices for writing MATLAB®; code, but we do have some recommendations:

Again, thanks for contributing, and we look forward to your issues and pull requests!

Maintainers

Maintainers (those with write access) can either use branches, forks, or commit directly to the primary default branch.

  1. Branches. For work that involves contributions from multiple people, branches are preferred.
  2. Forks. Forks could be used where you are the primary coder and you would like another maintainer to look at your changes. When ready you create a pull request and the other maintainer will put your changes on the default branch.
  3. Direct commits. For simple stuff, maintainers can directly submit to the default branch.

Uwe Brauer is the primary maintainer and tries to look at all significant changes. He however prefers direct commits or branches.