Merge branch 'docs/contributing-md-labels' into 'master'

Remove label examples from headings

See merge request gitlab-org/gitlab-ce!19982

CONTRIBUTING.md

@@ -27,14 +27,15 @@ _This notice should stay as the first item in the CONTRIBUTING.md file._
 - [Helping others](#helping-others)
 - [I want to contribute!](#i-want-to-contribute)
 - [Workflow labels](#workflow-labels)
-  - [Type labels (~"feature proposal", ~bug, ~customer, etc.)](#type-labels-feature-proposal-bug-customer-etc)
-  - [Subject labels (~wiki, ~"container registry", ~ldap, ~api, etc.)](#subject-labels-wiki-container-registry-ldap-api-etc)
-  - [Team labels (~"CI/CD", ~Discussion, ~Quality, ~Platform, etc.)](#team-labels-cicd-discussion-quality-platform-etc)
-  - [Milestone labels (~Deliverable, ~Stretch, ~"Next Patch Release")](#milestone-labels-deliverable-stretch-next-patch-release)
-  - [Priority labels (~P1, ~P2, ~P3 , ~P4)](#bug-priority-labels-p1-p2-p3-p4)
-  - [Severity labels (~S1, ~S2, ~S3 , ~S4)](#bug-severity-labels-s1-s2-s3-s4)
-  - [Label for community contributors (~"Accepting Merge Requests")](#label-for-community-contributors-accepting-merge-requests)
-- [Implement design & UI elements](#implement-design--ui-elements)
+    - [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)
@@ -145,7 +146,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
 [labels-page]: https://gitlab.com/gitlab-org/gitlab-ce/labels
 
-### Type labels (~"feature proposal", ~bug, ~customer, etc.)
+### Type labels
 
 Type labels are very important. They define what kind of issue this is. Every
 issue should have one or more.
@@ -161,28 +162,41 @@ already reserved for subject labels).
 
 The descriptions on the [labels page][labels-page] explain what falls under each type label.
 
-### Subject labels (~wiki, ~"container registry", ~ldap, ~api, etc.)
+### Subject labels
 
 Subject labels are labels that define what area or feature of GitLab this issue
 hits. They are not always necessary, but very convenient.
 
+Examples of subject labels are ~wiki, ~ldap, ~api,
+~issues, ~"merge requests", ~labels, and ~"container registry".
+
 If you are an expert in a particular area, it makes it easier to find issues to
 work on. You can also subscribe to those labels to receive an email each time an
 issue is labeled with a subject label corresponding to your expertise.
 
-Examples of subject labels are ~wiki, ~"container registry", ~ldap, ~api,
-~issues, ~"merge requests", ~labels, and ~"container registry".
-
 Subject labels are always all-lowercase.
 
-### Team labels (~"CI/CD", ~Discussion, ~Quality, ~Platform, etc.)
+### Team labels
 
 Team labels specify what team is responsible for this issue.
 Assigning a team label makes sure issues get the attention of the appropriate
 people.
 
-The current team labels are ~Distribution, ~"CI/CD", ~Discussion, ~Documentation, ~Quality,
-~Geo, ~Gitaly, ~Monitoring, ~Platform, ~Release, ~"Security Products", ~"Configuration", and ~"UX".
+The current team labels are:
+
+- ~Configuration
+- ~"CI/CD"
+- ~Discussion
+- ~Distribution
+- ~Documentation
+- ~Geo
+- ~Gitaly
+- ~Monitoring
+- ~Platform
+- ~Quality
+- ~Release
+- ~"Security Products"
+- ~UX
 
 The descriptions on the [labels page][labels-page] explain what falls under the
 responsibility of each team.
@@ -193,7 +207,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
 any issue.
 
-### Milestone labels (~Deliverable, ~Stretch, ~"Next Patch Release")
+### Milestone labels
 
 Milestone labels help us clearly communicate expectations of the work for the
 release. There are three levels of Milestone labels:
@@ -211,7 +225,7 @@ Each issue scheduled for the current milestone should be labeled ~Deliverable
 or ~"Stretch". Any open issue for a previous milestone should be labeled
 ~"Next Patch Release", or otherwise rescheduled to a different milestone.
 
-### Bug Priority labels (~P1, ~P2, ~P3, ~P4)
+### Bug Priority labels
 
 Bug Priority labels help us define the time a ~bug fix should be completed. Priority determines how quickly the defect turnaround time must be.
 If there are multiple defects, the priority decides which defect has to be fixed immediately versus later.
@@ -224,7 +238,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)                  |  |
 | ~P4   | Low Priority    | Anything outside the next 3 releases (approx beyond one quarter) | The issue is prominent but does not impact user workflow and a workaround is documented  |
 
-### Bug Severity labels (~S1, ~S2, ~S3, ~S4)
+### Bug Severity labels
 
 Severity labels help us clearly communicate the impact of a ~bug on users.
 
@@ -244,7 +258,7 @@ Severity labels help us clearly communicate the impact of a ~bug on users.
 | ~S3   | A few users or a single paid customer impacted                      | The issue is likely to occur in the near future              |
 | ~S4   | No paid users/customer impacted, or expected impact within 30 days  | The issue _may_ occur but it's not likely                    |
 
-### Label for community contributors (~"Accepting Merge Requests")
+### Label for community contributors
 
 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