Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-docs.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJacques Erasmus <jerasmus@gitlab.com>2019-10-08 13:05:17 +0300
committerJacques Erasmus <jerasmus@gitlab.com>2019-10-08 13:05:17 +0300
commitb09a1258ce2703a70d2d9f19e985b357728d283e (patch)
tree95091d6dfa7bfa22b0a58b8b4bbbd9ee1c6cce65 /CONTRIBUTING.md
parentdbba66d4f90741019f0045535fd1232d309986c6 (diff)
Add frontend code review guidelines
Diffstat (limited to 'CONTRIBUTING.md')
-rw-r--r--CONTRIBUTING.md16
1 files changed, 16 insertions, 0 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 442c2b00..44451259 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -10,3 +10,19 @@ terms.
[DCO + License](https://gitlab.com/gitlab-org/dco/blob/master/README.md)
_This notice should stay as the first item in the CONTRIBUTING.md file._
+
+## Code review guideline
+
+When contributing code to the docs project, you must get your code reviewed before merging the code into master.
+
+The responsibility to find the best solution and implement it lies with the merge request author.
+
+Before assigning a merge request to a maintainer for approval and merge, you should be confident that it actually solves the problem it was meant to solve,
+that it does so in the most appropriate way, that it satisfies all requirements, and that there are no remaining bugs, logical problems, uncovered edge cases,
+or known vulnerabilities. The best way to do this, and to avoid unnecessary back-and-forth with reviewers, is to perform a self-review of your own merge
+request.
+
+### Frontend
+
+1. Once you've verified that your code is in working order, assign the MR to a maintainer (refer to the [team page](https://about.gitlab.com/company/team/) to find a frontend maintainer of the docs project).
+2. The maintainer will review and merge your code.