diff --git a/Stages.md b/Stages.md
index 6510eff..eb9737e 100644
--- a/Stages.md
+++ b/Stages.md
@@ -1,5 +1,7 @@
 # WHATWG Stages
 
+**See [all features using the Stages process](https://github.com/search?q=org%3Awhatwg+is%3Aopen+label%3A%22stage%3A+1%22%2C%22stage%3A+2%22%2C%22stage%3A+3%22&type=issues) and their current states.**
+
 The WHATWG's approach to "documenting reality" is ideal for nailing down [fundamental parts of the platform](https://spec.whatwg.org/) and improving interoperability and developer satisfaction. It can sometimes be daunting for new [Contributors](./IPR%20Policy.md#contributor), who don't know how to reliably get implementer feedback or editor time commitment. The WHATWG Stages process is an optional, opt-in process that both new and established [Contributors](./IPR%20Policy.md#contributor) can use if they want to get more formal signals on support for their [Contribution](./IPR%20Policy.md#21-contribution). This tool is generally used for medium-to-large [Contributions](./IPR%20Policy.md#21-contribution); it's not expected to be used for each [Contribution](./IPR%20Policy.md#21-contribution).
 
 Stages asks for explicit implementer involvement at multiple checkpoints, starting from notification that the problem is being worked on, then sign-off on the rough API and specification, and finally agreement on the full specification text. These checkpoints are also useful to the broader community, helping web developers monitor the [Contributions](./IPR%20Policy.md#21-contribution) that are moving through the various stages. By explicitly signaling a [Contribution](./IPR%20Policy.md#21-contribution)'s progress, including implementer involvement, the community has a better idea of what is going on in the WHATWG.