Skip to content

Latest commit

 

History

History
136 lines (79 loc) · 8.92 KB

CONTRIBUTING.md

File metadata and controls

136 lines (79 loc) · 8.92 KB
Raw

Welcome to the Ready Player Me Unity SDK (Core) contributing guide

Thank you for investing your time in contributing to our project! Any contribution you make will be reflected on https://github.com/readyplayerme/Unity-Core ✨.

Read our Code of Conduct to keep our community approachable and respectable.

In this guide you will get an overview of the contribution workflow from opening an issue, creating a PR, reviewing, and merging the PR.

Use the table of contents icon on the top left corner of this document to get to a specific section of this guide quickly.

New contributor guide

To get an overview of the project, read the README. Here are some resources to help you get started with open source contributions:

FAQ

Did you find a bug?

  • Ensure the bug was not already reported by searching on GitHub under Issues.

  • If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case demonstrating the expected behavior that is not occurring.

  • If possible, use the relevant bug report templates to create the issue. Simply copy the content of the appropriate template into a .rb file, make the necessary changes to demonstrate the issue, and paste the content into the issue description:

  • If you would like to contact us directly to report an issue or for general support requests contact our Ready Player Me Support email support@readyplayer.me.

Did you write a patch that fixes a bug?

  • Open a new GitHub pull request with the patch.

  • Ensure the PR description clearly describes the problem and solution. Include the relevant issue number if applicable.

  • Before submitting, please read the Contributing to Ready Player Me Unity SDK guide to know more about our coding conventions and best practices.

Did you fix whitespace, format code, or make a purely cosmetic patch?

Changes that are cosmetic in nature and do not add anything substantial to the stability, functionality, or testability will generally not be accepted.

Do you intend to add a new feature or change an existing one?

  • Suggest your change to the Ready Player Me support email support@readyplayer.me and start writing code.

  • Do not open an issue on GitHub until you have collected positive feedback about the change. GitHub issues are primarily intended for bug reports and fixes.

Do you have questions about the source code?

Issues

Create a new issue

If you spot a problem with the docs, search if an issue already exists. If a related issue doesn't exist, you can open a new issue using a relevant issue form.

Solve an issue

Scan through our existing issues to find one that interests you. You can narrow down the search using labels as filters. See Labels for more information. As a general rule, we don’t assign issues to anyone. If you find an issue to work on, you are welcome to open a PR with a fix.

Make Changes

Make changes locally

  1. Install Git LFS.

  2. Fork the repository.

  1. Create a working branch and start with your changes!

Commit your update

We encourage following the Conventional Commits format when it comes to writing commit messages. Our package repositories come with a .githooks folder that has a commit-msg file that can enforce this. To set this up you just need to configure git's hookspath folder to point there.

You can do this by

  1. Open the terminal
  2. Navigate to the root folder of this repository
  3. Run the following command git config core.hooksPath .githooks

Commit the changes once you are happy with them. Don't forget to self-review to speed up the review process:zap:.

Self review

You should always review your own PR first.

For content changes, make sure that you:

  • Confirm that the changes meet the user experience and goals outlined in the content design plan (if there is one).
  • Compare your pull request's source changes to staging to confirm that the output matches the source and that everything is rendering as expected. This helps spot issues like typos, content that doesn't follow the style guide, or content that isn't rendering due to versioning problems. Remember that lists and tables can be tricky.
  • Review the content for technical accuracy.
  • Review the entire pull request using the translations guide for writers.
  • Copy-edit the changes for grammar, spelling, and adherence to the style guide.
  • Check new or updated Liquid statements to confirm that versioning is correct.
  • If there are any failing checks in your PR, troubleshoot them until they're all passing.

Pull Request

When you're finished with the changes, create a pull request.

  • Fill the "Ready for review" template so that we can review your PR. This template helps reviewers understand your changes as well as the purpose of your pull request.
  • Don't forget to link PR to issue if you are solving one.
  • Enable the checkbox to allow maintainer edits so the branch can be updated for a merge. Once you submit your PR, a team member will review your proposal. We may ask questions or request additional information.
  • We may ask for changes to be made before a PR can be merged, either using suggested changes or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.
  • As you update your PR and apply changes, mark each conversation as resolved.
  • If you run into any merge issues, checkout this git tutorial to help you resolve merge conflicts and other issues.

Your PR is merged!

Congratulations 🎉🎉 The GitHub team thanks you ✨.

Once your PR is merged, your contributions will be publicly visible on the GitHub docs.

Now that you are part of the GitHub docs community, see how else you can contribute to the docs.

Thanks! ❤️ ❤️ ❤️

Ready Player Me Team