Merge branch 'docs-fe-mr-review-docs' into 'master'

Adds a small checklist reminder about MR

See merge request gitlab-org/gitlab-ce!32528

doc/development/fe_guide/development_process.md

@@ -58,6 +58,24 @@ Please use your best judgement when to use it and please contribute new points t
 - [ ] Follow up on issues that came out of the review. Create issues for discovered edge cases that should be covered in future iterations.
 ```
+### Merge Request Review
+
+With the purpose of being [respectful of others' time](https://about.gitlab.com/handbook/values/#be-respectful-of-others-time) please follow these guidelines when asking for a review:
+
+- Make sure your Merge Request:
+  - milestone is set
+  - at least the labels suggested by danger-bot are set
+  - has a clear description
+  - includes before/after screenshots if there is a UI change
+  - pipeline is green
+  - includes tests
+  - includes a changelog entry (when necessary)
+- Before assigning to a maintainer, assign to a reviewer.
+- If you assigned a merge request, or pinged someone directly, keep in mind that we work in different timezones and asynchronously, so be patient. Unless the merge request is urgent (like fixing a broken master), please don't DM or reassign the merge request before waiting for a 24-hour window.
+- If you have a question regarding your merge request/issue, make it on the merge request/issue. When we DM each other, we no longer have a SSOT and [no one else is able to contribute](https://about.gitlab.com/handbook/values/#public-by-default).
+- When you have a big WIP merge request with many changes, you're adivsed to get the review started before adding/removing significant code. Make sure it is assigned well before the release cut-off, as the reviewer(s)/maintainer(s) would always prioritize reviewing finished MRs before WIP ones.
+- Make sure to remove the WIP title before the last round of review.
+
 ### Share your work early
 1. Before writing code, ensure your vision of the architecture is aligned with