Add latest changes from gitlab-org/gitlab@14-10-stable-eev14.10.0-rc42

4 files changed, 11 insertions, 16 deletions

diff --git a/doc/development/contributing/design.md b/doc/development/contributing/design.md
index 463a7ee0e0b..def39a960d8 100644
--- a/doc/development/contributing/design.md
+++ b/doc/development/contributing/design.md
@@ -49,7 +49,7 @@ Check these aspects both when _designing_ and _reviewing_ UI changes.
 ### Visual design
 
 Check visual design properties using your browser's _elements inspector_ ([Chrome](https://developer.chrome.com/docs/devtools/css/),
-[Firefox](https://developer.mozilla.org/en-US/docs/Tools/Page_Inspector/How_to/Open_the_Inspector)).
+[Firefox](https://firefox-source-docs.mozilla.org/devtools-user/page_inspector/how_to/open_the_inspector/index.html)).
 
 - Use recommended [colors](https://design.gitlab.com/product-foundations/colors/)
   and [typography](https://design.gitlab.com/product-foundations/type-fundamentals/).
@@ -66,7 +66,7 @@ Check visual design properties using your browser's _elements inspector_ ([Chrom
 
 Check states using your browser's _styles inspector_ to toggle CSS pseudo-classes
 like `:hover` and others ([Chrome](https://developer.chrome.com/docs/devtools/css/reference/#pseudo-class),
-[Firefox](https://developer.mozilla.org/en-US/docs/Tools/Page_Inspector/How_to/Examine_and_edit_CSS#viewing_common_pseudo-classes)).
+[Firefox](https://firefox-source-docs.mozilla.org/devtools-user/page_inspector/how_to/examine_and_edit_css/index.html#viewing-common-pseudo-classes)).
 
 - Account for all applicable states ([error](https://design.gitlab.com/content/error-messages),
   rest, loading, focus, hover, selected, disabled).
@@ -78,7 +78,7 @@ like `:hover` and others ([Chrome](https://developer.chrome.com/docs/devtools/cs
 ### Responsive
 
 Check responsive behavior using your browser's _responsive mode_ ([Chrome](https://developer.chrome.com/docs/devtools/device-mode/#viewport),
-[Firefox](https://developer.mozilla.org/en-US/docs/Tools/Responsive_Design_Mode)).
+[Firefox](https://firefox-source-docs.mozilla.org/devtools-user/responsive_design_mode/index.html)).
 
 - Account for resizing, collapsing, moving, or wrapping of elements across
   all breakpoints (even if larger viewports are prioritized).
@@ -99,7 +99,7 @@ Check accessibility using your browser's _accessibility inspector_ ([Chrome](htt
 When the design is ready, _before_ starting its implementation:
 
 - Share design specifications in the related issue, preferably through a [Figma link](https://help.figma.com/hc/en-us/articles/360040531773-Share-Files-with-anyone-using-Link-Sharing#Copy_links)
-  link or [GitLab Designs feature](../../user/project/issues/design_management.md#the-design-management-section).
+  link or [GitLab Designs feature](../../user/project/issues/design_management.md).
   See [when you should use each tool](https://about.gitlab.com/handbook/engineering/ux/product-designer/#deliver).
 - Document user flow and states (for example, using [Mermaid flowcharts in Markdown](../../user/markdown.md#mermaid)).
 - Document animations and transitions.
diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md
index 4db686b9b1e..fe1549e7f34 100644
--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@@ -31,11 +31,7 @@ on those issues. Please select someone with relevant experience from the
 If there is nobody mentioned with that expertise, look in the commit history for
 the affected files to find someone.
 
-We also use [GitLab Triage](https://gitlab.com/gitlab-org/gitlab-triage) to automate
-some triaging policies. This is currently set up as a scheduled pipeline
-(`https://gitlab.com/gitlab-org/quality/triage-ops/-/pipeline_schedules/10512/edit`,
-must have at least the Developer role in the project) running on [quality/triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops)
-project.
+We also have triage automation in place, described [in our handbook](https://about.gitlab.com/handbook/engineering/quality/triage-operations/).
 
 ## Labels
 
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index a9b4d13ab06..5ed0885eed9 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -144,7 +144,7 @@ document from the Kubernetes team also has some great points regarding this.
 
 ### Commit messages guidelines
 
-Commit messages should follow the guidelines below, for reasons explained by Chris Beams in [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/):
+Commit messages should follow the guidelines below, for reasons explained by Chris Beams in [How to Write a Git Commit Message](https://cbea.ms/git-commit/):
 
 - The commit subject and body must be separated by a blank line.
 - The commit subject must start with a capital letter.
@@ -203,7 +203,7 @@ Example commit message template that can be used on your machine that embodies t
 #    Do not use Emojis
 #    Use the body to explain what and why vs. how
 #    Can use multiple lines with "-" for bullet points in body
-#    For more information: https://chris.beams.io/posts/git-commit/
+#    For more information: https://cbea.ms/git-commit/
 # --------------------
 ```
 
@@ -286,8 +286,8 @@ requirements.
 ### Production use
 
 1. Confirmed to be working in staging before implementing the change in production, where possible.
-1. Confirmed to be working in the production with no new [Sentry](https://about.gitlab.com/handbook/engineering/#sentry) errors after the contribution is deployed.
-1. Confirmed that the [rollout plan](https://about.gitlab.com/handbook/engineering/development/processes/rollout-plans) has been completed.
+1. Confirmed to be working in the production with no new [Sentry](https://about.gitlab.com/handbook/engineering/monitoring/#sentry) errors after the contribution is deployed.
+1. Confirmed that the [rollout plan](https://about.gitlab.com/handbook/engineering/development/processes/rollout-plans/) has been completed.
 1. If there is a performance risk in the change, I have analyzed the performance of the system before and after the change.
 1. *If the merge request uses feature flags, per-project or per-group enablement, and a staged rollout:*
    - Confirmed to be working on GitLab projects.
diff --git a/doc/development/contributing/verify/index.md b/doc/development/contributing/verify/index.md
index a2bb0eca733..828eb0a9598 100644
--- a/doc/development/contributing/verify/index.md
+++ b/doc/development/contributing/verify/index.md
@@ -55,7 +55,7 @@ and they serve us and our users well. Some examples of these principles are that
 - Feedback needs to be available when a user needs it and data can not disappear unexpectedly when engineers need it.
 - It all doesn’t matter if the platform is not secure and we
 are leaking credentials or secrets.
-- When a user provides a set of preconditions in a form of CI/CD configuration, the result should be deterministic each time a pipeline runs, because otherwise the platform might not be trustworthy. 
+- When a user provides a set of preconditions in a form of CI/CD configuration, the result should be deterministic each time a pipeline runs, because otherwise the platform might not be trustworthy.
 - If it is fast, simple to use and has a great UX it will serve our users well.
 
 ## Building things in Verify
@@ -189,8 +189,7 @@ Slack channel (GitLab team members only).
 After your merge request is merged by a maintainer, it is time to release it to
 users and the wider community. We usually do this with feature flags.
 While not every merge request needs a feature flag, most merge
-requests in Verify should have feature flags. [**TODO** link to docs about what
-needs a feature flag and what doesn’t].
+requests in Verify should have [feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags).
 
 If you already follow the advice on this page, you probably already have a
 few metrics and perhaps a few loggers added that make your new code observable