Propose a Feature

Every feature starts as a problem worth solving, stated in a feature issue. From there it is triaged, accepted, and refined until its use cases and scope are documented. Only then does it move on to Propose a Design.

Not sure the problem is clear yet?

An idea discussion is an optional first step. Use it when the problem still needs exploration or community input, then file the issue once you can state it. Start a discussion →

Open Feature Issue →

Writing a Good Feature Issue

Before opening an issue, make sure you can answer these three questions:

01

What problem are we solving?

Be specific about the problem, not the solution. Describe the limitation and its negative impact on users.

02

Why should we solve this now?

Provide justification: user impact, business value, technical debt, or compliance requirements.

03

Who are we solving this for?

Identify user personas: end users, administrators, developers, security teams, and their goals.

What Happens After You File the Issue

1

Triage

Maintainers review the issue for strategic fit, assess its scope, and apply labels. Expect questions on the issue thread wherever the problem statement leaves room for interpretation.

2

Accepted

An accepted issue is one ThunderID intends to build. It is open for anyone, including you, to pick up. An issue that is not accepted is closed with the reasoning on the thread.

3

Refinement

Maintainers and the reporter work through the use cases and the scope together on the issue thread, and update the issue body as it converges. This is where the boundaries get set: which use cases the feature covers, and which it explicitly leaves out.

Refined and scoped: move to design

An issue moves on only once its use cases and scope are documented. Design starts from that scope, so an unrefined issue is sent back rather than designed around.

See Propose a Design →

You can stop here

Creating a well-defined feature issue is a complete contribution. You don't need to design or implement it yourself.