Rename /contributors/code/getting-started

Rename /contributors/code/getting-started to /contributors/code/getting-started-with-code-contribution.

This is done to avoid having two handbook pages with the same slug, because this results in some confusion when the pages are generated.

Also, replace all the occurence of the first with the second.

docs/contributors/accessibility-testing.md

@@ -4,7 +4,7 @@ This is a guide on how to test accessibility on Gutenberg. This is a living docu
 
 ## Getting Started
 
-Make sure you have set up your local environment following the instructions on [Getting Started](/docs/contributors/code/getting-started.md).
+Make sure you have set up your local environment following the instructions on [Getting Started](/docs/contributors/code/getting-started-with-code-contribution.md).
 
 ## Keyboard Testing
 

docs/contributors/code/code.md

@@ -16,7 +16,7 @@ Browse [the issues list](https://github.com/wordpress/gutenberg/issues) to find
 
 ## Contributor Resources
 
-* [Getting Started](/docs/contributors/code/getting-started.md) documents getting your development environment setup, this includes your test site and developer tools suggestions.
+* [Getting Started](/docs/contributors/code/getting-started-with-code-contribution.md) documents getting your development environment setup, this includes your test site and developer tools suggestions.
 * [Git Workflow](/docs/contributors/code/git-workflow.md) documents the git process for deploying changes using pull requests.
 * [Coding Guidelines](/docs/contributors/code/coding-guidelines.md) outline additional patterns and conventions used in the Gutenberg project.
 * [Testing Overview](/docs/contributors/code/testing-overview.md) for PHP and JavaScript development in Gutenberg.

docs/contributors/code/coding-guidelines.md

@@ -472,6 +472,6 @@ For class components, there is no recommendation for documenting the props of th
 We use
 [`phpcs` (PHP_CodeSniffer)](https://github.com/squizlabs/PHP_CodeSniffer) with the [WordPress Coding Standards ruleset](https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards) to run a lot of automated checks against all PHP code in this project. This ensures that we are consistent with WordPress PHP coding standards.
 
-The easiest way to use PHPCS is [local environment](/docs/contributors/code/getting-started.md#local-environment). Once that's installed, you can check your PHP by running `npm run lint-php`.
+The easiest way to use PHPCS is [local environment](/docs/contributors/code/getting-started-with-code-contribution.md#local-environment). Once that's installed, you can check your PHP by running `npm run lint-php`.
 
 If you prefer to install PHPCS locally, you should use `composer`. [Install `composer`](https://getcomposer.org/download/) on your computer, then run `composer install`. This will install `phpcs` and `WordPress-Coding-Standards` which you can then run via `composer lint`.

docs/contributors/code/getting-started.md → docs/contributors/code/getting-started-with-code-contribution.md

@@ -1,4 +1,4 @@
-# Getting Started
+# Getting Started With Code Contribution
 
 The following guide is for setting up your local environment to contribute to the Gutenberg project. There is significant overlap between an environment to contribute and an environment used to extend the WordPress block editor. You can review the [Development Environment tutorial](/docs/getting-started/tutorials/devenv/README.md) for additional setup information.
 

docs/contributors/code/native-mobile.md

@@ -4,7 +4,7 @@ Intertwined with the web codepaths, the Gutenberg repo also includes the [React
 
 ## Running Gutenberg Mobile on Android and iOS
 
-For instructions on how to run the **Gutenberg Mobile Demo App** on Android or iOS, see [Getting Started for the React Native based Mobile Gutenberg](/docs/contributors/code/getting-started-native-mobile.md)
+For instructions on how to run the **Gutenberg Mobile Demo App** on Android or iOS, see [Getting Started for the React Native based Mobile Gutenberg](/docs/contributors/code/getting-started-with-code-contribution-native-mobile.md)
 
 Also, the mobile client is packaged and released via the [official WordPress apps](https://wordpress.org/mobile/). Even though the build pipeline is slightly different then the mobile demo apps and lives in its own repo for now ([here's the native mobile repo](https://github.com/wordpress-mobile/gutenberg-mobile)), the source code itself is taken directly from this repo and the "web" side codepaths.
 
@@ -21,7 +21,7 @@ Our tooling isn't as good yet as we'd like to and it's hard to have a good aware
 If you encounter a failed Android/iOS test on your pull request, we recommend the following steps:
 
 1. Re-running the failed GitHub Action job ([guide for how to re-run](https://docs.github.com/en/actions/configuring-and-managing-workflows/managing-a-workflow-run#viewing-your-workflow-history)) - This should fix failed tests the majority of the time. Cases where you need to re-run tests for a pass should go down in the near future as flakiness in tests is actively being worked on. See the following GitHub issue for updated info on known failures: https://github.com/WordPress/gutenberg/issues/23949
-2. You can check if the test is failing locally by following the steps to run the E2E test on your machine from the [mobile getting started guide](/docs/contributors/code/getting-started-native-mobile.md#ui-tests), with even more relevant info in the [relevant directory README.md](https://github.com/WordPress/gutenberg/tree/HEAD/packages/react-native-editor/__device-tests__#running-the-tests-locally)
+2. You can check if the test is failing locally by following the steps to run the E2E test on your machine from the [mobile getting started guide](/docs/contributors/code/getting-started-with-code-contribution-native-mobile.md#ui-tests), with even more relevant info in the [relevant directory README.md](https://github.com/WordPress/gutenberg/tree/HEAD/packages/react-native-editor/__device-tests__#running-the-tests-locally)
 3. In addition to reading the logs from the E2E test, you can download a video recording from the Artifacts section of the GitHub job that may have additional useful information.
 4. Check if any changes in your PR would require corresponding changes to `.native.js` versions of files.
 5. Lastly, if you're stuck on a failing mobile test, feel free to reach out to contributors on Slack in the #mobile or #core-editor chats in the WordPress Core Slack, [free to join](https://make.wordpress.org/chat/).

docs/contributors/code/testing-overview.md

@@ -23,15 +23,15 @@ Tests for JavaScript use [Jest](https://jestjs.io/) as the test runner and its A
 
 It should be noted that in the past, React components were unit tested with [Enzyme](https://github.com/airbnb/enzyme). However, for new tests, it is preferred to use React Testing Library (RTL) and over time old tests should be refactored to use RTL too (typically when working on code that touches an old test).
 
-Assuming you've followed the [instructions](/docs/contributors/code/getting-started.md) to install Node and project dependencies, tests can be run from the command-line with NPM:
+Assuming you've followed the [instructions](/docs/contributors/code/getting-started-with-code-contribution.md) to install Node and project dependencies, tests can be run from the command-line with NPM:
 
 ```
 npm test
 ```
 
 Linting is static code analysis used to enforce coding standards and to avoid potential errors. This project uses [ESLint](http://eslint.org/) and [TypeScript's JavaScript type-checking](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html) to capture these issues. While the above `npm test` will execute both unit tests and code linting, code linting can be verified independently by running `npm run lint`. Some JavaScript issues can be fixed automatically by running `npm run lint-js:fix`.
 
-To improve your developer workflow, you should setup an editor linting integration. See the [getting started documentation](/docs/contributors/code/getting-started.md) for additional information.
+To improve your developer workflow, you should setup an editor linting integration. See the [getting started documentation](/docs/contributors/code/getting-started-with-code-contribution.md) for additional information.
 
 To run unit tests only, without the linter, use `npm run test-unit` instead.
 
@@ -386,7 +386,7 @@ Contributors to Gutenberg will note that PRs include continuous integration E2E
 
 End-to-end tests use [Puppeteer](https://github.com/puppeteer/puppeteer) as a headless Chromium driver, and are otherwise still run by a [Jest](https://jestjs.io/) test runner.
 
-If you're using the built-in [local environment](/docs/contributors/code/getting-started.md#local-environment), you can run the e2e tests locally using this command:
+If you're using the built-in [local environment](/docs/contributors/code/getting-started-with-code-contribution.md#local-environment), you can run the e2e tests locally using this command:
 
 ```bash
 npm run test-e2e
@@ -454,7 +454,7 @@ Every core block is required to have at least one set of fixture files for its m
 
 ## PHP Testing
 
-Tests for PHP use [PHPUnit](https://phpunit.de/) as the testing framework. If you're using the built-in [local environment](/docs/contributors/code/getting-started.md#local-environment), you can run the PHP tests locally using this command:
+Tests for PHP use [PHPUnit](https://phpunit.de/) as the testing framework. If you're using the built-in [local environment](/docs/contributors/code/getting-started-with-code-contribution.md#local-environment), you can run the PHP tests locally using this command:
 
 ```bash
 npm run test-php

docs/contributors/documentation/documentation.md

@@ -96,7 +96,7 @@ The preferred format for code examples is ESNext, this should be the default vie
 
 ### Editor Config
 
-You should configure your editor to use Prettier to auto-format markdown documents. See the [Getting Started documentation](/docs/contributors/code/getting-started.md) for complete details.
+You should configure your editor to use Prettier to auto-format markdown documents. See the [Getting Started documentation](/docs/contributors/code/getting-started-with-code-contribution.md) for complete details.
 
 An example config for using Visual Studio Code and the Prettier extensions:
 

docs/getting-started/tutorials/devenv/README.md

@@ -1,6 +1,6 @@
 # Development Environment
 
-This guide is for setting up your local environment for JavaScript development for creating plugins and tools to extend WordPress and the block editor. If you are looking to contribute to Gutenberg project itself, see additional documentation in the [Getting Started guide](/docs/contributors/code/getting-started.md).
+This guide is for setting up your local environment for JavaScript development for creating plugins and tools to extend WordPress and the block editor. If you are looking to contribute to Gutenberg project itself, see additional documentation in the [Getting Started guide](/docs/contributors/code/getting-started-with-code-contribution.md).
 
 A development environment is a catch-all term for what you need setup on your computer to work. The three main pieces needed for our development environment are:
 

docs/how-to-guides/javascript/js-build-setup.md

@@ -4,7 +4,7 @@ ESNext is JavaScript written using syntax and features only available in a versi
 
 See the [ESNext syntax documentation](/docs/how-to-guides/javascript/esnext-js.md) for explanation and examples about common code differences between standard JavaScript and ESNext.
 
-Let's set up your development environment to use these syntaxes, we'll cover development for your plugin to work with the Gutenberg project (ie: the block editor). If you want to develop on Gutenberg itself, see the [Getting Started](/docs/contributors/code/getting-started.md) documentation.
+Let's set up your development environment to use these syntaxes, we'll cover development for your plugin to work with the Gutenberg project (ie: the block editor). If you want to develop on Gutenberg itself, see the [Getting Started](/docs/contributors/code/getting-started-with-code-contribution.md) documentation.
 
 Browsers cannot interpret or run ESNext and JSX syntaxes, so we must use a transformation step to convert these syntaxes to code that browsers can understand.
 

docs/manifest.json

@@ -1764,9 +1764,9 @@
 		"parent": "contributors"
 	},
 	{
-		"title": "Getting Started",
-		"slug": "getting-started",
-		"markdown_source": "../docs/contributors/code/getting-started.md",
+		"title": "Getting Started With Code Contribution",
+		"slug": "getting-started-with-code-contribution",
+		"markdown_source": "../docs/contributors/code/getting-started-with-code-contribution.md",
 		"parent": "code"
 	},
 	{

docs/toc.json

@@ -148,7 +148,7 @@
     ] },
     { "docs/contributors/README.md": [
         { "docs/contributors/code/code.md": [
-            { "docs/contributors/code/getting-started.md": [] },
+            { "docs/contributors/code/getting-started-with-code-contribution.md": [] },
             { "docs/contributors/code/git-workflow.md": [] },
             { "docs/contributors/code/coding-guidelines.md": [] },
             { "docs/contributors/code/testing-overview.md": [] },