Skip to content

Latest commit

 

History

History
43 lines (31 loc) · 4.67 KB

LABELING_GUIDELINES.md

File metadata and controls

43 lines (31 loc) · 4.67 KB
Raw

PR Labeling Guidelines

To maintain a consistent and efficient development workflow, we have set specific label guidelines for all pull requests (PRs). Please ensure you adhere to the following instructions:

Mandatory team labels:

  • Internal Developers: Every PR raised by an internal developer must include a label prefixed with team- (e.g., team-mobile-ux, team-mobile-platform, etc.). This indicates the respective internal team responsible for the PR.

  • External Contributors: PRs submitted by contributors who are not part of the organization will be automatically labeled with external-contributor.

It's essential to ensure that PRs have the appropriate labels before they are considered for merging.

Mandatory release version labels:

  • release-x.y.z: This label is automatically added to a PR and its linked issues upon the PR's merge. The x.y.z in the label represents the version in which the changes from the PR will be included. This label is auto-generated by a GitHub action, which determines the version by incrementing the minor version number from the most recent release. Manual intervention is only required in specific cases. For instance, if a merged PR is cherry-picked into a release branch, typically done to address Release Candidate (RC) bugs, the label would need to be manually updated to reflect the correct version.
  • regression-prod-x.y.z: This label is automatically added to a bug report issue at the time of its creation. The x.y.z in the label represents the version in which the bug first appeared. This label is auto-generated by a GitHub action, which determines the x.y.z value based on the version information provided in the bug report issue form. Manual intervention is only necessary under certain circumstances. For example, if a user submits a bug report and specifies the version they are currently using, but the bug was actually introduced in a prior version, the label would need to be manually updated to accurately reflect the version where the bug originated.
  • regression-RC-x.y.z: This label is manually added to a bug report issue by release engineers when a bug is found during release regerssion testing phase. The x.y.z in the label represents the release candidate (RC) version in which the bug's been discovered.

Mandatory QA labels:

Every PR shall include one the QA labels below:

  • needs-qa: If the PR includes a new features, complex testing steps, or large refactors, this label must be added to indicated PR requires a full manual QA prior being merged and added to a release.

  • Spot check on release build: If PR does not require feature QA but needs non-automated verification, this label must be added. Furthermore, when that label is added, you must provide test scenarios in the description section, as well as add screenshots, and or recordings of what was tested.

To merge your PR one of the following QA labels are required:

  • QA Passed: If the PR was labeled with needs-qa, this label must be added once QA has signed off
  • No QA Needed: If the PR does not require any QA effort. This label should only be used in case you are updating a README or other files that does not impact the building or runtime of the application.
  • Run E2E Smoke: This label will kick-off E2E testing and trigger a check to make sure the E2E tests pass.

Optional labels:

  • regression-develop: This label can manually be added to a bug report issue at the time of its creation if the bug is present on the development branch, i.e., main, but is not yet released in production.

Labels prohibited when PR needs to be merged:

Any PR that includes one of the following labels can not be merged:

  • needs-qa: The PR requires a full manual QA prior to being merged and added to a release.
  • QA'd but questions: The PR has been checked by QA, but there are pending questions or clarifications needed on minor issues that were found.
  • issues-found: The PR has been checked by QA or other reviewers, and appeared to include issues that need to be addressed.
  • need-ux-ds-review: The PR requires a review from the User Experience or Design System teams.
  • blocked: There are unresolved dependencies or other issues blocking the progress of this PR.
  • stale: The PR has not had recent activity in the last 90 days. It will be closed in 7 days.
  • DO-NOT-MERGE: The PR should not be merged under any circumstances.

To maintain code quality and project integrity, it's crucial to respect these label guidelines. Please ensure you review and update labels appropriately throughout the PR lifecycle.

Thank you for your cooperation!