Skip to content

G
gitlab-ce
Commit 50f8ead5 authored by Evan Read's avatar Evan Read
Browse files
Options

Remove DocToc frontmatter from published pages 

- Also fix some markdown syntax.
parent 45a5a371
Hide whitespace changes
Inline Side-by-side
Showing with 41 additions and 122 deletions
doc/development/contributing/design.md
View file @ 50f8ead5
<!-- START doctoc generated TOC please keep comment here to allow auto update --> # Implement design & UI elements
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
**Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)*
- [Implement design & UI elements](#implement-design--ui-elements)
- [Style guides](#style-guides)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
## Implement design & UI elements
For guidance on UX implementation at GitLab, please refer to our [Design System](https://design.gitlab.com/). For guidance on UX implementation at GitLab, please refer to our [Design System](https://design.gitlab.com/).
...@@ -34,27 +25,27 @@ In order to complete a product discovery issue in a release, you must complete t ...@@ -34,27 +25,27 @@ In order to complete a product discovery issue in a release, you must complete t
## Style guides ## Style guides
1. [Ruby](https://github.com/bbatsov/ruby-style-guide). 1. [Ruby](https://github.com/bbatsov/ruby-style-guide).
Important sections include [Source Code Layout][rss-source] and Important sections include [Source Code Layout][rss-source] and
[Naming][rss-naming]. Use: [Naming][rss-naming]. Use:
- multi-line method chaining style **Option A**: dot `.` on the second line - multi-line method chaining style **Option A**: dot `.` on the second line
- string literal quoting style **Option A**: single quoted by default - string literal quoting style **Option A**: single quoted by default
1. [Rails](https://github.com/bbatsov/rails-style-guide) 1. [Rails](https://github.com/bbatsov/rails-style-guide)
1. [Newlines styleguide][newlines-styleguide] 1. [Newlines styleguide][newlines-styleguide]
1. [Testing][testing] 1. [Testing][testing]
1. [JavaScript styleguide][js-styleguide] 1. [JavaScript styleguide][js-styleguide]
1. [SCSS styleguide][scss-styleguide] 1. [SCSS styleguide][scss-styleguide]
1. [Shell commands](../shell_commands.md) created by GitLab 1. [Shell commands](../shell_commands.md) created by GitLab
contributors to enhance security contributors to enhance security
1. [Database Migrations](../migration_style_guide.md) 1. [Database Migrations](../migration_style_guide.md)
1. [Markdown](http://www.cirosantilli.com/markdown-styleguide) 1. [Markdown](http://www.cirosantilli.com/markdown-styleguide)
1. [Documentation styleguide](https://docs.gitlab.com/ee/development/documentation/styleguide.html) 1. [Documentation styleguide](https://docs.gitlab.com/ee/development/documentation/styleguide.html)
1. Interface text should be written subjectively instead of objectively. It 1. Interface text should be written subjectively instead of objectively. It
should be the GitLab core team addressing a person. It should be written in should be the GitLab core team addressing a person. It should be written in
present time and never use past tense (has been/was). For example instead present time and never use past tense (has been/was). For example instead
of _prohibited this user from being saved due to the following errors:_ the of _prohibited this user from being saved due to the following errors:_ the
text should be _sorry, we could not create your account because:_ text should be _sorry, we could not create your account because:_
1. Code should be written in [US English][us-english] 1. Code should be written in [US English][us-english]
This is also the style used by linting tools such as This is also the style used by linting tools such as
[RuboCop](https://github.com/bbatsov/rubocop), [RuboCop](https://github.com/bbatsov/rubocop),
......
doc/development/contributing/index.md
View file @ 50f8ead5
<!-- START doctoc generated TOC please keep comment here to allow auto update --> # Contribute to GitLab
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
**Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)*
- [Contribute to GitLab](#contribute-to-gitlab)
- [Security vulnerability disclosure](#security-vulnerability-disclosure)
- [Code of conduct](#code-of-conduct)
- [Closing policy for issues and merge requests](#closing-policy-for-issues-and-merge-requests)
- [Helping others](#helping-others)
- [I want to contribute!](#i-want-to-contribute)
- [Contribution Flow](#contribution-flow)
- [Workflow labels](#workflow-labels)
- [Type labels](#type-labels)
- [Subject labels](#subject-labels)
- [Team labels](#team-labels)
- [Milestone labels](#milestone-labels)
- [Bug Priority labels](#bug-priority-labels)
- [Bug Severity labels](#bug-severity-labels)
- [Severity impact guidance](#severity-impact-guidance)
- [Label for community contributors](#label-for-community-contributors)
- [Implement design & UI elements](#implement-design--ui-elements)
- [Issue tracker](#issue-tracker)
- [Issue triaging](#issue-triaging)
- [Feature proposals](#feature-proposals)
- [Issue tracker guidelines](#issue-tracker-guidelines)
- [Issue weight](#issue-weight)
- [Regression issues](#regression-issues)
- [Technical and UX debt](#technical-and-ux-debt)
- [Stewardship](#stewardship)
- [Merge requests](#merge-requests)
- [Merge request guidelines](#merge-request-guidelines)
- [Contribution acceptance criteria](#contribution-acceptance-criteria)
- [Definition of done](#definition-of-done)
- [Style guides](#style-guides)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
## Contribute to GitLab
For a first-time step-by-step guide to the contribution process, see For a first-time step-by-step guide to the contribution process, see
["Contributing to GitLab"](https://about.gitlab.com/contributing/). ["Contributing to GitLab"](https://about.gitlab.com/contributing/).
......
doc/development/contributing/issue_workflow.md
View file @ 50f8ead5
<!-- START doctoc generated TOC please keep comment here to allow auto update --> # Workflow labels
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
**Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)*
- [Workflow labels](#workflow-labels)
- [Type labels](#type-labels)
- [Subject labels](#subject-labels)
- [Team labels](#team-labels)
- [Release Scoping labels](#release-scoping-labels)
- [Priority labels](#priority-labels)
- [Severity labels](#severity-labels)
- [Severity impact guidance](#severity-impact-guidance)
- [Label for community contributors](#label-for-community-contributors)
- [Issue triaging](#issue-triaging)
- [Feature proposals](#feature-proposals)
- [Issue tracker guidelines](#issue-tracker-guidelines)
- [Issue weight](#issue-weight)
- [Regression issues](#regression-issues)
- [Technical and UX debt](#technical-and-ux-debt)
- [Stewardship](#stewardship)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
## Workflow labels
To allow for asynchronous issue handling, we use [milestones][milestones-page] To allow for asynchronous issue handling, we use [milestones][milestones-page]
and [labels][labels-page]. Leads and product managers handle most of the and [labels][labels-page]. Leads and product managers handle most of the
...@@ -45,7 +22,7 @@ labels, you can _always_ add the team and type, and often also the subject. ...@@ -45,7 +22,7 @@ labels, you can _always_ add the team and type, and often also the subject.
[milestones-page]: https://gitlab.com/gitlab-org/gitlab-ce/milestones [milestones-page]: https://gitlab.com/gitlab-org/gitlab-ce/milestones
[labels-page]: https://gitlab.com/gitlab-org/gitlab-ce/labels [labels-page]: https://gitlab.com/gitlab-org/gitlab-ce/labels
### Type labels ## Type labels
Type labels are very important. They define what kind of issue this is. Every Type labels are very important. They define what kind of issue this is. Every
issue should have one or more. issue should have one or more.
...@@ -61,7 +38,7 @@ already reserved for subject labels). ...@@ -61,7 +38,7 @@ already reserved for subject labels).
The descriptions on the [labels page][labels-page] explain what falls under each type label. The descriptions on the [labels page][labels-page] explain what falls under each type label.
### Subject labels ## Subject labels
Subject labels are labels that define what area or feature of GitLab this issue Subject labels are labels that define what area or feature of GitLab this issue
hits. They are not always necessary, but very convenient. hits. They are not always necessary, but very convenient.
...@@ -75,7 +52,7 @@ issue is labeled with a subject label corresponding to your expertise. ...@@ -75,7 +52,7 @@ issue is labeled with a subject label corresponding to your expertise.
Subject labels are always all-lowercase. Subject labels are always all-lowercase.
### Team labels ## Team labels
Team labels specify what team is responsible for this issue. Team labels specify what team is responsible for this issue.
Assigning a team label makes sure issues get the attention of the appropriate Assigning a team label makes sure issues get the attention of the appropriate
...@@ -107,7 +84,7 @@ indicate if an issue needs backend work, frontend work, or both. ...@@ -107,7 +84,7 @@ indicate if an issue needs backend work, frontend work, or both.
Team labels are always capitalized so that they show up as the first label for Team labels are always capitalized so that they show up as the first label for
any issue. any issue.
### Release Scoping labels ## Release Scoping labels
Release Scoping labels help us clearly communicate expectations of the work for the Release Scoping labels help us clearly communicate expectations of the work for the
release. There are three levels of Release Scoping labels: release. There are three levels of Release Scoping labels:
...@@ -138,7 +115,7 @@ This label documents the planned timeline & urgency which is used to measure aga ...@@ -138,7 +115,7 @@ This label documents the planned timeline & urgency which is used to measure aga
| ~P3 | Medium Priority | Within the next 3 releases (approx one quarter) | | ~P3 | Medium Priority | Within the next 3 releases (approx one quarter) |
| ~P4 | Low Priority | Anything outside the next 3 releases (approx beyond one quarter) | | ~P4 | Low Priority | Anything outside the next 3 releases (approx beyond one quarter) |
### Severity labels ## Severity labels
Severity labels help us clearly communicate the impact of a ~bug on users. Severity labels help us clearly communicate the impact of a ~bug on users.
...@@ -149,7 +126,7 @@ Severity labels help us clearly communicate the impact of a ~bug on users. ...@@ -149,7 +126,7 @@ Severity labels help us clearly communicate the impact of a ~bug on users.
| ~S3 | Major Severity | Broken Feature, workaround acceptable | Can create merge requests only from the Merge Requests page, not through the Issue. | | ~S3 | Major Severity | Broken Feature, workaround acceptable | Can create merge requests only from the Merge Requests page, not through the Issue. |
| ~S4 | Low Severity | Functionality inconvenience or cosmetic issue | Label colors are incorrect / not being displayed. | | ~S4 | Low Severity | Functionality inconvenience or cosmetic issue | Label colors are incorrect / not being displayed. |
#### Severity impact guidance ### Severity impact guidance
Severity levels can be applied further depending on the facet of the impact; e.g. Affected customers, GitLab.com availability, performance and etc. The below is a guideline. Severity levels can be applied further depending on the facet of the impact; e.g. Affected customers, GitLab.com availability, performance and etc. The below is a guideline.
...@@ -160,7 +137,7 @@ Severity levels can be applied further depending on the facet of the impact; e.g ...@@ -160,7 +137,7 @@ Severity levels can be applied further depending on the facet of the impact; e.g
| ~S3 | A few users or a single paid customer affected | Limited impact on important portions of GitLab.com | Degradation is likely to occur in the near future | | ~S3 | A few users or a single paid customer affected | Limited impact on important portions of GitLab.com | Degradation is likely to occur in the near future |
| ~S4 | No paid users/customer affected, or expected to in the near future | Minor impact on on GitLab.com | Degradation _may_ occur but it's not likely | | ~S4 | No paid users/customer affected, or expected to in the near future | Minor impact on on GitLab.com | Degradation _may_ occur but it's not likely |
### Label for community contributors ## Label for community contributors
Issues that are beneficial to our users, 'nice to haves', that we currently do Issues that are beneficial to our users, 'nice to haves', that we currently do
not have the capacity for or want to give the priority to, are labeled as not have the capacity for or want to give the priority to, are labeled as
...@@ -210,8 +187,7 @@ any potential community contributor to @-mention per above. ...@@ -210,8 +187,7 @@ any potential community contributor to @-mention per above.
[up-for-grabs]: https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name=Accepting+Merge+Requests&scope=all&sort=weight_asc&state=opened [up-for-grabs]: https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name=Accepting+Merge+Requests&scope=all&sort=weight_asc&state=opened
[firt-timers]: https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=Accepting+Merge+Requests&scope=all&sort=upvotes_desc&state=opened&weight=1 [firt-timers]: https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=Accepting+Merge+Requests&scope=all&sort=upvotes_desc&state=opened&weight=1
## Issue triaging
### Issue triaging
Our issue triage policies are [described in our handbook]. You are very welcome Our issue triage policies are [described in our handbook]. You are very welcome
to help the GitLab team triage issues. We also organize [issue bash events] once to help the GitLab team triage issues. We also organize [issue bash events] once
...@@ -233,7 +209,7 @@ project. ...@@ -233,7 +209,7 @@ project.
[scheduled pipeline]: https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/10512/edit [scheduled pipeline]: https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/10512/edit
[quality/triage-ops]: https://gitlab.com/gitlab-org/quality/triage-ops [quality/triage-ops]: https://gitlab.com/gitlab-org/quality/triage-ops
### Feature proposals ## Feature proposals
To create a feature proposal for CE, open an issue on the To create a feature proposal for CE, open an issue on the
[issue tracker of CE][ce-tracker]. [issue tracker of CE][ce-tracker].
...@@ -259,7 +235,7 @@ need to ask one of the [core team] members to add the label, if you do not have ...@@ -259,7 +235,7 @@ need to ask one of the [core team] members to add the label, if you do not have
If you want to create something yourself, consider opening an issue first to If you want to create something yourself, consider opening an issue first to
discuss whether it is interesting to include this in GitLab. discuss whether it is interesting to include this in GitLab.
### Issue tracker guidelines ## Issue tracker guidelines
**[Search the issue tracker][ce-tracker]** for similar entries before **[Search the issue tracker][ce-tracker]** for similar entries before
submitting your own, there's a good chance somebody else had the same issue or submitting your own, there's a good chance somebody else had the same issue or
...@@ -271,7 +247,7 @@ The text in the parenthesis is there to help you with what to include. Omit it ...@@ -271,7 +247,7 @@ The text in the parenthesis is there to help you with what to include. Omit it
when submitting the actual issue. You can copy-paste it and then edit as you when submitting the actual issue. You can copy-paste it and then edit as you
see fit. see fit.
### Issue weight ## Issue weight
Issue weight allows us to get an idea of the amount of work required to solve Issue weight allows us to get an idea of the amount of work required to solve
one or multiple issues. This makes it possible to schedule work more accurately. one or multiple issues. This makes it possible to schedule work more accurately.
...@@ -293,7 +269,7 @@ is probably 1, adding a new Git Hook maybe 4 or 5, big features 7-9. ...@@ -293,7 +269,7 @@ is probably 1, adding a new Git Hook maybe 4 or 5, big features 7-9.
issues or chunks. You can simply not set the weight of a parent issue and set issues or chunks. You can simply not set the weight of a parent issue and set
weights to children issues. weights to children issues.
### Regression issues ## Regression issues
Every monthly release has a corresponding issue on the CE issue tracker to keep Every monthly release has a corresponding issue on the CE issue tracker to keep
track of functionality broken by that release and any fixes that need to be track of functionality broken by that release and any fixes that need to be
...@@ -313,7 +289,7 @@ addressed. ...@@ -313,7 +289,7 @@ addressed.
[8.3 Regressions]: https://gitlab.com/gitlab-org/gitlab-ce/issues/4127 [8.3 Regressions]: https://gitlab.com/gitlab-org/gitlab-ce/issues/4127
[update the notes]: https://gitlab.com/gitlab-org/release-tools/blob/master/doc/pro-tips.md#update-the-regression-issue [update the notes]: https://gitlab.com/gitlab-org/release-tools/blob/master/doc/pro-tips.md#update-the-regression-issue
### Technical and UX debt ## Technical and UX debt
In order to track things that can be improved in GitLab's codebase, In order to track things that can be improved in GitLab's codebase,
we use the ~"technical debt" label in [GitLab's issue tracker][ce-tracker]. we use the ~"technical debt" label in [GitLab's issue tracker][ce-tracker].
...@@ -337,7 +313,7 @@ for a release by the appropriate person. ...@@ -337,7 +313,7 @@ for a release by the appropriate person.
Make sure to mention the merge request that the ~"technical debt" issue or Make sure to mention the merge request that the ~"technical debt" issue or
~"UX debt" issue is associated with in the description of the issue. ~"UX debt" issue is associated with in the description of the issue.
### Stewardship ## Stewardship
For issues related to the open source stewardship of GitLab, For issues related to the open source stewardship of GitLab,
there is the ~"stewardship" label. there is the ~"stewardship" label.
......
doc/development/contributing/merge_request_workflow.md
View file @ 50f8ead5
<!-- START doctoc generated TOC please keep comment here to allow auto update --> # Merge requests
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
**Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)*
- [Merge requests](#merge-requests)
- [Merge request guidelines](#merge-request-guidelines)
- [Contribution acceptance criteria](#contribution-acceptance-criteria)
- [Definition of done](#definition-of-done)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
## Merge requests
We welcome merge requests with fixes and improvements to GitLab code, tests, We welcome merge requests with fixes and improvements to GitLab code, tests,
and/or documentation. The issues that are specifically suitable for and/or documentation. The issues that are specifically suitable for
...@@ -36,7 +25,7 @@ some potentially easy issues. ...@@ -36,7 +25,7 @@ some potentially easy issues.
To start with GitLab development download the [GitLab Development Kit][gdk] and To start with GitLab development download the [GitLab Development Kit][gdk] and
see the [Development section](../README.md) for some guidelines. see the [Development section](../README.md) for some guidelines.
### Merge request guidelines ## Merge request guidelines
If you can, please submit a merge request with the fix or improvements If you can, please submit a merge request with the fix or improvements
including tests. If you don't know how to fix the issue but can write a test including tests. If you don't know how to fix the issue but can write a test
...@@ -114,7 +103,7 @@ Please ensure that your merge request meets the contribution acceptance criteria ...@@ -114,7 +103,7 @@ Please ensure that your merge request meets the contribution acceptance criteria
When having your code reviewed and when reviewing merge requests please take the When having your code reviewed and when reviewing merge requests please take the
[code review guidelines](../code_review.md) into account. [code review guidelines](../code_review.md) into account.
### Contribution acceptance criteria ## Contribution acceptance criteria
1. The change is as small as possible 1. The change is as small as possible
1. Include proper tests and make all tests pass (unless it contains a test 1. Include proper tests and make all tests pass (unless it contains a test
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7