Skip to content

feature-requests.md

Latest commit

 

History

History
126 lines (92 loc) · 7.06 KB

feature-requests.md

File metadata and controls

126 lines (92 loc) · 7.06 KB
Raw

Feature requests

This page explains how feature requests for the Element apps (Web/Desktop, Android and iOS) and Element Call are filed, how the product team answers them, and when it makes sense to write code.

The short version: open an issue, wait for an answer, and only write a PR once the issue says we want one.

Where to file

Element is one product on three platforms. Features are managed in a single place so they stay consistent.

What you want Where
A new feature, or a change to how an existing feature behaves, for one platform or all of them, calls included element-meta
A bug the repository where it reproduces: element-web, element-x-android or element-x-ios; element-call for calls
An SDK API, protocol, performance or crypto concern matrix-rust-sdk (Element X on Android and iOS) or matrix-js-sdk (Element Web and Desktop)
The rich text composer matrix-rich-text-editor
The sign-in, sign-up and account management pages opened by your homeserver matrix-authentication-service

The app and element-call repositories hold only bugs and the engineering tasks that deliver a feature, no feature requests.

The SDK, composer and authentication repositories are not on the triage board described below: requests there are agreed with their maintainers and do not go through the process on this page.

Please file at most 2 feature requests a week. Each one takes time to read and answer. If you file more, we may close the extra ones with a standard reply. You can file them again once your earlier requests have an answer.

Please report security issues by email to security@element.io, not in a public issue. See the security disclosure policy.

Who decides

Accepting a feature is a product decision, made by the Element product managers. It means the feature fits the direction of the product, the design is agreed, and we want it.

The decision depends on the problem, so the templates start from the problem rather than the solution: what you are trying to do, who has this problem, and how often.

How we answer

Feature requests are triaged on the public Feature Requests Triage board. It collects open issues labelled T-Enhancement in element-meta. We aim to answer every request in a timely manner.

The answer is the issue's Status on the board. It is shown in the Projects panel of the issue page:

Projects
  Feature Requests Triage
    Status   🧪 Let's try
Status What it means Should I write a PR?
📥 Untriaged Nobody has looked at it yet. Not yet. Wait for an answer.
❓ Needs info We need more from you before we can answer. Not yet.
💬 In discussion Product, design or engineering is working out an answer. Not yet.
🚫 Don't do It does not fit the direction of the product. The issue is closed as "not planned". No.
⏸️ Maybe later It does not fit now. We may reconsider it. No promise, no date. No. If you disagree, say so on the issue and we can look at it again.
🧪 Let's try We are open to a PR and will evaluate it as a proof of concept. We may still decide not to ship it. Yes, knowing the risk. See below.
✅ Do it We want this. The core team will support integrating a PR that meets our quality bar. Yes.
🏗️ Coming soon The core team is working on it, or will start soon. No. Please don't duplicate the work.

We explain our answers when it helps, but not always in depth. A request that clearly does not fit may be closed with a short or standard reply and no detailed reasoning: we would rather spend that time on the requests we can say yes to.

This is not a roadmap

The Status is our answer to a request. It is not a plan, a schedule or a promise.

  • ✅ Do it means we would welcome a PR and help get it merged. It does not mean the core team will build it.
  • 🏗️ Coming soon means the core team has picked it up. It carries no date.
  • These answers are not a priority order. Most of the work behind 🧪 and ✅ is done by contributors, on their own schedule.

About 🧪 Let's try

We are interested enough to look at an implementation, but a PR here is a proof of concept that helps us evaluate the feature. We may still decide not to ship it, and that is a possible outcome. If that is not a risk you want to take, wait for ✅ Do it.

About ⏸️ Maybe later

There is no scheduled review of these issues. They stay open, and if someone still cares about one, a comment on the issue brings it back to our attention.

Labels

Only the two answers that invite you to write code also get a label, so you can find them in any issue list without opening the board. The labels follow the board automatically, within an hour:

Label Meaning
X-Accepting-PRs Same as ✅ Do it. We want this. The core team will support integrating a PR that meets our quality bar.
X-Accepting-PoC-PRs Same as 🧪 Let's try. PR welcome as a proof of concept to evaluate the feature. No warranty it is merged.

For example: issues accepting PRs in element-meta.

The App: labels say which platforms a request is for: App: web, App: ElementX Android and App: ElementX iOS. New requests start with all three, and triage removes the ones that don't apply. Requests about calls also get A-Element Call. As a rule, a feature lands on all platforms, so a PR for one platform may wait for the others before it is merged.

Before you write code

  1. Say whether you want to implement it, and on which platforms. The issue template asks.
  2. Wait for ✅ Do it or 🧪 Let's try (or their labels) before you start. This rule protects your time more than ours: a PR with no agreed intent behind it is a design conversation held after the code was written.
  3. Link the issue from your PR with Part of element-hq/element-meta#N, not Fixes. A feature PR whose issue has neither label may be closed with a pointer back to the issue.
  4. If you feel you have been waiting too long for an answer, comment on the issue to remind us.

You never need to create issues in the app repositories for an accepted request: when the core team picks work up, it creates the T-Task sub-issues there itself.

This applies to features and enhancements only. Bug fixes don't go through product triage.