WordPress · JustinyAhin · Mar 9, 2021 · Feb 2, 2021 · Feb 2, 2021 · Feb 2, 2021
@@ -22,19 +22,19 @@ The Editor offers rich new value to users with visual, drag-and-drop creation to
 
 ### Create a Block Tutorial
 
-[Learn how to create your first block](/docs/designers-developers/developers/tutorials/create-block/readme.md) for the WordPress block editor. From setting up your development environment, tools, and getting comfortable with the new development model, this tutorial covers all what you need to know to get started with the block editor.
+[Learn how to create your first block](/docs/getting-started/tutorials/create-block/readme.md) for the WordPress block editor. From setting up your development environment, tools, and getting comfortable with the new development model, this tutorial covers all what you need to know to get started with the block editor.
 
 ### Develop for the block editor
 
-Whether you want to extend the functionality of the block editor, or create a plugin based on it, [see the developer documentation](/docs/designers-developers/developers/README.md) to find all the information about the basic concepts you need to get started, the block editor APIs and its architecture.
+Whether you want to extend the functionality of the block editor, or create a plugin based on it, [see the developer documentation](/docs/how-to-guides/README.md) to find all the information about the basic concepts you need to get started, the block editor APIs and its architecture.
 
 - [Gutenberg Architecture](/docs/architecture/readme.md)
