Merge request policy questions

Problem/Motivation

Now that we have merge requests, we have some documentation on the practicalities of how to create and merge them:

Developers: https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa...
Maintainers: https://www.drupal.org/docs/develop/git/git-for-drupal-project-maintaine...
(see also this related issue about a 3rd page that duplicates this content: #3197834: Two pages about merge requests

One thing we are lacking in this documentation is guidance/policies.

Steps to reproduce

Proposed resolution

a. Identify the questions to be answered (see below)

b. The core governance group needs to come up with answers/policies/guidelines for Drupal core. (see below)

c. Document these answers somewhere.

Remaining tasks

All of the above.

Current question/answer list

Questions to be answered and/or policies to establish:

1. When should an issue use a patch and when should it use a merge request?
2. If there is already a merge request on an issue, is it OK for a new developer to commit to it?
3. When should you make a new branch in the issue fork or a new merge request?
   from xjm in Slack:
   The issue summary explodes if there are multiple MRs and there's no way to delete/hide them currently. If that were fixed we could establish a convention around creating a new branch for a rebase, but it doesn't scale to every time something needs to be rerolled. Maybe there could be a maximum of 2 non-hidden MRs?

   from drumm in Slack:
   I do not recommend using multiple merge requests to re-roll. Either git rebase or git merge in upstream, using the same branches.

   from xjm in Slack:
   Rebased branches are easier for reviewers to work with. Merges make the issue history on d.o very confusing and make it harder to identify which commits are actually part of the changeset.

   That said, there is some risk in teaching novice contributors to do that. There is also a UI button for rebasing I believe? I think that "Needs reroll" is something that should cease to be a task (and cease to be credited unless there are merge conflicts that were resolved). We don't want people doing drive-by rebases of branches they've not contributed to otherwise.

   drumm: I’m 70% certain the rebase button doesn’t handle conflict. There is a conflict resolution UI somewhere, I think on merge only.

   xjm: 95% of patch rerolls are rebased locally with no merge conflicts. I think we should add a "Needs merge conflict resolution" tag (or sometihng) that will replace the 5% remaining usecase of "Needs reroll".

   drumm: And there’s no point to rebasing unless there is a merge conflict. If it is just rebasing for the sake of rebasing, that’s just extra noise.

4. Is it OK to force push if you are rebasing?
   From xjm in Slack:
   rebase-force-push is the cleanest way to update an MR branch so long as the contributor is aware it's destructive and dangerous if used incorrectly

   From drumm in Slack:
   On force push, backup tags are made of the previous work, like https://git.drupalcode.org/issue/drupalorg-3192158/-/tags

5. Something about the "suggestion feature" ??? [mentioned by xjm in Slack]
6. Continue to heavily encourage making a comment before we work on an existing merge request / issue fork branch.
   From drumm in Slack: Yes. Always be communicating. Especially commenting to sum up once a round of work is done.