We use labels in our Pull Requests to be able to categorize and prioritize our work. Some are also used to trigger our CI jobs.
At the moment our labels can be separated into the following groups:
A project horizontal corresponds to an area of the project that has an horizontal impact, meaning it has impact in most or all the verticals in the project.
- introduction of automation tests
- updating localizable strings or working in the localization system of the project
- work in the iOS Platform, e.g. architecture, infrastructure, tooling, ...
We have several projects which contain a subset of functionalities from the main babylon app. These apps also have different flavours in terms of UI.
The labels to define work that is done in each different project are:
🇨🇦 - work in the Telus app
🇺🇸 - work in the US app
Informs in which stage of development the PR is. These labels are used to know which PRs can be reviewed. They are also used to trigger our CI jobs.
- The PR is ready to be merged. Our bot picks up when this label is added. It will then automatically add the PR in the queue to merge the PRs in order. Once dequeued, it will first merge back develop into the PR, then wait for our CI system to run all the tests. Only if every test has passed the bot will finally merge the PR.
- The PR has one approval and is waiting for one more review.
Flags if there is something preventing the PR from being merged that is unrelated with review requests or failing builds.
- the PR is waiting for another task to be complete - this task can be a backend task, a product decision or another PR.
- the PR is blocking other PRs from resuming their work or from being merged. The PR with this label should have priority over the PRs that are being blocked by this one.
Alerts when a PR is required to be merged. This is used in emergency situations like a hot fix or a piece of work that is mandatory to go in the release that is about to ship.
- The PR has priority to be reviewed because it has an urgent change for the current or next release.
These tags are used to give extra context to the PR.
- The PR fixes a bug.
- The PR includes some work that won't change any functionality - it just removes clutter from the project.
- The PR has refactoring work. Refactoring work is usually work that involves rewritting a part of the project that had technical debt. This work usually doesn't have any visual changes (UI/UX changes).
- The PR takes 1-2 minutes to review (an example can be a PR that only involves updading localizable strings).
A PR should always have at least one label, representing the review status of the PR. If applicable, other labels can be added to represent what area does the PR touch.
As such, there are a few rules we should consider when applying labels to a PR.
Multiple labels from these groups can be added to a PR because a piece of work can have impact in more than one area.
In this group a mixed of rules are applied. A PR can:
- be either ready for review or still in progress. These are mutually exclusive. It means the labels representing both these stages can't be present in the same instant.
- have one reviewer label only if it is ready for review.
- have merge label only if it is ready for review, has two approvals and no changes requested.
A PR can have one or both of these labels dependending on the blocking chain. However, it is very unusual and not ideal that a PR is in a situation where it needs both labels at the same time.
There is some specific information that is mandatory to be present in the PR description when using:
- Blocked - Describe the reason why it is blocked. If it is being blocked by another PR or JIRA Ticket, these should be mentioned.
- Blocking other PRs - Describe the reason why it is blocking other PRs. It should mentioned which PRs are being blocked by it.
A PR can only have one emergency label.
A PR can have one or more extra labels at the same time.