Skip to content

Latest commit

 

History

History
80 lines (48 loc) · 3.85 KB

CONTRIBUTING.md

File metadata and controls

80 lines (48 loc) · 3.85 KB
Raw

Contribution and maintenance

First of all, thank you for considering being a contributor to this repository!

This page includes a set of guidelines for contributors as well as information and instructions about the Live Capture team maintenance process.

Contribution agreement

All Contributions to this repository are subject to the Unity Contribution Agreement (UCA).

By making a pull request, you are confirming agreement to the terms and conditions of the UCA, including that your Contributions are your original creation and that you have complete right and authority to make your Contributions.

How to contribute

Report bugs

The best way to report bugs is to use the Unity reporting tool.

Engage with the community

Use the Unity Forum to ask questions, send feedback and discuss with the community.

Suggest enhancements (via pull requests)

We're not currently accepting feature requests. However, we're open to reviewing incoming pull requests, including those that introduce new features. Your contributions will be appreciated.

Pull request workflow

Create a branch

Branch from main to implement any enhancements or documentation updates, etc.

If you fix a bug, branch off the tagged version with the bug and then make sure to port the fix to main.

Use branch naming prefix (e.g. feature/my-new-feature)

Prefix Meaning
feature A new feature.
ux A UX addition or update.
fix A bug fix.
docs Documentation only changes.
style Formatting, missing semi-colons, white-space, etc.
refactor A code change that neither fixes a bug nor adds a feature.
perf A code change that improves performance.
test Adding missing tests.
chore Maintain. Changes to the build process or auxiliary tools/libraries/documentation.

Note:

  • The main branch is where the development changes for the next release are. This branch is also known as the "integration branch".
  • We also use publish branches for each major and minor (example: live-capture/4.0/release)

Make a pull request

Once you have a change ready, make a pull request in GitHub.

The pull request description should typically include:

  • A summary of the change and its context,
  • A description of the fixed issues, and
  • Any other relevant information that would help the review.

If you're fixing a bug, also include steps to reproduce, environment information, and screenshots/screencasts as relevant.

Manage changelog and versioning

All notable changes in any package or project present in this repository should be documented in a CHANGELOG.md file at the root of each corresponding package or project. If no changelog file exists yet for the package or project you modified, feel free to create one.

Note: The format of changelog files should be based on Keep a Changelog and all packages and projects adhere to Semantic Versioning.

  • Any changes specific to the Live Capture package must be documented in the Live Capture package changelog file, as the content of this file gets published when the package is released.

  • Adding changelog entries about fixes and improvements done in the other packages and projects is not required, but will be appreciated.

Optimize pull request discussions

Discussions on pull requests should be limited to the review of the content (code or documentation) changed via the pull request itself.

Package release and app deployment

Package releases and companion app deployments are done by the Unity Live Capture team.