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
|
---
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.
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.
|
