Embed feedback loop for trainee maintainers in MRs

Why is this change being made?

💡 Provide a detailed answer to the question on why this change is being proposed, in accordance with our value of Transparency.

This MR proposes a small change in the review process for trainee maintainers, in order to improve the feedback loop. Many trainee maintainers have complained the lack of feedback on their reviews. Often when a merge request is sent to the maintainer, the maintaienr reviews the code and provides feedback directly to the author. Unless a critical problem is discovered during the maintainer review, reviewers tend not to be involved.

In a Slack thread (internal link) I've proposed this change in the process where the trainee maintainers explicitly seeks for feedback from the maintainer upon approving the merge request and submitting a summary of their review.

The advantages of this change are:

• The maintainer is now aware that the reviewer is interested in getting feedback. Not all reviewers are interested in the feedback and not all the MRs need it.
• It’s low friction because the maintainer is in the mental context of the review.
• The trainee gets feedback from any maintainer. Everyone can contribute.
• Is actionable, as the maintainer must resolve the thread

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
  • The when to get approval handbook section explains the workflow in more detail
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

---