Remove label examples from headings

Better make it clearer under each section what the labels are
rather than listing a subset of them in the section title

CONTRIBUTING.md

@@ -27,25 +27,26 @@ _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)
-  - [Issue tracker guidelines](#issue-tracker-guidelines)
-  - [Issue weight](#issue-weight)
-  - [Regression issues](#regression-issues)
-  - [Technical and UX debt](#technical-and-ux-debt)
-  - [Stewardship](#stewardship)
+    - [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)
+    - [Merge request guidelines](#merge-request-guidelines)
+    - [Contribution acceptance criteria](#contribution-acceptance-criteria)
 - [Definition of done](#definition-of-done)
 - [Style guides](#style-guides)
 - [Code of conduct](#code-of-conduct)
@@ -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,9 +225,9 @@ 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. 
+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.
 This label documents the planned timeline & urgency which is used to measure against our actual SLA on delivering ~bug fixes.
 
@@ -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.
 
@@ -240,11 +254,11 @@ Severity labels help us clearly communicate the impact of a ~bug on users.
 | Label | Security Impact                                                     | Availability / Performance Impact                            |
 |-------|---------------------------------------------------------------------|--------------------------------------------------------------|
 | ~S1   | >50% users impacted (possible company extinction level event)       |                                                              |
-| ~S2   | Many users or multiple paid customers impacted (but not apocalyptic)| The issue is (almost) guaranteed to occur in the near future |  
+| ~S2   | Many users or multiple paid customers impacted (but not apocalyptic)| The issue is (almost) guaranteed to occur in the near future |
 | ~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
@@ -300,14 +314,14 @@ For guidance on UX implementation at GitLab, please refer to our [Design System]
 
 The UX team uses labels to manage their workflow.
 
-The  ~"UX" label on an issue is a signal to the UX team that it will need UX attention. 
+The  ~"UX" label on an issue is a signal to the UX team that it will need UX attention.
 To better understand the priority by which UX tackles issues, see the [UX section](https://about.gitlab.com/handbook/engineering/ux) of the handbook.
 
 Once an issue has been worked on and is ready for development, a UXer removes the ~"UX" label and applies the ~"UX ready" label to that issue.
 
-The UX team has a special type label called ~"design artifact". This label indicates that the final output 
+The UX team has a special type label called ~"design artifact". This label indicates that the final output
 for an issue is a UX solution/design. The solution will be developed by frontend and/or backend in a subsequent milestone.
-Any issue labeled ~"design artifact" should not also be labeled ~"frontend" or ~"backend" since no development is 
+Any issue labeled ~"design artifact" should not also be labeled ~"frontend" or ~"backend" since no development is
 needed until the solution has been decided.
 
 ~"design artifact" issues are like any other issue and should contain a milestone label, ~"Deliverable" or ~"Stretch", when scheduled in the current milestone.