diff --git a/.github/DISCUSSION_TEMPLATE/feature-requests.yml b/.github/DISCUSSION_TEMPLATE/feature-requests.yml
index 183a3de934eccc8baa8428e822176e31d1d11782..e8a695063c34771ac6120b1e477b7494a17aa3c9 100644
--- a/.github/DISCUSSION_TEMPLATE/feature-requests.yml
+++ b/.github/DISCUSSION_TEMPLATE/feature-requests.yml
@@ -40,4 +40,4 @@ body:
     attributes:
       value: |
         Learn more about how feature requests work in our
-        [Feature Request Guidelines](https://github.com/zed-industries/zed/discussions/47963).
+        [Feature Request Guidelines](https://github.com/zed-industries/zed/discussions/51422).
diff --git a/docs/src/development/feature-process.md b/docs/src/development/feature-process.md
index 811e1a4fd6130fdf0abc687f6943f58b24e81b08..ec39c6c4b59ef5916d5f5dcfada9abf326f77a3a 100644
--- a/docs/src/development/feature-process.md
+++ b/docs/src/development/feature-process.md
@@ -2,7 +2,7 @@
 
 This is for moderate-to-large features — new UI, behavior changes, or work that cuts across multiple parts of Zed. Small keybindings or settings tweaks don't need all of this.
 
-> **Before you start:** If you're an external contributor, make sure the feature is something the team wants before investing significant effort. That said, coming prepared with background research makes it much easier for the team to understand and approve the proposal. Read the [Contributing guide](../../../CONTRIBUTING.md#sending-changes) — if there isn't already a GitHub issue with staff confirmation, start with a GitHub Discussion or a Discord message rather than a PR.
+> **Before you start:** If you're an external contributor, make sure the feature is something the team wants before investing significant effort. Please read the [Contributing Guide](../../../CONTRIBUTING.md) and our [Feature Request Guidelines](https://github.com/zed-industries/zed/discussions/51422) — if there isn't already a GitHub issue with clear staff confirmation, start with a GitHub Discussion. Feature request PRs that skip this process have a _very_ low merge rate. Taking the time to follow our process significantly increases the chances your idea gets picked up and built.
 
 ## 1. Why does this matter?
 
@@ -18,16 +18,20 @@ Write a short, concrete feature statement, then back it up with the context gath
 
 Here's an example format, though adapt it to whatever your feature needs:
 
-> **Feature:** Inline Git Blame
-> **Purpose:** Show the last commit author and message for each line directly after the editor text, so developers can understand code history without opening the git blame.
-> **Background:**
-> This is standard across all major code editors
-> \[screenshot of VSCode]
-> \[screenshot of Intellij]
-> \[screenshot of Neovim]
-> and has 146 thumbs up on the [github issue](https://github.com).
-> **Decisions:**
-> We have to decide whether to use the git CLI or a git library. Zed uses a git library but its blame implementation is too slow for a code editor, so we should use the CLI's porcelain interface.
+**Feature:** Inline Git Blame
+
+**Purpose:** Show the last commit author and message for each line directly after the editor text, so developers can understand code history without opening the git blame.
+
+**Background:**
+This is standard across all major code editors:
+
+- \[screenshot of VSCode]
+- \[screenshot of Intellij]
+- \[screenshot of Neovim]
+- and has 146 thumbs up on this [github issue](https://github.com).
+
+**Decisions:**
+We have to decide whether to use the git CLI or a git library. Zed uses a git library but its blame implementation is too slow for a code editor, so we should use the CLI's porcelain interface.
 
 ## 3. What else does this affect?