diff --git a/docs/contributors/code/how-to-get-your-pull-request-reviewed.md b/docs/contributors/code/how-to-get-your-pull-request-reviewed.md
new file mode 100644
index 00000000000000..91984c38117dff
--- /dev/null
+++ b/docs/contributors/code/how-to-get-your-pull-request-reviewed.md
@@ -0,0 +1,83 @@
+# How To Get Your Pull Request Reviewed?
+
+Sometimes we publish a Pull Request and no one [reviews](/docs/contributors/repository-management.md#code-review) our work. What to do?
+
+Attracting a review largely isn't about the code – it is about making the reviewing easy.
+
+If you published a Pull Request that isn't getting any comments or reviews, try one of the strategies used by core contributors:
+
+## Create the smallest reasonable PRs
+
+Approving a 2000-line-long PR takes months and feels overwhelming.
+
+Approving a 50-line long PR takes days or hours and feels easy.
+
+Large batches slow you down. Ship your work in small chunks to merge more and learn faster.
+
+## Share relevant context:
+
+Clarify:
+* What problem are you solving?
+* How does your PR solve it?
+* What feedback do you need?
+* What’s out of scope?
+* What’s unintuitive?
+* How to test?
+
+Summarize any related issues and PRs.
+
+It's easier than asking others to go and figure it out.
+
+## Make your PR exciting
+
+All contributions are competing for attention. Make your stand out.
+
+The easiest way? Say why it matters:
+
+❌ A new react hook to get data
+✅ `useEntityRecord`: get data with 10x less boilerplate
+
+Then prove it with code examples, visuals, and screencasts.
+
+## Show your work
+
+Post a link to your PR in related issues & PRs.
+
+Ping commenters of related issues, previous committers, and tech leads.
+
+Bring it up on the #core-editor channel of the WordPress.org slack. The easiest way to get feedback is to speak out during the [open floor section](https://make.wordpress.org/core/tag/core-editor-agenda/) of the weekly [Core Editor meeting](/docs/getting-started/README.md).
+
+Assign relevant labels, milestones, and projects (or ask someone).
+
+## Review the work of others
+
+It’s the easiest way to get on others’ radar.
+
+Look up the PRs of commenters of related issues, previous committers, and tech leads. Then review them.
+
+Is their work unfamiliar? Do:
+
+* Take some time to understand it
+* Propose a pair programming session
+* Skip, go for the next PR
+
+## Reduce risk with clarity
+
+Risk adds friction – an approval can backfire later.
+
+Clarity is like grease. Clearly document:
+
+* What risks are involved? Why take them?
+* Why is this PR the best solution?
+* How can the risk be minimized?
+* What else has been tried?
+
+## Follow the attention
+
+Some PRs naturally get more traction than others.
+
+Double down on these.
+
+Some Issues are more topical than others (e.g. those listed in the goals for an upcoming release) and thus will garner more attention. By focusing on these it will be easier to attract reviewers.
+
+How to get there quickly? Help with an active project from the WordPress roadmap
diff --git a/docs/contributors/repository-management.md b/docs/contributors/repository-management.md
index 2b326f8767e8c0..9bce2d06fd1566 100644
--- a/docs/contributors/repository-management.md
+++ b/docs/contributors/repository-management.md
@@ -13,6 +13,7 @@ This document covers:
     -   [Design Review](#design-review)
     -   [Merging Pull Requests](#merging-pull-requests)
     -   [Closing Pull Requests](#closing-pull-requests)
+    -   [How To Get Your Pull Request Reviewed?](/docs/contributors/code/how-to-get-your-pull-request-reviewed.md)
 -   [Projects](#projects)
 
 ## Issues
@@ -103,6 +104,8 @@ Code reviews are encouraged by everyone who is willing to attempt one. If you re
 
 If you are not yet comfortable leaving a full review, try commenting on a PR. Questions about functionality or the reasoning behind a change are helpful too. You could also comment on changes to parts of the code you understand, without leaving a full review.
 
+If you struggle with getting a review, see: [How To Get Your Pull Request Reviewed?](/docs/contributors/code/how-to-get-your-pull-request-reviewed.md)
+
 ### Design Review
 
 If your pull request impacts the design/UI, you need to label appropriately to alert design. To request a design review, add the [Needs Design Feedback](https://github.com/WordPress/gutenberg/labels/Needs%20Design%20Feedback) label to your PR. If there are any PRs that require an update to the design/UI, please use the [Figma Library Update](https://github.com/WordPress/gutenberg/labels/Figma%20Library%20Update) label.
diff --git a/docs/manifest.json b/docs/manifest.json
index 9af856642476ff..7ae12e9743f003 100644
--- a/docs/manifest.json
+++ b/docs/manifest.json
@@ -2099,6 +2099,12 @@
 		"markdown_source": "../docs/contributors/code/deprecations.md",
 		"parent": "code"
 	},
+	{
+		"title": "How To Get Your Pull Request Reviewed?",
+		"slug": "how-to-get-your-pull-request-reviewed",
+		"markdown_source": "../docs/contributors/code/how-to-get-your-pull-request-reviewed.md",
+		"parent": "code"
+	},
 	{
 		"title": "Design Contributions",
 		"slug": "design",
diff --git a/docs/toc.json b/docs/toc.json
index 5f5ee4a992fe5e..8f3b669a281c5a 100644
--- a/docs/toc.json
+++ b/docs/toc.json
@@ -317,7 +317,8 @@
 						]
 					},
 					{ "docs/contributors/code/backward-compatibility.md": [] },
-					{ "docs/contributors/code/deprecations.md": [] }
+					{ "docs/contributors/code/deprecations.md": [] },
+					{ "docs/contributors/code/how-to-get-your-pull-request-reviewed.md": [] }
 				]
 			},
 			{