Feature Requests
Edit on GitHubProposing a new feature for the beacon: describing the use case, checking the roadmap, and what makes a request get built.
Feature Requests
The roadmap is driven by use cases, not ideas. This page explains how to propose a feature so it has a real chance of being built.
The use-case rule
Describe the problem, not the solution:
| Weak | Strong |
|---|---|
| “Add a louder buzzer” | “During a snowstorm the buzzer is inaudible at 20 m” |
| “Add Bluetooth” | “I want to read the beacon status without opening the case” |
The maintainer’s job is matching solutions to use cases; the request should supply the use case.
Before you ask
- Check the Roadmap: the feature may already be planned.
- Check the FAQ and the wiki: it may already exist in another form.
- Search the issues: someone may have asked the same thing, with the discussion that matters.
The process
- Open an issue with the use case (see Reporting Issues for the format).
- Discuss scope: every feature has a cost in battery, complexity or both.
- If it survives discussion, it lands on the roadmap.
- The fastest path to any feature: build it yourself on a branch (see Contributing).
The honest filter
The project’s design constraint is stated on the Overview: a simple, rugged, battery-honest rescue device. Features that fight that constraint (heavy, power-hungry, complex) need an exceptional use case to win.
Related pages
- Roadmap for the planned work
- Contributing for building it yourself
- Reporting Issues for the issue format