Feature Request Guidelines

[J1337]

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 of this process is to keep feature discussions open and transparent while encouraging collaboration between the Zed team and the community.

---

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, Zed 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 low effort proposals or ideas that do not align with Zed’s product vision.

Possible outcomes

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

Discussions that remain open can continue to gather feedback and signal from the community. Over time, they may be promoted into an issue or closed if the outcome is not feasible.

---

Stage 2: Accepted Proposal (Issue)

When a discussion is promoted, it becomes an issue. This is an explicit signal from our team that the idea is worth pursuing.

All feature proposals that reach this stage are added to the Zed Guild - The Board (view)

This board tracks feature work where community contributions are especially welcome and helps make active opportunities visible.

At this stage:

• Scope and goals are agreed on at a high level
• The team looks for a Zed maintainer and community contributor who are able to pair on the work

In some cases, a community champion (experienced contributor) may pick up an issue without an internal owner. More commonly, an internal owner will be identified to guide the work and move it forward.

Promotion to this stage does not guarantee immediate implementation or timelines. Prioritization is influenced by factors such as user impact, alignment with current goals, available maintainer time, and contributor interest.

---

Stage 3: Development process

Once an issue has a owner and sufficient direction, development can begin.

Community contributors and Zed maintainers collaborate closely during this stage, with maintainers supporting, reviewing, and helping unblock progress. Work may include design discussions, pairing sessions, and pull requests.

---

Feature request guidance

When creating a feature request proposal, you will be provided with a template to help explain the idea clearly and consistently.

The template focuses on the most essential information: what is being proposed, and why? Clear and well defined proposals are easier for the community and the team to engage with. The intent is to start a conversation not to produce a finished specification.

---

Feature Request Template

Use this template to suggest a new feature, improvement, or change.

What are you proposing?

Describe the feature, improvement, or change at a high level.

Why does this matter?

What problem does this solve?

What becomes easier or possible?

Are there any examples or context?

Screenshots, mockups, workflows, or examples from other tools.

Possible approach

If you have ideas about how this could work, share them here.