Allow merge request author to change target branch
Release notes
By allowing a Merge Request author to change the target branch of the MR, we can:
- Empower MR authors to keep up with the release cycle of software they are contributing to, as legacy/stable/future development branches change
- Empower MR authors to fix an MR accidentally opened against the wrong target
- Save project maintainers time fixing incorrectly targeted MRs
- Keeps the MRs on a project clean by preventing having multiple duplicate MRs against different target branches.
Problem to solve
When working on larger projects which maintain multiple development branches (Current-stable, Legacy-stable, Next-minor, Next-major) a merge request may be opened against a branch, but then needed to be re-targeted to a new branch as releases cycle.
An example of this:
-
A developer working on Drupal is writing a new feature request, and opens a merge request against Drupal 9.4.x, the next upcoming minor release
-
The project maintainers are unable to review and prioritize merging that request before 9.4.0 releases
-
The merge request needs to be retargetted to 9.5.x, but only the maintainers have the power to do this
-
If the original author was empowered to do this, they could proactively take care of any newly introduced merge conflicts/rebasing,etc so its ready when a maintainer has time
-
This is also simply useful when a Merge Request author simply accidentally selects the wrong target branch.
Proposal
- Simply grant the MR author permission to change the target branch of their MR. They set the target when creating it, so they don't gain any access that they wouldn't already have by simply creating a new MR.
- Perhaps make this ability a configurable setting on a project or group basis.
Intended users
Feature Usage Metrics
Analytics could determine how often an MR author makes a target branch change. Analytics could also determine how much less often a project maintainer must make a target branch change.