diff --git a/doc/guides/modules-in-core.md b/doc/guides/modules-in-core.md
new file mode 100644
index 00000000000000..6cb29bbaaafd6e
--- /dev/null
+++ b/doc/guides/modules-in-core.md
@@ -0,0 +1,44 @@
+# To be or not to be in core
+
+Should a module be in core? This question arises every so often. This document
+explains things to consider when deciding whether a module should be in core or
+not.
+
+## Strong arguments for including a module in core
+
+1. The module provides functionality that is standardized (such as a
+   [Web API][]) and overlaps with existing functionality.
+2. The module can only be implemented in core.
+3. The module can only be implemented in a performant way in core.
+4. Developer experience is significantly improved if the module is in core.
+5. The module will be widely used, have cross platform native code, and being in
+   core will avoid the need for an end-user compilation chain.
+6. Part or all of the module will also be re-used or duplicated in core.
+
+## Strong arguments against including a module in core
+
+1. None of the arguments list in the previous section apply.
+
+## Benefits and challenges
+
+When it is unclear whether a module should be included in core, it might be
+helpful to consider these additional factors.
+
+### Benefits
+
+1. The module will receive more frequent testing with Node.js CI and CITGM.
+2. The module will be integrated into the LTS workflow.
+3. Documentation will be integrated with core.
+4. There is no dependency on npm.
+
+### Challenges
+
+1. Inclusion in core is likely to reduce code merging velocity as the Node.js
+   process for code review and merging is more time-consuming than that of most
+   individual modules.
+2. By being bound to the Node.js release cycle, it is harder and slower to
+   publish patches.
+3. Less flexibility for end users. They can't update the module when they choose
+   without also updating Node.js.
+
+[Web API]: https://developer.mozilla.org/en-US/docs/Web/API