Skip to content

Submitting PRs

Blaine Gunn edited this page Nov 15, 2023 · 19 revisions

Approvals

  1. Every PR needs at least two approvals.
  2. Approvals & changes can come from anyone. Milo Admins are responsible for the binding approvals.
  3. Milo Contributors can send PRs from forks.
  4. Milo Committers can merge approved PRs into any branch besides stage or main.
  5. Milo Admins can merge approved PRs into stage and main.

Ready to review

Ensure to read on how to get your PR into a reviewable state and that all the PR checks are green before you assign any reviewers.

Audits

A PR must pass all audits run by Github. If an audit does not pass, an admin is required to merge.

  • For Lighthouse, we generally expect 98 or above.
  • For code coverage, we generally expect 98% or above.
  • For Adobe CLA, you must be a part of the adobecom org.

There are exceptions to every audit depending on the context of the fix or feature.

Commit Template

Place this in your home folder.

.gitcommittemplate

MWPW-xxxx - Summarize changes in 50 characters or less

* Add your
* Specific
* Features or fixes

Resolves: [MWPW-NUMBER](MWPW-URL)

**Test URLs:**
- Before: https://stage--milo--adobecom.hlx.page/?martech=off
- After: https://<branch>--milo--adobecom.hlx.page/?martech=off

1x JIRA | 1x Commit | 1x PR

We encourage you to have one commit per PR. By doing so, your PR will be pre-populated with relevant information. This is not required. If you wish to follow this process, it may require squashing commits before you PR. Please see below for our recommended way of squashing commits. Reach out to the team if you have more questions.

Pull Request Title

We recommend the following title format:

MWPW-xxxx - Summarize changes in 50 characters or less

This ensures glanceable information for the reviewers and will help get a PR approved faster.

Squashing commits

We believe every commit that lands into Milo main should have meaning. We do not expect this for work in progress commits. This is why we recommend squashing your commits to

Drafts PRs

No new draft PR should be opened to keep the PR count down. If you would like a review of draft code please reach out on milo-community discussion forum with a link to your branch. Another way to tackle "draft" PRs is to send us a diff. For example: https://github.com/adobecom/milo/compare/main...review-schema

Getting attention to your PR

Opening a PR will automatically request the code owners for a review. Usually open PRs are actively being looked at by the community. If your PR is urgent such as a critical production bug or your PR does not have any kind of response for over 48 hours, you can reach out to #milo-dev (or #milo-community for access to that channel) on slack.