doc: add experimental modules review policy

Signed-off-by: Paolo Insogna <paolo@cowtech.it>

Author: ShogunPanda

doc/api/documentation.md

@@ -47,6 +47,16 @@ The stability indexes are as follows:
 >
 > Experimental features leave the experimental status typically either by
 > graduating to stable, or are removed without a deprecation cycle.
+>
+> As part of the major-release experimental module review process,
+> collaborators who introduce experimental modules are expected to take
+> ownership and help bring each experiment to a conclusion: either promotion
+> to stable or removal.
+>
+> If an experimental feature has reached mainstream adoption such that breaking
+> changes are not realistically possible without ecosystem breakage, it should
+> be considered stable in the next experimental module review issue, regardless
+> of development status or author intent.
 
 <!-- separator -->
 

doc/contributing/collaborator-guide.md

@@ -462,6 +462,9 @@ For pull requests introducing new core modules:
 * Land only after sign-off from at least two TSC voting members.
 * Land with a [Stability Index][] of Experimental. The module must remain
   Experimental until a semver-major release.
+* Introducing an Experimental module means taking ownership of the experiment
+  and participating in the major-release experimental module review process
+  until the module is either promoted to Stable or removed.
 
 ### Introducing new APIs on the global scope
 

doc/contributing/releases.md

@@ -1283,6 +1283,35 @@ The release date for the next major release should be announced immediately
 following the current release (e.g. the release date for 13.0.0 should be
 announced immediately following the release of 12.0.0).
 
+### Experimental module review
+
+Approximately one month before cutting a new major release, releasers must
+open an issue asking collaborators involved with experimental modules to review
+their status and propose updates.
+
+Releasers are not required to make module-status decisions themselves.
+
+That issue should include an explicit list of all experimental modules, and
+should also explicitly mention a collaborator for each module when possible.
+
+The discussion should identify:
+
+* Modules that should be promoted to stable.
+* Modules that should have their experimental stage changed.
+* Modules that should be removed from the codebase.
+
+The issue is for discussion only and should not itself be turned into a pull
+request. Once decisions are made, the issue must be closed.
+
+The final comment before closing should summarize, for each module:
+
+1. Whether a change will be made.
+2. The reason for the change, or the reason for no change.
+3. An implementing pull request, if one exists.
+
+The issue should link the same purpose issue created for the previous major release
+so that modules status comparison is simplified.
+
 ### Release branch
 
 Approximately two months before a major release, new `vN.x` and