[policy, no patch] Merge request policy questions

I am trying to figure out what still needs to be done here. We've been using GitLab for a while now and some established practices has emerged and there is more documentation as well. Using GitLab to Contribute to Drupal → .

This is a summary of the items in the issue summary.

1. When should an issue use a patch and when should it use a merge request?

No documentation that I could find.

2. If there is already a merge request on an issue, is it OK for a new developer to commit to it?

Yes. Documented at https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-drupal/introduction#s-introduction-to-issue-forks-and-merge-requests → <

3. When should you make a new branch in the issue fork or a new merge request?

No documentation that I could find

4. Is it OK to force push if you are rebasing?

Documented process at Rebase a merge request → .

5. Something about the "suggestion feature" ??? [mentioned by xjm in Slack]

No documentation that I could find.

6. Continue to heavily encourage making a comment before we work on an existing merge request / issue fork branch.

The contributor tasks for patches and merge requests includes a step for adding the comment before working.
Related documentation regarding credit at How is credit granted for Drupal core issues →

So this is what is fixed and what needs work.
1 - This seems to be at the preference of the contributor and therefor I don't think this needs to be documented. However, an MR and the suggestion feature make working on coding standards issues easier. But that can be done in a specific how to wiki page for coding standards.
2 - Fixed
3 - What I see is that new MRs are created when needed to change the branch or by people seeking credit for clicking a button. The latter has been addressed in the crediting documentation. As for the former, I am not sure documentation is needed.
4 - Fixed
5 - The suggestion feature is in use and is just part of GitLab. I don't see why this need specific documentation.
6 - Fixed?

I am not finding a need to add documentation, which is surprising. Is documentation needed for 1, 3, 5 or 6?

Setting to NR to get other opinions.

Is there documentation needed?

I asked in #needs-review-queue-initiative about this issue. FeyP responded about 1, 2 and 5.

For 1) I have taken the suggestion and added documentation that simply states the contributor decides to use a patch or merge workflow. The docs are Patch or merge request → and linked to it at Creating merge requests → .

For 2) FeyP prefers a single MR per issue. I think this is implied in the existing documentation, "One or more contributors commits/pushes changes to the fork." so no change for this one.

For 5) FeyP thinks that the intention was to document that the suggestion feature should be used instead of just commenting. So I have added that to the Reviewing a merge request → .

That leaves 3) and 6).

3) For this, there has been a learning phase and people engaged in credit farming. Ignoring those, people make a new branch or MR as needed. One frequent reason is to move to a more recent branch. I am not sure what to document here nor is there a suggestion in this issue. Also things may change with 🌱 [Policy] Branch Naming: Use an 11.x branch for HEAD, then use 'main' when d.o can support it Fixed .

6) adding comments is something that is encouraged all the time. I see it in comments, wiki pages, slack etc. I do think that is part of our practice and that no further documentation is needed.

Therefor I am going to close this as fixed. It was worthwhile to endure that these points are covered.

If you disagree, or I have missed something, re-open the issue and add a comment. ping me in Slack as well.

Cheers

Automatically closed - issue fixed for 2 weeks with no activity.