Contributing Guidelines and Agreement for MagicScript

To ensure the health of the MagicScript ecosystem, in addition to the Apache License 2.0, Contributors to MagicScript must additionally agree to, and follow, these guidelines.

MagicScript is a community effort: it can only be great if we all help out in one way or another. If you feel like you aren't experienced enough to contribute, you can still make an impact by:

  • Responding to one of the open issues. Even if you can't resolve or fully answer a question, asking for more information or clarity on an issue is extremely beneficial for someone to come after you to resolve the issue.
  • Providing feedback on the open PRs.
  • Commenting on the Forums for MagicScript.

If you would like to submit a pull request, please follow this Contributors guide to find out how.

Ways You Can Help With Issues

For any issue, there are fundamentally three ways an individual can help:

  1. By opening the issue for discussion: For instance, if you believe that you have uncovered a bug creating a new issue in issue tracker is the way to report it.
  2. By helping to triage the issue: This can be done either by providing supporting details (a test case that demonstrates a bug), or providing suggestions on how to address the issue.
  3. By helping to resolve the issue: Typically this is done either in the form of demonstrating that the issue reported is not a problem after all, or more often, by opening a Pull Request that changes some bit of code in a concrete and reviewable manner.

Contributions

Any material, including code, you submit to the project, e.g. in Pull Requests or as comments in Issues, is a “Contribution” to the project as defined in the Apache License 2.0. In accordance with the “Separate license terms” of Item 5 in the Apache License 2.0, by making a Contribution, you additionally agree to and assert that you meet all of the below conditions:

  1. You own and have all the rights to the Contribution;
  • If you do not own and have all the rights to the Contribution (e.g., if code in the Contribution constitutes a work-for-hire to your employer or you are a joint author of code in the Contribution), then: i) you have acquired authorization(s) from all the holder(s) of the rights in the Contribution to submit the Contribution to this project under the Apache License 2.0; and (ii) you have forwarded a written copy of each of those authorizations to Magic Leap before submitting the Contribution; and
  1. To the extent the Contribution includes dependencies with upstream licenses:
  • You have the right to submit the upstream dependency as a Contribution to this project under the terms of each upstream license;
  • None of the upstream licenses include terms (e.g., copyleft terms) preventing the licensing of the project, including the Contribution, under the terms of the Apache License 2.0; and
  • As incorporated into the project, your Contribution complies with all of the upstream licenses.

Per Item #2 above, if your Contribution includes any upstream dependencies, please identify in your Contribution for each of the upstream dependencies:

  1. the name(s) of the author(s) of the upstream dependency and any accompanying copyright notice(s);
  2. the name and version of the dependency;
  3. a copy of the license under which you acquired the dependency; and
  4. any other documentation (e.g., NOTICE or LICENSE files) required to be included in downstream distributions under the dependecy’s license.

Attribution of Changes

When contributors submit a change to a MagicScript project, after that change is approved, other developers with commit access may commit it for the author. When doing so, it is important to retain correct attribution of the contribution. Generally speaking, Git handles attribution automatically.

Code Review Guidelines

MagicScript projects rely on code review to improve software quality:

  • All significant changes, by all developers, must be reviewed by a Magic Leap developer before they are committed to the repository.
  • Code reviews are conducted on GitHub through comments on pull requests or commits.
  • The developer responsible for a code change is also responsible for making all necessary review-related changes.
  • Minor review-related changes can be accepted as a separate commit on the same pull request.

Code review can be an iterative process, which continues until the change is ready to be committed. After a change is sent out for review it needs an explicit approval before it’s submitted. Do not assume silent approval or request active objections to the patch by setting a deadline.

Sometimes code reviews will take longer than you would hope for, especially for larger features. Here are some accepted ways to speed up review times for your patches:

  • Review other people’s changes. If you help out, everybody will be more willing to do the same for you. Goodwill is our currency.
  • Split your change into multiple smaller changes. The smaller your change, the higher the probability that somebody will take a quick look at it.
  • Ping the change. If it is urgent, provide reasons why it is important to get this change landed and ping it every couple of days. If it is not urgent, the common courtesy ping rate is one week. Remember that you’re asking for valuable time from other professional developers.

Note that anyone is welcome to review and give feedback on a change, but only people with commit access to the repository can approve it.