franciskafyi created
Small tweaks to our feature doc and a link out to more about how the
Feature Request process works.
Release Notes:
- N/A.github/DISCUSSION_TEMPLATE/feature-requests.yml | 2
docs/src/development/feature-process.md | 26 ++++++++++-------
2 files changed, 16 insertions(+), 12 deletions(-)
@@ -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).
@@ -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?