オリジナルドキュメントの更新

.gitignore

@@ -0,0 +1,2 @@
+# Node.js
+node_modules/

core/about/communication.md

@@ -16,6 +16,7 @@
 *   [make/docs](https://make.wordpress.org/docs/): The blog for the documentation team.
 *   [make/meta](https://make.wordpress.org/meta/): The blog for the developers of the WordPress.org website.
 *   [make/mobile](https://make.wordpress.org/mobile/): The blog for all things mobile (iOS/Android).
+*   [make/performance](https://make.wordpress.org/performance/): The blog for all things performance-related.
 *   [make/plugins](https://make.wordpress.org/plugins/): The blog for plugin developers.
 *   [make/polyglots](https://make.wordpress.org/polyglots/): The blog for translators.
 *   [make/support](https://make.wordpress.org/support/): The blog for the support team (forums, IRC, etc).

core/about/getting-started-at-a-contributor-day.md

@@ -101,21 +101,27 @@ Some easy tasks for a first time contributor to get started at a contributor day
 
 If you are unsure if you are on the latest npm version, run the following command:
 
+```bash
  npm install npm@latest -g 
+```
 
 *    Docker – https://docs.docker.com/install/
 
 A handy guide to setting up your local environment can be found in [**Contributing.md**](https://github.com/WordPress/gutenberg/blob/master/CONTRIBUTING.md) in the Gutenberg github repository. There you will find commands to help get your local environment up and running.  
 
 Largely, the setup process can be finished end to end by running the following command from the Gutenberg directory (Powershell works well if you are on Windows.):
 
+```bash
 ./bin/setup-local-env.sh
+```
 
 The script will go step by step through the process of validating prerequisites are met. If there is something missing, the script will report what needs to be done to complete the setup. Re running the script a few times after making the suggested changes will complete setup.  
 
 Once you have the development version of Gutenberg running on your local environment you will need to run the following from within the Gutenberg directory:
 
+```bash
 npm run dev
+```
 
 This will monitor/update changes you make.  
 
@@ -133,7 +139,9 @@ If you are looking for some unassigned first issues to get familiar with contrib
 4.  Make an initial commit 
 5.  Publish your branch using: 
 
+```bash
 git push -u origin <branch name>
+```
 
 Now you are ready to make your changes locally to fix the issue. When finished, commit your changes and push them to your branch.  
 

core/about/release-cycle/block-editor-release-process-for-major-releases.md

@@ -7,7 +7,7 @@ This guide will clarify how to handle the block editor portion of a major WordPr
 *   **Timeline planner:** this involves mapping out key milestones for the editor release squad to be aware of, making sure Gutenberg releases line up well, and helping remind/wrangle work around those dates. 
 *   **Project Board Manager:** this includes setting up the board, adding automations, keeping the board up to date with priority issues, triage of incoming GitHub issues, and reporting to teams any major blockers. 
 *   **Release Wrangler:** this role involves managing the actual packaging of the release and working with the wider release squad. 
-*   **Communication Wrangler:** this includes helping wrangle dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase., attending meetings to share important information, and reporting back updates to the release squad. 
+*   **Communication Wrangler:** this includes helping wrangle dev notes, attending meetings to share important information, and reporting back updates to the release squad. 
 
 ## Quick Reference Timeline
 
@@ -148,36 +148,37 @@ Generally speaking, the process is as follows:
 
 To get started, here’s a script to use to begin auditing the experimental APIs:
 
+```
 ( () => {
 	const reportExperimental = (
 		objectToReport = window.wp,
 		returnObject = {},
-		path = \[\],
+		path = [],
 		depth = 0
 	) => {
-		const MAXIMUM\_DEPTH\_TO\_SEARCH = 6;
+		const MAXIMUM_DEPTH_TO_SEARCH = 6;
 		const { lodash } = window;
 		if (
-			depth > MAXIMUM\_DEPTH\_TO\_SEARCH ||
+			depth > MAXIMUM_DEPTH_TO_SEARCH ||
 			! lodash.isObject( objectToReport )
 		) {
 			return;
 		}
 		for ( const key of Object.keys( objectToReport ) ) {
 			if (
-				key.startsWith( '\_\_experimental' ) ||
-				key.startsWith( '\_\_unstable' )
+				key.startsWith( '__experimental' ) ||
+				key.startsWith( '__unstable' )
 			) {
 				lodash.set(
 					returnObject,
-					\[ ...path, key \],
-					typeof objectToReport\[ key \]
+					[ ...path, key ],
+					typeof objectToReport[ key ]
 				);
 			}
 			reportExperimental(
-				objectToReport\[ key \],
+				objectToReport[ key ],
 				returnObject,
-				\[ ...path, key \],
+				[ ...path, key ],
 				depth + 1
 			);
 		}
@@ -186,6 +187,8 @@ To get started, here’s a script to use to begin auditing the experimental APIs
 	return reportExperimental();
 } )();
 
+```
+
 This script takes advantage of the fact that most of the block editor API’s are exposed as part of the wp global and recursively iterates on that variable, trying to find experimental keys in the object. This report allows you to see some experimental Actions, Selectors, Components, Functions, and some settings. However, this script does not cover experimental props in components or experimental flags in settings objects. For those aspects, you’ll need to search the codebase and talk with those familiar enough with the code to know what is likely still experimental. If you don’t know where to start, it’s recommended that you ask in the next [#core-editor](https://make.wordpress.org/core/tag/core-editor/) meeting. 
 
 With the information from the report and any information manually collected, it can help to then group related experimental APIs to get a sense of what’s in place currently. From there, use git blame to know who was involved in each API in order to ping them. You can then create a new overview issue in GitHub that lists out a checkbox for each API where one can see at a glance the status of whether a decision has been made around the API being stabilized or not. 
@@ -209,7 +212,7 @@ If you have gone through the process of deciding which features to include in th
 
 **Planning and Writing Dev Notes**
 
-*For more context on Dev Notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. best practices, check out* [*this handbook page*](https://make.wordpress.org/core/handbook/tutorials/writing-developer-notes/)*.*
+*For more context on Dev Note best practices, check out* [*this handbook page*](https://make.wordpress.org/core/handbook/tutorials/writing-developer-notes/)*.*
 
 In order to know what needs a Dev Note, you can check all PRs [labeled with  “Needs Dev Note”.](https://github.com/WordPress/gutenberg/issues?q=label%3A%22Needs+Dev+Note%22.) You might find that there are more PRs than you can feasible write individual posts for without overwhelming the community with information. The best thing to do if you find too many PRs with that label is to group related changes and propose a dev note for each group.
 

core/about/release-cycle/preparing-the-about-page.md

@@ -18,7 +18,7 @@ If you want to create a page like this, here are the steps to follow:
         *   Check-in with release leads about headline features
         *   Check-in with any feature leads if you’re unclear about details
         *   Go through Beta posts on /news/ to populate features and find copy inspiration
-        *   Go through dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. on make/core to populate developer happiness section
+        *   Go through dev notes on make/core to populate developer happiness section
         *   Make sure to go through the features of Gutenberg and create a section to call it out with “new editor feature this release.”
     *   Create images — could be illustrations, icons, or screenshots
     *   Finalize copy (after release lead last review)

core/about/release-cycle/releasing-minor-versions.md

@@ -38,7 +38,7 @@ Ideally, all patches land at least 48 hours before release and a release candida
 
 Regardless of which kind of release you’re planning, there are a number of things you need to do.
 
-*   Check for breaking changes that would require a dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.. Ensure that those are published ahead of the release and tagged with the minor release number, related major release number, and the dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. tag (e.g., “4.9, 4.9.2, dev notes”).
+*   Check for breaking changes that would require a dev note. Ensure that those are published ahead of the release and tagged with the minor release number, related major release number, and the dev notes tag (e.g., “4.9, 4.9.2, dev notes”).
 *   Notify the Akismet team a few days ahead of time. If they have a plugin release coming soon, it’s good for us to be able to include an updated version, so users aren’t being prompted to updated Akismet as soon as they install WordPress. [Here’s an example](https://build.trac.wordpress.org/changeset/38478) of a commit to build.svn that bumps the Akismet external to the latest version.
 *   Ask a member of the Security team to run the private security unit test suite, to make sure no regressions are introduced. If any are found, avoid discussing the details publicly, because some sites (like wordpress.org) run `trunk` or beta/RCs in production. Instead, notify the Security team privately.
 *   You’ll want to notify hosts that a release is coming a couple of days ahead of time. Three days is the recommended time frame, but is not always possible depending on release timeline. The security team can assist you with the message to hosts. This message **should not go out until all security patches are ready** (if a security release).
@@ -54,7 +54,7 @@ Now that you’ve done all of that, it’s on to release day.
 
 You’ve made it. Release day can be stressful. The best way to survive release day is to *stay calm*. Things will go wrong. It’s okay, just regroup and keep moving forward. Here’s a list of things that need to get done on release day:
 
-*   The relevant credits file needs to be updated to list any new contributors. That files lives [in the meta repository](https://meta.trac.wordpress.org/browser/sites/trunk/api.wordpress.org/public_html/core/credits).
+*   The relevant credits file needs to be updated to list any new contributors. That file lives [in the meta repository](https://meta.trac.wordpress.org/browser/sites/trunk/api.wordpress.org/public_html/core/credits).
 *   If you’re running a security release, security patches need to be committed to all relevant branches.
 *   Once any security patches are committed, move the release process to the [#core](https://make.wordpress.org/core/tag/core/) channel.
     *   start by making an announcement (using the `/here` Slack command) welcoming people to the release party
@@ -91,69 +91,23 @@ You’ve made it. Release day can be stressful. The best way to survive release
 
 Assuming you’re following the instructions above and have an ideal schedule (all the time in the world), you’ll want to use the following schedule:
 
-**When?**
-
-**What?**
-
-T-7:00:00
-
-Triage all [targeted tickets](https://core.trac.wordpress.org/tickets/minor).
-
-T-5:00:00
-
-All security patches created, tested, and cleared by the WordPress Security team.
-
-T-4:00:00
-
-Commit all non-security patches to the relevant branch(es).
-
-T-4:00:00
-
-Run the private security unit test suite
-
-T-3:00:00
-
-Notify hosts that a release is coming.
-
-T-1:00:00
-
-Create the WordPress.org/news/ blog post (as draft).
-
-T-0:12:00
-
-If there are security fixes, lower the TTL in the `version-check` API to 60 minutes. (`WP_CORE_SHORT_API_TTL_VERSION` constant in `version.php`.)
-
-T-0:05:00
-
-Commit security patches and run unit tests and security tests.
-
-T-0:00:31
-
-Version bumps on all relevant branches.
-
-T-0:00:30
-
-Build the release package in mission control. Test package and manually test updates.
-
-T-0:00:00
-
-Turn on autoupdates. (`WP_CORE_LATEST_RELEASE` constant, and the `wporg_get_versions()` and `wporg_get_version_equivalents()` functions in `version.php`.)
-
-T+0:00:01
-
-Post the WordPress.org/news/ blog post.
-
-T+0:00:15
-
-Update credits (before or after release).
-
-T+0:01:00
-
-Autoupdates complete (for the most part).
-
-T+0:01:00
-
-Tag the releases. Many people run WordPress from SVN and need a tagged release to deploy.
+| **When?** | **What?** |
+| --- | --- |
+| T-7:00:00 | Triage all [targeted tickets](https://core.trac.wordpress.org/tickets/minor). |
+| T-5:00:00 | All security patches created, tested, and cleared by the WordPress Security team. |
+| T-4:00:00 | Commit all non-security patches to the relevant branch(es). |
+| T-4:00:00 | Run the private security unit test suite |
+| T-3:00:00 | Notify hosts that a release is coming. |
+| T-1:00:00 | Create the WordPress.org/news/ blog post (as draft). |
+| T-0:12:00 | If there are security fixes, lower the TTL in the `version-check` API to 60 minutes. (`WP_CORE_SHORT_API_TTL_VERSION` constant in `version.php`.) |
+| T-0:05:00 | Commit security patches and run unit tests and security tests. |
+| T-0:00:31 | Version bumps on all relevant branches. |
+| T-0:00:30 | Build the release package in mission control. Test package and manually test updates. |
+| T-0:00:00 | Turn on autoupdates. (`WP_CORE_LATEST_RELEASE` constant, and the `wporg_get_versions()` and `wporg_get_version_equivalents()` functions in `version.php`.) |
+| T+0:00:01 | Post the WordPress.org/news/ blog post. |
+| T+0:00:15 | Update credits (before or after release). |
+| T+0:01:00 | Autoupdates complete (for the most part). |
+| T+0:01:00 | Tag the releases. Many people run WordPress from SVN and need a tagged release to deploy. |
 
 ## Extras
 

core/about/release-cycle/wordpress-release-team-and-focus-leads.md

@@ -35,7 +35,7 @@ These are tasks and responsibilities that may be documented for specific roles b
 *   Communicating publicly as much as possible (on tickets, in component chats, Make/Core posts, etc.)
 *   Identifying blockers to progress and asking for help from buddies, team leads, and/or the Release Lead
 *   Being mindful of deadlines
-*   Identifying changes that require documentation, HelpHub articles, or communication to the community at large (through dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase., marketing, etc.)
+*   Identifying changes that require documentation, HelpHub articles, or communication to the community at large (through dev notes, marketing, etc.)
 *   Leading bug scrubs focused on your team’s tickets and tasks
 *   Facilitating and participating in inter-team discussions
 
@@ -96,7 +96,7 @@ These are tasks and responsibilities that may be documented for specific roles b
 *   Keep track of changes within the release that require dev notes
 *   Coordinate with the participants of those tickets with the best understanding of the changes (the committer, component maintainers, contributors owned a ticket, and lead the charge) to draft dev notes
 *   Ensure all dev notes are written with enough time to proofread, reviewed, and published prior to the field guide (which publishes at the same time as release candidate 1)
-*   If a ticket participant is not available to write a dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase., finding someone to write one, or writing one yourself
+*   If a ticket participant is not available to write a dev note, finding someone to write one, or writing one yourself
 *   Ensure any documentation pages required for new features are created before the release
 *   Write and publish the release changelog on HelpHub
 *   Update WordPress versions page on the Codex