Add merge request reviewer label to me, Douwe and Robert

\cc @rspeicher @DouweM

@dzaporozhets Is this clear enough? I've reviewed MR's, so I would be a MR reviewer too... but of course not for anything other than the website. Perhaps it is helpful to clarify by writing something like:
"Reviews merge requests for GitLab CE / EE"?

\cc @sytses

I thought this was something that all developers were expected to do/be available for?

Title changed from Add merge request reviewer label to me, Douwe and Rober to Add merge request reviewer label to me, Douwe and Robert

@dzaporozhets Good points from Ernst and Robert. We have people on the core team that can also merge simple stuff. 'Complex merge endboss'?

@ernstvn @rspeicher you are right. Every developer can review and merge code. I want to specify who:

• will review merge request from new developers during their first month
• will review and merge something complex, big or controversial

@sytses so you kinda right. Its more like 'Complex merge endboss' 😃 Should I update merge request with such title?

"Complex merges master" sounds better to me :-)
Plus we should then add a note to onboarding / handbook that new developers should initially assign their MR's to these merge masters, of course cc-ing others that are relevant.

@ernstvn master has three other meanings, one in git, one in gitlab and a non PC one http://www.nytimes.com/2015/12/03/us/harvard-to-discontinue-use-of-house-master-title.html?_r=0

I prefer endboss, we should link it to http://www.urbandictionary.com/define.php?term=endboss&defid=5331178

@sytses That is hilarious, thanks for the links.

I don't think we need a fancy term for this. I'm fine with leaving it off the team page and just adding a note in the developer onboarding about who to reach out to for reviews.

@rspeicher I suspect that developers on the core team and in the wider community don't read our onboarding handbook, while they too can propose complex merge requests. Assuming that there is a greater probability that the team page is visited, it makes sense to put it there.

Community members can't assign the MRs though. I think we rely on core team/other developers to ping people to review, and they are likely to be familiar with our handbook.

Ah, good to know. Thanks @rspeicher . In that case I am fine with your suggestion; let's see what Sytse and Dmitriy think.

I propose that stuff like this goes into the team page, not the handbook. The handbook is for procedures. The team page for individual roles. It is convenient to look at the people in the company and what they do.

mentioned in merge request !1245 (merged)

Since I got no comments further comments I made a new proposal. https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/1245 I hope you don't mind @rspeicher

Status changed to closed

mentioned in commit 76f1b90f