kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Adds a small checklist reminder about MR

Browse source 
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
This commit is contained in:
Filipa Lacerda 2019-09-06 08:53:12 +00:00 committed by Tim Zallmann
parent 6cdc14be61
commit e41aee63f5
1 changed files with 18 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
doc/development/fe_guide/development_process.md
View file

@ -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