Document "How to get your MR reviewed, approved, and merged"

This documents how to get your merge request reviewed, approved, and merged.

I've also added a link to it from the Engineering workflow handbook document: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/5263

/cc @dzaporozhets @DouweM @smcgivern @jschatz1 @ayufan @stanhu

mentioned in issue #24865 (closed)

Approved this merge request

Thanks @rymai, LGTM! Just a couple of typos.

assigned to @rymai

Looks good to me. Thanks!

resolved all discussions

added 1 commit

• c444f258 - Document "How to get your MR reviewed, approved, and merged"

Compare with previous version

added 1 commit

• 1d78e4ed - 1 commit from branch master

Compare with previous version

@smcgivern @stanhu Thanks, fixed!

assigned to @smcgivern

Approved this merge request

merged

Why specs? You mean code? You wrote that here: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9839/diffs#3f454a98e586d1aa0d322e19afd5e67e08f2d3c8_355_367 regarding

If your merge request includes frontend and backend changes

Changes can be stuff other than specs right? Also FE should review HTML too. 😄 For semanticism.

Why specs? You mean code?

@jschatz1 I don't think I have to define what's backend code, but I wanted to emphasize that specs need to be reviewed by a backend person too!

Maybe I should start the sentence with "Note that specs other...", would it be clearer?

Also FE should review HTML too.

Ok, my sentence is definitely not clear enough then! :) What I meant is that as soon as there is Ruby code in a view, e.g.:

%ul
  - records.sort_by(&:name).each do |record|
    %li= record.name

this should be reviewed by a backend person, but I guess this is a bit silly because almost all view changes include Ruby code...

Sounds good to me.

mentioned in commit af9cb102

mentioned in merge request !9967 (merged)