Merge branch 'document-auto-update-of-dependencies' into 'master'

doc: Add a Dependencies doc page under Development

See merge request gitlab-org/gitlab!66626

doc/development/dependencies.md

+---
+stage: none
+group: unassigned
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Dependencies
+
+## Dependency updates
+
+We use the [Renovate GitLab Bot](https://gitlab.com/gitlab-org/frontend/renovate-gitlab-bot) to
+automatically create merge requests for updating (some) Node and Ruby dependencies in several projects.
+You can find the up-to-date list of projects managed by the renovate bot in the project's README.
+
+Some key dependencies updated using renovate are:
+
+- [`@gitlab/ui`](https://gitlab.com/gitlab-org/gitlab-ui)
+- [`@gitlab/svgs`](https://gitlab.com/gitlab-org/gitlab-svgs)
+- [`@gitlab/eslint-plugin`](https://gitlab.com/gitlab-org/frontend/eslint-plugin)
+- And any other package in the `@gitlab/` scope
+
+We have the goal of updating [_all_ dependencies with renovate](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/21).
+
+Updating dependencies automatically has several benefits, have a look at this [example MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/53613).
+
+- MRs are created automatically when new versions are released.
+- MRs can easily be rebased and updated by just checking a checkbox in the MR description.
+- MRs contain changelog summaries and links to compare the different package versions.
+- MRs can be assigned to people directly responsible for the dependencies.
+
+### Community contributions updating dependencies
+
+It is okay to reject Community Contributions that solely bump dependencies.
+Simple dependency updates are better done automatically for the reasons provided above.
+If a community contribution needs to be rebased, runs into conflicts, or goes stale, the effort required
+to instruct the contributor to correct it often outweighs the benefits.
+
+If a dependency update is accompanied with significant migration efforts, due to major version updates,
+a community contribution is acceptable.
+
+Here is a message you can use to explain to community contributors as to why we reject simple updates:
+
+```markdown
+Hello CONTRIBUTOR!
+
+Thank you very much for this contribution. It seems like you are doing a "simple" dependency update.
+
+If a dependency update is as simple as increasing the version number, we'd like a Bot to do this to save you and ourselves some time.
+
+This has certain benefits as outlined in our <a href="https://docs.gitlab.com/ee/development/fe_guide/dependencies.html#updating-dependencies">Frontend development guidelines</a>.
+
+You might find that we do not currently update DEPENDENCY automatically, but we are planning to do so in [the near future](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/21).
+
+Thank you for understanding, I will close this Merge Request.
+/close
+```

doc/development/fe_guide/dependencies.md

@@ -24,52 +24,7 @@ production assets post-compile.
 
 ## Updating dependencies
 
-We use the [Renovate GitLab Bot](https://gitlab.com/gitlab-org/frontend/renovate-gitlab-bot) to
-automatically create merge requests for updating dependencies of several projects.
-You can find the up-to-date list of projects managed by the renovate bot in the project's README.
-
-Some key dependencies updated using renovate are:
-
-- [`@gitlab/ui`](https://gitlab.com/gitlab-org/gitlab-ui)
-- [`@gitlab/svgs`](https://gitlab.com/gitlab-org/gitlab-svgs)
-- [`@gitlab/eslint-plugin`](https://gitlab.com/gitlab-org/frontend/eslint-plugin)
-- And any other package in the `@gitlab/` scope
-
-We have the goal of updating [_all_ dependencies with renovate](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/21).
-
-Updating dependencies automatically has several benefits, have a look at this [example MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/53613).
-
-- MRs will be created automatically when new versions are released
-- MRs can easily be rebased and updated with just checking a checkbox in the MR description
-- MRs contain changelog summaries and links to compare the different package versions
-- MRs can be assigned to people directly responsible for the dependencies
-
-### Community contributions updating dependencies
-
-It is okay to reject Community Contributions that solely bump dependencies.
-Simple dependency updates are better done automatically for the reasons provided above.
-If a community contribution needs to be rebased, runs into conflicts, or goes stale, the effort required
-to instruct the contributor to correct it often outweighs the benefits.
-
-If a dependency update is accompanied with significant migration efforts, due to major version updates,
-a community contribution is acceptable.
-
-Here is a message you can use to explain to community contributors as to why we reject simple updates:
-
-```markdown
-Hello CONTRIBUTOR!
-
-Thank you very much for this contribution. It seems like you are doing a "simple" dependency update.
-
-If a dependency update is as simple as increasing the version number, we'd like a Bot to do this to save you and ourselves some time.
-
-This has certain benefits as outlined in our <a href="https://docs.gitlab.com/ee/development/fe_guide/dependencies.html#updating-dependencies">Frontend development guidelines</a>.
-
-You might find that we do not currently update DEPENDENCY automatically, but we are planning to do so in [the near future](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/21).
-
-Thank you for understanding, I will close this Merge Request.
-/close
-```
+See the main [Dependencies](../dependencies.md) page for general information about dependency updates.
 
 ### Blocked dependencies
 

doc/development/index.md

@@ -63,12 +63,13 @@ Complementary reads:
 
 - [GitLab core team & GitLab Inc. contribution process](https://gitlab.com/gitlab-org/gitlab/-/blob/master/PROCESS.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)
-- [Danger bot](dangerbot.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)
-- [Patch release process for developers](https://gitlab.com/gitlab-org/release/docs/blob/master/general/patch/process.md#process-for-developers)
-- [Adding a new service component to GitLab](adding_service_component.md)
 
 ### Development guidelines review