From e41aee63f5ebc3a698a3f6c8ce2bb01f96846f39 Mon Sep 17 00:00:00 2001 From: Filipa Lacerda Date: Fri, 6 Sep 2019 08:53:12 +0000 Subject: Adds a small checklist reminder about MR Frontend maintainers are a bit overloaded with reviews. In order to speed up the review process we are compiling on the frontend guidelines the list of steps everyone should be following before asking for review --- doc/development/fe_guide/development_process.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/doc/development/fe_guide/development_process.md b/doc/development/fe_guide/development_process.md index ae0e2361840..9224a2548ab 100644 --- a/doc/development/fe_guide/development_process.md +++ b/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 -- cgit v1.2.1