1. Review the merge request. If you see anything questionable, kick it back to "needs review" or "needs work", unassign it from yourself, and leave a comment. If the patch introduces changes that need manual updating from site admins, be sure that the issue summary has a release note.
2. If it looks good, go through the issue and assign credit as you see fit.
3. Adjust the issue title as desired for maximum clarity, since it will be the commit message.
4. Scroll to the bottom of the page and merge it.
5. If you're going to backport the issue to the current release branch, read on; otherwise, leave a nice comment and mark the issue fixed -- you're all set.
### How to backport
1. Pull the latest changes from the development branch (e.g., `git checkout 1.x && git pull`)
2. Check out the release branch (e.g., `git checkout 1.0.x`).
3. Cherry-pick the latest commit from the release branch (e.g. `git cherry-pick 1.x`). If there are merge conflicts, fix them if they're straightforward, and continue the cherry-pick (`git add . && git cherry-pick --continue`). If they're _not_ straightforward, abort the cherry-pick (`git cherry-pick --abort`) and kick the issue to "Patch (to be ported)", and ask for a new MR targeting the release branch.
4. Adjust `project_template/composer.json`, and the various `composer.json` files in the component recipes, to account for the changes being made to the component(s) by the current patch. For example, if the patch is fixing a bug (or bumping a dependency) in `drupal_cms_ai`, and the _next_ version of Drupal CMS will be 1.0.3, then you'll want to change `project_template/composer.json`, which depends on `drupal_cms_ai`, so that its requirement is `"drupal/drupal_cms_ai": "~1.0.3"`. You'll need to do this for everything that depends on the component(s) being changed. This is tedious, but necessary.
5. Add those changes to the most recent commit: `git add . && git commit --amend`. Push the branch (`git push`).
