Merge branch 'master' into 30286-vue-loadin-icon30286-vue-loadin-icon

* master: (62 commits)
  Fix broken test - load correct data
  Remove redirect for old issue url containing id instead of iid
  Use vue file for table pagination component
  stub error handlers where uncaught Promise rejections currently exist
  Revert "Fix OpenID spec failure that assumed current_sign_in_at would be set"
  Add :redis keyword to some specs clear state of trackable attributes
  Fix OpenID spec failure that assumed current_sign_in_at would be set
  Kubernetes Helm Chart Install docs
  Add Repository subnav to 'Find files'
  Make tree, blob and blame pages more consistent
  Add screenshots to Triggered Build docs
  Add Prometheus memory sparkline to MR widget
  Fix test failure in job vue componenFix test failure in job vue componentt
  Remove unnecessary if check
  Fix links in code review docs
  Improve readability of code
  Remove some unused Gitlab::Git code
  Use Rails 'delegate'
  Remove CI/CD models directory from `eager_load_paths`
  Don't make Commit#raw_deltas private
  ...

1 files changed, 10 insertions, 5 deletions

diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index be3dd1e2cc6..4ed89146072 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -6,18 +6,20 @@ There are a few rules to get your merge request accepted:
 
 1. Your merge request should only be **merged by a [maintainer][team]**.
   1. If your merge request includes only backend changes [^1], it must be
-    **approved by a [backend maintainer][team]**.
+    **approved by a [backend maintainer][projects]**.
   1. If your merge request includes only frontend changes [^1], it must be
-    **approved by a [frontend maintainer][team]**.
+    **approved by a [frontend maintainer][projects]**.
   1. If your merge request includes frontend and backend changes [^1], it must
-    be **approved by a [frontend and a backend maintainer][team]**.
+    be **approved by a [frontend and a backend maintainer][projects]**.
 1. To lower the amount of merge requests maintainers need to review, you can
-  ask or assign any [reviewers][team] for a first review.
+  ask or assign any [reviewers][projects] for a first review.
   1. If you need some guidance (e.g. it's your first merge request), feel free
     to ask one of the [Merge request coaches][team].
   1. The reviewer will assign the merge request to a maintainer once the
     reviewer is satisfied with the state of the merge request.
 
+For more guidance, see [CONTRIBUTING.md](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md).
+
 ## Best practices
 
 This guide contains advice and best practices for performing code review, and
@@ -30,7 +32,7 @@ code is effective, understandable, and maintainable.
 Any developer can, and is encouraged to, perform code review on merge requests
 of colleagues and contributors. However, the final decision to accept a merge
 request is up to one the project's maintainers, denoted on the
-[team page](https://about.gitlab.com/team).
+[engineering projects][projects].
 
 ### Everyone
 
@@ -140,3 +142,6 @@ Largely based on the [thoughtbot code review guide].
 ---
 
 [Return to Development documentation](README.md)
+
+[projects]: https://about.gitlab.com/handbook/engineering/projects/
+[team]: https://about.gitlab.com/team/