-- [Block Style Variations](/docs/designers-developers/developers/filters/block-filters.md#block-style-variations)
-- [Creating Block Patterns](/docs/designers-developers/developers/block-api/block-patterns.md)
-- [Theming for the Block Editor](/docs/designers-developers/developers/themes/readme.md)
-- [Block API Reference](/docs/designers-developers/developers/block-api/readme.md)
-- [Block Editor Accessibility](/docs/designers-developers/developers/accessibility.md)
-- [Internationalization](/docs/designers-developers/developers/internationalization.md)
+- [Block Style Variations](/docs/reference-guides/filters/block-filters.md#block-style-variations)
+- [Creating Block Patterns](/docs/reference-guides/block-api/block-patterns.md)
+- [Theming for the Block Editor](/docs/how-to-guides/themes/readme.md)
+- [Block API Reference](/docs/reference-guides/block-api/readme.md)
+- [Block Editor Accessibility](/docs/reference-guides/accessibility.md)
+- [Internationalization](/docs/how-to-guides/internationalization.md)
 
 ### Contribute to the block editor
 

@@ -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/getting-started.md).
+Make sure you have set up your local environment following the instructions on [Getting Started](/docs/contributors/code/getting-started.md).
 
 ## Keyboard Testing
 

@@ -220,7 +220,7 @@ It is preferred to implement all components as [function components](https://rea
 
 ## JavaScript Documentation using JSDoc
 
-Gutenberg follows the [WordPress JavaScript Documentation Standards](https://make.wordpress.org/core/handbook/best-practices/inline-documentation-standards/javascript/), with additional guidelines relevant for its distinct use of [import semantics](/docs/contributors/coding-guidelines.md#imports) in organizing files, the [use of TypeScript tooling](/docs/contributors/testing-overview.md#javascript-testing) for types validation, and automated documentation generation using [`@wordpress/docgen`](https://github.com/WordPress/gutenberg/tree/HEAD/packages/docgen).
+Gutenberg follows the [WordPress JavaScript Documentation Standards](https://make.wordpress.org/core/handbook/best-practices/inline-documentation-standards/javascript/), with additional guidelines relevant for its distinct use of [import semantics](/docs/contributors/code/coding-guidelines.md#imports) in organizing files, the [use of TypeScript tooling](/docs/contributors/code/testing-overview.md#javascript-testing) for types validation, and automated documentation generation using [`@wordpress/docgen`](https://github.com/WordPress/gutenberg/tree/HEAD/packages/docgen).
 
 For additional guidance, consult the following resources:
 
@@ -266,7 +266,7 @@ Note the use of quotes when defining a set of string literals. As in the [JavaSc
 
 Use the [TypeScript `import` function](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html#import-types) to import type declarations from other files or third-party dependencies.
 
-Since an imported type declaration can occupy an excess of the available line length and become verbose when referenced multiple times, you are encouraged to create an alias of the external type using a `@typedef` declaration at the top of the file, immediately following [the `import` groupings](/docs/contributors/coding-guidelines.md#imports).
+Since an imported type declaration can occupy an excess of the available line length and become verbose when referenced multiple times, you are encouraged to create an alias of the external type using a `@typedef` declaration at the top of the file, immediately following [the `import` groupings](/docs/contributors/code/coding-guidelines.md#imports).
 
 ```js
 /** @typedef {import('@wordpress/data').WPDataRegistry} WPDataRegistry */
@@ -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/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.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`.
@@ -16,11 +16,11 @@ Browse [the issues list](https://github.com/wordpress/gutenberg/issues) to find
 
 ## Contributor Resources
 
-* [Getting Started](/docs/contributors/getting-started.md) documents getting your development environment setup, this includes your test site and developer tools suggestions.
-* [Git Workflow](/docs/contributors/git-workflow.md) documents the git process for deploying changes using pull requests.
-* [Coding Guidelines](/docs/contributors/coding-guidelines.md) outline additional patterns and conventions used in the Gutenberg project.
-* [Testing Overview](/docs/contributors/testing-overview.md) for PHP and JavaScript development in Gutenberg.
+* [Getting Started](/docs/contributors/code/getting-started.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.
 * [Accessibility Testing](/docs/contributors/accessibility-testing.md) documents the process of testing accessibility in Gutenberg.
-* [Managing Packages](/docs/contributors/managing-packages.md) documents the process for managing the npm packages.
-* [Gutenberg Release Process](/docs/contributors/release.md) - a checklist for the different types of releases for the Gutenberg project.
-* [React Native mobile Gutenberg](/docs/contributors/native-mobile.md) - a guide on the React Native based mobile Gutenberg editor.
+* [Managing Packages](/docs/contributors/code/managing-packages.md) documents the process for managing the npm packages.
+* [Gutenberg Release Process](/docs/contributors/code/release.md) - a checklist for the different types of releases for the Gutenberg project.
+* [React Native mobile Gutenberg](/docs/contributors/code/native-mobile.md) - a guide on the React Native based mobile Gutenberg editor.
@@ -1,12 +1,12 @@
 # Getting Started
 
-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/designers-developers/developers/tutorials/devenv/readme.md) for additional setup information.
+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.
 
 ## Development Tools (Node)
 
 Gutenberg is a JavaScript project and requires [Node.js](https://nodejs.org/). The project is built using the latest active LTS release of node, and the latest version of NPM. See the [LTS release schedule](https://github.com/nodejs/Release#release-schedule) for details.
 
-We recommend using the [Node Version Manager](https://github.com/nvm-sh/nvm) (nvm) since it is the easiest way to install and manage node for macOS, Linux, and Windows 10 using WSL2. See [our Development Tools guide](/docs/designers-developers/developers/tutorials/devenv/readme.md#development-tools) or the Nodejs site for additional installation instructions.
+We recommend using the [Node Version Manager](https://github.com/nvm-sh/nvm) (nvm) since it is the easiest way to install and manage node for macOS, Linux, and Windows 10 using WSL2. See [our Development Tools guide](/docs/getting-started/tutorials/devenv/readme.md#development-tools) or the Nodejs site for additional installation instructions.
 
 After installing Node, you can build Gutenberg by running the following from within the cloned repository:
 
@@ -34,7 +34,7 @@ The [wp-env package](/packages/env/README.md) was developed with the Gutenberg p
 
 By default, `wp-env` can run in a plugin directory to create and run a WordPress environment, mounting and activating the plugin automatically. You can also configure `wp-env` to use existing installs, multiple plugins, or themes. See the [wp-env package](/packages/env/README.md#wp-envjson) for complete documentation.
 
-If you don't already have it, you'll need to install Docker and Docker Compose in order to use `wp-env`. See the [Development Environment tutorial for additional details](/docs/designers-developers/developers/tutorials/devenv/readme.md).
+If you don't already have it, you'll need to install Docker and Docker Compose in order to use `wp-env`. See the [Development Environment tutorial for additional details](/docs/getting-started/tutorials/devenv/readme.md).
 
 Once Docker is installed and running: To install WordPress, run the following from within the cloned gutenberg directory:
 

@@ -49,7 +49,7 @@ This will create a directory called `gutenberg` with all the files for the proje
 git switch -c update/my-branch
 ```
 
-**Step 4**: Make the code changes. Build, confirm, and test your change thoroughly. See [coding guidelines](/docs/contributors/coding-guidelines.md) and [testing overview](/docs/contributors/testing-overview.md) for guidance.
+**Step 4**: Make the code changes. Build, confirm, and test your change thoroughly. See [coding guidelines](/docs/contributors/code/coding-guidelines.md) and [testing overview](/docs/contributors/code/testing-overview.md) for guidance.
 
 **Step 5**: Commit your change with a [good commit message](https://make.wordpress.org/core/handbook/best-practices/commit-messages/). This will commit your change to your local copy of the repository.
 

@@ -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/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-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,11 +21,11 @@ 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/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-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/).
 
 ## Debugging the native mobile unit tests
 
-Follow the instructions in [Native mobile testing](/docs/contributors/testing-overview.md#native-mobile-testing) to locally debug the native mobile unit tests when needed.
+Follow the instructions in [Native mobile testing](/docs/contributors/code/testing-overview.md#native-mobile-testing) to locally debug the native mobile unit tests when needed.
@@ -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/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.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/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.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/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.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/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.md#local-environment), you can run the PHP tests locally using this command:
 
 ```bash
 npm run test-php

@@ -1,9 +1,9 @@
 # Reference
 
--   [Glossary](/docs/designers-developers/glossary.md)
--   [Coding Guidelines](/docs/contributors/coding-guidelines.md)
--   [Testing Overview](/docs/contributors/testing-overview.md)
--   [Frequently Asked Questions](/docs/designers-developers/faq.md)
+-   [Glossary](/docs/getting-started/glossary.md)
+-   [Coding Guidelines](/docs/contributors/code/coding-guidelines.md)
+-   [Testing Overview](/docs/contributors/code/testing-overview.md)
+-   [Frequently Asked Questions](/docs/getting-started/faq.md)
 
 ## Logo
 
@@ -15,4 +15,4 @@ Released under GPL license, made by [Cristel Rossignol](https://twitter.com/cris
 
 ## Mockups
 
-Mockup Sketch files are available in [the Design section](/docs/designers-developers/designers/design-resources.md).
+Mockup Sketch files are available in [the Design section](/docs/how-to-guides/designers/design-resources.md).