1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
|
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
---
# Development processes
Consult these topics for information on development processes for contributing to GitLab.
## Processes
Must-reads:
- [Guide on adapting existing and introducing new components](architecture.md#adapting-existing-and-introducing-new-components)
- [Code review guidelines](code_review.md) for reviewing code and having code
reviewed
- [Database review guidelines](database_review.md) for reviewing
database-related changes and complex SQL queries, and having them reviewed
- [Secure coding guidelines](secure_coding_guidelines.md)
- [Pipelines for the GitLab project](pipelines/index.md)
Complementary reads:
- [Avoiding required stops](avoiding_required_stops.md)
- [Contribute to GitLab](contributing/index.md)
- [Security process for developers](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#security-releases-critical-non-critical-as-a-developer)
- [Patch release process for developers](https://gitlab.com/gitlab-org/release/docs/blob/master/general/patch/process.md#process-for-developers)
- [Guidelines for implementing Enterprise Edition features](ee_features.md)
- [Adding a new service component to GitLab](adding_service_component.md)
- [Guidelines for changelogs](changelog.md)
- [Dependencies](dependencies.md)
- [Danger bot](dangerbot.md)
- [Requesting access to ChatOps on GitLab.com](chatops_on_gitlabcom.md#requesting-access) (for GitLab team members)
### Development guidelines review
For changes to development guidelines, request review and approval from an experienced GitLab Team Member.
For example, if you're documenting a new internal API used exclusively by
a given group, request an engineering review from one of the group's members.
Small fixes, like typos, can be merged by any user with at least the Maintainer role.
#### Broader changes
Some changes affect more than one group. For example:
- Changes to [code review guidelines](code_review.md).
- Changes to [commit message guidelines](contributing/merge_request_workflow.md#commit-messages-guidelines).
- Changes to guidelines in [feature flags in development of GitLab](feature_flags/index.md).
- Changes to [feature flags documentation guidelines](documentation/feature_flags.md).
In these cases, use the following workflow:
1. Request a peer review from a member of your team.
1. Request a review and approval of an Engineering Manager (EM)
or Staff Engineer who's responsible for the area in question:
- [Frontend](https://about.gitlab.com/handbook/engineering/frontend/)
- [Backend](https://about.gitlab.com/handbook/engineering/)
- [Database](https://about.gitlab.com/handbook/engineering/development/database/)
- [User Experience (UX)](https://about.gitlab.com/handbook/product/ux/)
- [Security](https://about.gitlab.com/handbook/security/)
- [Quality](https://about.gitlab.com/handbook/engineering/quality/)
- [Engineering Productivity](https://about.gitlab.com/handbook/engineering/quality/engineering-productivity/)
- [Infrastructure](https://about.gitlab.com/handbook/engineering/infrastructure/)
You can skip this step for MRs authored by EMs or Staff Engineers responsible
for their area.
If there are several affected groups, you may need approvals at the
EM/Staff Engineer level from each affected area.
1. After completing the reviews, consult with the EM/Staff Engineer
author / approver of the MR.
If this is a significant change across multiple areas, request final review
and approval from the VP of Development, who is the DRI for development guidelines.
Any Maintainer can merge the MR.
#### Technical writing reviews
If you would like a review by a technical writer, post a message in the `#docs` Slack channel.
Technical writers do not need to review the content, however, and any Maintainer
other than the MR author can merge.
### Reviewer values
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/57293) in GitLab 14.1.
As a reviewer or as a reviewee, make sure to familiarize yourself with
the [reviewer values](https://about.gitlab.com/handbook/engineering/workflow/reviewer-values/) we strive for at GitLab.
Also, any doc content should follow the [Documentation Style Guide](documentation/index.md).
## Language-specific guides
### Go guides
- [Go Guidelines](go_guide/index.md)
### Shell Scripting guides
- [Shell scripting standards and style guidelines](shell_scripting_guide/index.md)
## Clear written communication
While writing any comment in an issue or merge request or any other mode of communication,
follow [IETF standard](https://www.ietf.org/rfc/rfc2119.txt) while using terms like
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY",
and "OPTIONAL".
This ensures that different team members from different cultures have a clear understanding of
the terms being used.
|
