diff --git a/release-management.mkd b/release-management.mkd
new file mode 100644
index 0000000000000000000000000000000000000000..c094d7f912806dd20a7145cbc45d2b0337d5ebb2
--- /dev/null
+++ b/release-management.mkd
@@ -0,0 +1,326 @@
+---
+title: GHC Release Management
+authors:
+ - Simon Peyton Jones
+ - Ben Gamari
+ - Andreas Klebinger
+ - Julian Ospald
+---
+
+These notes describe the policy for GHC's release processes,
+especially concerning the partnership between
+
+* "upstream producers": those producing GHC's releases (roughly: the GHC team), and
+* "downstream consumers": those consuming them (roughly: ghcup, library
+  authors, Stack team, Stackage, Linux distros including Nix, HLS, Cabal, Core
+  Libraries Committee).
+
+In order to understand where we can improve it is important
+to understand the areas where our downstream users struggle. We have started to
+collect some such reports from downstream stakeholders in [this
+document][pain-points]. Others are invited to add to this list.
+
+[pain-points]: https://docs.google.com/document/d/1JYYciVcSj34YyC07i_qnQyJ8PHXsA7VzdC2BC_cXB1k
+
+
+# 1. Motivation
+
+GHC is a complex artefact, so it is all too easy for upstream producers to
+produce releases that somehow fail to meet the expectations of downstream
+consumers. These mis-matched expectations can cause friction and aggravation,
+as well as extra work (sometimes a lot of it).
+
+Some of this is just hard: There is a lot to do across many facets of a complex
+project. However, the aim of this document
+is to avoid unnecessary friction, by promoting clarity, accurate and timely
+communication, and explicitly-articulated expectations.
+
+More specifically, we propose two significant changes:
+
+1. **Explicitly articulate a list of expectations (or invariants) about
+   releases**, things that upstream producers undertake to maintain, and on
+   which downstream consumers can rely.   See Section 2.  
+
+2. **Define a communications plan** that describes how the upstream team will
+   communicate with downstream consumers.  See Section 3.
+
+
+# 2. Expectations/invariants for GHC releases
+
+The goal of this section to is lay forth a set of technical invariants
+regarding GHC's distribution practices. 
+The general aim of this is to ensure that GHC build products are fit for
+consumption, without modification or augmentation by downstream distributors.
+
+Here we seek to precisely articulate the invariants that packagers and end-users
+can rely upon. These are offered as ideals
+to which both distributors and GHC developers both aspire. We recognize that
+not all of these ideals have been realized: while some we can guarantee today,
+others may be desireable but are not yet attainable. We will mark the latter with
+a (🔴) to indicate that help could be used in these areas.
+
+Regardless, by specifying these goals in concrete terms we hope to better prioritize
+work on GHC to improve the downstream experience. Moreover, this list can serve
+as a concrete list of items which can be tested in GHC and its release process,
+making these guarantees robust.
+
+In various places we will refer to the [GHCup][GHCup] distribution channel due
+to its wide adoption and close involvement with GHC upstream.
+
+[GHCup]: https://www.haskell.org/GHCup/
+
+
+## 2.1. Release artifacts
+
+* Alpha prereleases will be published for testing purposes in preparation for new major releases
+* Release candidates will be published for testing purposes prior to both major and minor releases;
+  a testing period of at least two weeks between the publication of a release
+  candidate and the final release will be provided
+* GHC will clearly document which platforms are supported by each release according to the
+  established [platform tier classification][platform-tiers]
+* Starting from a source distribution tarball, on all tier 1 platforms:
+
+  * GHC itself, including all of its boot libraries, must build to produce a functional compiler  
+  * The user’s guide, manual page (where applicable) and Haddock documentation
+    for GHC and boot libraries must build  
+  * No such guarantees are provided for Tier 2 or lower platforms  
+* Haddock documentation for GHC-maintained packages (e.g. `base`,
+  `template-haskell`, the `ghc` library, `ghc-internal`, `ghc-prim`) is
+  available on Hackage on the day of release and is fully functional.  
+* Binary distributions provided for tier 1 platforms consistently include a minimum set
+  of expected features. Specifically:  
+  * the compiler, `iserv`, `ghci`, `haddock`, `unlit`
+  * corresponding manual pages on platforms where these are supported
+  * HTML users guide
+  * Haddocks  
+  * profiling and vanilla libraries  
+  * Hadrian bootstrap sources for the latest minor GHC releases of the last three major release series
+
+  Note that certain characteristics of bindists are inherently different
+  between platforms (e.g. static vs dynamic linkage, `libffi`, `gmp`, `libc`
+  versions, etc). These attributes are not covered in the above.
+* Binary distributions should provide a stable interface for configuration and
+  installation (`configure`, `make`, `ghc-toolchain`)
+  (see [GHC #25669](https://gitlab.haskell.org/ghc/ghc/-/issues/25669)).
+  * For this to happen one needs to define the desired feature set (🔴), after
+    which tests can be added to ensure it is maintained.  
+  * The same is true for building from source. This requires that Hadrian features
+    be split into “stable” user facing and development workflow features
+    (🔴)
+* The testsuite distribution (i.e. `ghc-X.Y.Z-testsuite.tar`) passes across all
+  supported platforms and configurations (🔴)
+  (see [GHC #25670](https://gitlab.haskell.org/ghc/ghc/-/issues/25670)).
+
+The GHC and GHCup teams will take an active role in providing releases via GHCup:
+
+* Official GHC releases and prereleases will be made available by the release
+  manager via GHCup's `vanilla` and `prerelease` channels, respectively
+* The aspiration is that, for tier 1 platforms, a GHC release (shipped in the
+  GHCup `vanilla` channel) is of high enough quality to be a quality-assured
+  release (shipped in the GHCup `default` channel) without patches.  
+  * If a downstream should need to repackage of release artifacts they are
+    asked to consult with upstream such that the underlying issue can be
+    addressed
+  * When a downstream packager needs to repackage a release, the steps should
+    be documented, reproducible, and clearly visible to end-users such that
+    issues that may stem from the modifications can be readily identified by
+    upstream
+  * Binary distributions provided for non-tier-1 platforms should be clearly marked to users  
+
+[platform-tiers]: https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms
+
+
+## 2.2. Boot libraries and versioning
+
+GHC ships in its source and binary distributions a small set of libraries
+depended upon by the compiler.  These are the *boot libraries*; these are
+summarized on the [GHC wiki][library-versions].
+
+* The version of a boot library typically increase moving forward with time and
+  major GHC versions. That is:  
+
+  > `ghc-major(X) >= ghc-major(Y) && date(X) > date(y)` implies 
+  > `core-lib-versions(X) >= core-lib-versions(Y)`  
+
+* GHC HQ will not perform major version bumps of boot libraries in minor
+  compiler releases.
+
+* The GHC team will notify boot library maintainers of the library versions
+  planned to be included in an upcoming GHC release with a reasonable time 
+  window (2 to 3 weeks) for the maintainer to recommend alternative versions.
+
+* Proposal coordination with the core libraries committee (CLC):
+  * Changes to the interfaces of `base`, `template-haskell`, and other core
+    libraries under GHC control should not be made in minor releases.
+    Exceptions may be made for security vulnerabilities and severe correctness
+    issues.
+  * CLC/GHC Proposals intended to land in a given release should be decided on
+    and merged before a release branch is forked. Among other things this
+    ensures that `Cabal` can support any added pragmas.
+  * If the GHC Team intends to include a CLC proposal in a GHC release they
+    must provide the CLC sufficient time (at least two weeks) to consider and
+    approve the proposal.
+
+* Boot library maintainers should provide Hackage releases and version control
+  tags in a timely manner  
+
+* Boot library maintainers should notify GHC before increasing their dependency
+  footprint (including package)  
+
+* GHC upstream expects that boot library maintainers make conditional or
+  otherwise avoid unnecessary use of `TemplateHaskell` as such usage poses a
+  challenge for bootstrapping and cross-compiling GHC
+
+* GHC upstream appreciates notification from downstream maintainers regarding
+  releases and major bugs that may require action from upstream
+
+[library-versions]: https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history
+
+
+# 3. Expectations around communication
+
+We want to ensure that GHC's communications is clear and easily heard.
+While ideally GHC's developers will anticipate all issues that downstream
+consumers might encounter and work to mitigate them prior to release; however,
+in practice this is too ambitious. Robust communications channels ensure that
+lapses are quickly discovered and addressed.
+
+When considering communications modes, it is helpful to distinguish:
+
+* "**Push communication**" is:  
+  * Sent to a specific group of stakeholders that the GHC team thinks are relevant.  
+  * Opt out: recipients can opt out, of course, if they desire; and other
+    stakeholders can opt in.  
+
+* "**Opt-in communication**" is:  
+  * Broadcast to anyone who is interested.  
+  * Opt in: recipients will only receive it if they explicitly opt in, for
+    example by subscribing to an email list or reading the Haskell Discourse
+
+In all communications we hold ourselves to the [Haskell Foundation Guidelines
+for Respectful Communications][GRC]. We hope and expect that our counterparts
+will similarly follow these guidelines.
+
+[GRC]: https://haskell.foundation/guidelines-for-respectful-communication/
+
+## 3.1 Terminology
+
+* **alphas**: on the way to a release candidate, for integration testing, may be incomplete  
+* **release candidate**: this should be complete; in principle releasable.
+
+## 3.2 Communication channels
+
+GHC developers use the following communications channels:
+
+* <ghc-devs@haskell.org> and `#ghc-devs:matrix.org`, both used for
+  communications within GHC's developer community.
+
+* The <https://discourse.haskell.org/> and <ghc-users@haskell.org> used
+  primarily for release announcements and other major developments relevant to
+  end-users
+
+* the <ghc-releases@haskell.org> email list which includes every stakeholder who
+  *should* be informed (e.g. authors of key libraries), or who would *like* to
+  be informed, about releases. The GHC team will proactively add stakeholders
+  to this list, unless they explicitly ask not to be added, but in addition any
+  one can add themselves. While this list is open to the public GHC HQ will add
+  members to this list as appropriate (who naturally, may opt out if
+  desireable).
+
+* <ghc-boot-libraries@haskell.org>
+  mailing list for communication with maintainers of boot libraries. They are
+  likely not terribly interested in (comparably) lots of chatter in
+  <ghc-releases@haskell.org> and might prefer just a single email per release.  
+  Similar to `ghc-releases@`, GHC HQ will ensure that boot library maintainers
+  are added to this list appropriate.
+
+* A Matrix channel, [`#haskell-releases:matrix.org`][haskell-releases],
+  for informal real-time chat about releases. Announcements will be made over
+  this channel, but never exclusively on this channel (with `ghc-releases`
+  being the primary channel).
+
+* Every four months or so, we will hold a **regular check-in meeting** where a
+  small group of key consumers and GHC developers can meet to discuss how
+  things are going.  Scheduling such a meeting may be hard; but the goal is to
+  proactively reach out and invite a shared conversation about how to make
+  things better. GHC developers should certainly expect people to push their feedback
+  to them, but sometimes things fall through the cracks, so "pulling feedback"
+  at intervals makes sure this doesn't happen, and conveys that GHC developers
+  actually care about said feedback.  
+
+[haskell-releases]: https://app.element.io/?updated=1.11.19#/room/#haskell-releases:matrix.org
+
+
+## 3.3 Communications for major releases of GHC
+
+The status of major GHC releases will be communicated as follows:
+
+1. A few weeks before the fork date send email to <ghc-boot-libraries@haskell.org> containing:
+   * Announcing which version of which boot libraries the GHC team proposes to be included in the release  
+   * inviting feedback and version bumps
+   * Goal: have the boot libraries sorted by alpha-2  
+1. When a major release branch is forked, email to <ghc-releases@haskell.org>
+   and <ghc-devs@haskell.org> containing:
+  * an announcement that the branch fork has happened
+  * a preliminary announcement of the timetable  
+  * a summary of what the release is planned to contain, especially any
+    destabilising changes relevant to distributors and testers (N.B. language
+    changes are not so important for this purpose).
+1. Ensure that an entry exists in the [GHC release status table][ghc-status],
+   including a pointer to the milestone, which itself contains the timetable.  
+1. When each alpha comes out: email to <ghc-releases@haskell.org> for information rather than action
+1. When a release candidate comes out: email to <ghc-releases@haskell.org> inviting action:
+  * Invite downstream users to take it for a test drive  
+  * There will be at least a two-week window between the release candidate and
+    final release for testing and feedback
+  * This step may be repeated if substantial changes are made, albeit perhaps
+    with a shorter response window.
+
+[ghc-status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-Status
+
+## 3.4 Patch-level (aka minor) releases of GHC
+
+Even for patch-level releases, following the process of announcing a release
+candidate, with two weeks to try it out, is good practice.
+
+In particular, as for major releases:
+
+* Announce the upcoming release, with timetable etc.  
+* Indicate the reason for the release; what to look out for.  
+* Announce the release candidate as above, with time for downstream users to
+  respond
+
+Otherwise the process is the same as the major release case but without alpha
+pre-releases, with a two week testing window for distribution prior to final
+release.
+
+## 3.5 Proactive announcements
+
+Beyond releases, if GHC HQ decides to make major changes in platform or
+architecture support, they should inform the community well in advance, at
+least by email to `ghc-devs@`, to `ghc-releases@`, and a Discourse post.  
+
+Examples of such announcements include:
+
+* If **a platform moves from one [tier][platform-tiers] to another** (in either
+  direction):
+  * the decision will be announced as soon as possible, via at least the
+    `ghc-releases` mailing list, hopefully allowing volunteers to step up to
+    fix whatever made this decision necessary.  
+  * there will be a best-effort to also reach out to distributors and packagers
+    directly if we know they might be affected.
+
+* **Major changes to how GHC is compiled from source** are communicated to
+  users via [ghc-releases@haskell.org](mailto:ghc-releases@haskell.org) and the
+  release notes
+
+* **Bindist changes**:  
+  * Significant changes to the top level file layout of installed bindists are
+    communicated to downstream users via ghc-releases@haskell.org  
+  * Significant changes to the user-facing installation procedure (e.g.
+    \`configure\` and \`make install\`) are communicated to users via the
+    release notes and the release announcement.  
+  * Big changes to windows toolchains e.g. switching from gcc to clang are
+    communicated via ghc-releases@haskell.org. Smaller changes like upgrades to
+    the shipped versions are documented in release notes.
+