[Meta] Pull requests should be merged when they are approved

[peternied]

Description

In GitHub when a pull request has been reviewed and approved the contributor knows it is accepted when the change has been merged. It looks like there is a practice in this repro to mark pull requests with a label 6 - Done bug waiting to merge, this is confusing. If the change is approved, then it should be merged to prevent surprise merge conflicts to the contributor that authored the change.

Here is a timeline for an outstanding pull request:

• Oct 2nd '23 submitted
• Nov 20 '23 approved
• Nov 24 '23 unapproved
• Dec 1st '23 reapproved
• Jan 30 '24 unmerged - date of this issues creation

Because of the timescales involved is hard for a contributor to know when they are 'done' contributing.

Proposal

When a pull request is created they point to main by default; on inspection of new pull requests a maintainer determines if it should be released immediately or if not, switches the base to point to the appropriate target release branch. As soon as the pull request is approved, it is merged into the feature branch, in this case maybe 2.12 is a good name for it.

When 2.12 is released, a maintainer would make a new pull request from the 2.12 branch onto main to pull in all of those features that target the new release. This becomes the single release deployment and lets the contributors know that the maintainers of this repo will handle the deployment of the documentation changes.

[peternied]

I couldn't find an architecture doc for this repo so its possible my suggestion doesn't align with how things are constructed. If someone could provide me with documentation, I'll be happy to revisit my recommendation to make sure its compatibly with how this project operates.

[Naarcha-AWS]

@peternied: When a PR is related to a new version for an unreleased distribution of OpenSearch, in this case, OpenSearch 2.12, we wait to merge the PRs until closer to release. Not only does this ensure that we aren't needing to backport already merged PRs to the new version, but it also helps the writers with tracking what pieces are done for the release and which are still in-progress.

[hdhalter]

This is a great suggestion, @peternied. We will look into what it would take to set this up in the repo.

[bbarani]

I like this idea. We can enable auto-merge once all required reviews and status checks have passed. This will work only when all status checks are green though. Also, the PR should use the right set of labels.

[hdhalter]

We'd have to think more about auto-merge. Our current process allows for one sign-off by a maintainer technically, but our real process is tech review --> doc review --> editorial review. The editorial review is skipped if there are no wording changes. So, once the PR passes tech (by a developer) and doc review (by a maintainer), the maintainer has the responsibility of deciding whether it should go to editorial or merge. So, we'd need a checkbox that opts out of the editorial review or, if it requires editorial, requires a sign-off by the editor.

[Naarcha-AWS]

I could see the benefit of auto-merge for backport PRs in-particular. However, when merging to main I could see auto-merge causing issues. It frequent that, as part of the writing process, that a draft will go through several more iterations even after we've reached "Green" and "Approved" states in GitHub, for example, a release feature PR going through several technical changes before publication.

One idea @hdhalter proposed recently was cutting the branch for the future release sooner and merging release PRs into that branch. This however, would require us to update our backend pipelines.