Submitting PRs

Approvals

1. PR needs at least two approvals
2. Approvals & changes can come from anyone
3. Unity Contributors can send PRs from forks
4. Unity Committers can merge approved PRs into any branch besides stage or main
5. Release Manager can merge approved PRs into stage and main
6. We recommend the following title format for PR: MWPW-xxxx - Summarize changes in 50 characters or less
7. Please ensure all PRs have clear descriptions of the changes being committed

Labels

When opening a PR, ensure it has the appropriate labels.

• Add a product label: acrobat, photoshop, express, platform, etc.
• Add the label bug fix if PR includes bug fixes
• Add the label ready for stage when a PR is ready to be merged to stage

PR Review and Testing Guidelines

Depending on if commits can be verified on a feature branch or can only be directly tested on stage, please follow the appropriate process.

Feature branch verification

1. Assign the PR to QE and add the needs-verification label

No issues on feature branch

2. QE verifies the changes, removes the needs-verification label, and then adds verified label
3. QE / developer adds the ready for stage label on the PR
4. Release Manager merges PR to stage branch if there are 2 approvals

Issues found on feature branch

2. QE adds a comment in the PR / JIRA ticket and developer updates PR with fixes
3. QE verifies the changes, removes the needs-verification label, and then adds verified label
4. QE / developer adds the ready for stage label on the PR
5. Release Manager merges PR to stage branch if there are 2 approvals

Stage branch verification

1. Developer adds verify on stage and ready for stage labels and assigns PR to QE
2. Release Manager merges PR if there are 2 approvals

No issues on stage

3. QE updates merged PR to add verified label and a comment to confirm

Issues found on stage

3. QE adds the needs-rework label and a comment about the issue in the associated JIRA ticket
4. Developer creates a new PR and adds the labels: bug fix, verify on stage, and ready for stage
5. Developer updates description of new PR to reference the old PR to maintain traceability
6. Release Manager merges PR if there are 2 approvals and repeats the process again

Releases

PR titles should be written as following: [Release] Stage to Main

In cases where we cannot merge stage changes directly into main branch:

1. Revert any commits that will not be added into the release batch
2. Create a PR from stage to main
3. Ask QE to add verified label to the release PR
4. Release Manager merges release PR to main when there are at least 2 approvals
5. For each reverted commit, re-create PRs to stage and Release Manager merges when there are sufficient approvals