📣 Feature Request Guidelines – start by reading this

[franciskafyi]

Feature Request Guidelines

Welcome! We value ideas and feedback from the community, and feature requests play an important role in shaping the direction of Zed.

This guide explains how to propose new features or improvements, what to expect after you submit a request, and how ideas move from discussion to implementation. The goal is to keep this process open and transparent while encouraging real collaboration between the Zed team and contributors.

Before you submit: Feature request PRs that skip this process have a very low merge rate. Taking the time to follow the stages below significantly increases the chances your idea gets picked up and built.

---

How feature requests work

Feature requests move through a number of stages. Not every request will advance, but each stage is designed to make progress and decisions visible when they happen.

---

Stage 1: Feature Request (Discussion)

Anyone can propose a feature, improvement, or change by opening a discussion.

At this stage, the Zed team may triage discussions by applying labels, asking clarifying questions, or guiding the conversation. The focus is on exploring the idea, gauging interest, and filtering out proposals that are low-effort or don't align with Zed's product direction.

Possible outcomes:

• Closed with an explanation
• Left open for community discussion
• Promoted into an issue

Discussions that stay open can continue to gather feedback and signal from the community. Over time, they may be promoted into an issue or closed if the idea isn't feasible.

---

Stage 2: Accepted Proposal (Issue)

When a discussion is promoted to an issue, it's an explicit signal from the team that the idea is worth pursuing. All accepted proposals are added to the Community Features Board, which tracks feature work where community contributions are especially welcome. This is also where we try to make visible the community requested work that the Zed team is currently working on.

At this stage:

• Scope and goals are agreed on at a high level
• The team looks for a Zed maintainer and community contributor who can pair on the work
• In some cases, an experienced contributor may pick up an issue independently. More commonly, an internal owner is identified to guide the work and keep it moving

Reaching this stage does not guarantee a timeline. Prioritization depends on user impact, alignment with current goals, available maintainer time, and contributor interest.

If you're a contributor ready to build, the Feature Development Process doc and our Contributing Guidelines offer more context to help you get started.

---

Stage 3: Development

Once an issue has an owner and enough direction, development begins. Community contributors and Zed maintainers work closely together during this stage, with maintainers supporting, reviewing, and helping unblock progress. Work may include design discussions and pairing sessions. We try to allocate enough time for this but it will be dependent on the maintainer's other commitments and deadlines.

---

Stage 4: Review and Merge

When a pull request is ready, a Zed maintainer will review it. The review focuses on correctness, code quality, and whether the implementation matches the agreed scope from Stage 2.

A few things to expect:

• Feedback may require changes before the PR can be merged. This is normal and part of how we maintain quality across the codebase.
• If a PR diverges significantly from the agreed scope, the maintainer may ask you to revise the approach or split the work into smaller pieces.
• PRs that weren't preceded by an accepted issue are unlikely to be merged.

Once a PR is merged, the associated issue is closed and the feature is released 🎉