From idea to release
How larger work on Home Assistant is planned in the open, from a feature request to a roadmap opportunity, an epic, tasks, and pull requests, and where you can join in along the way.
A lot of work on Home Assistant needs no plan at all. A bug fix, an improvement to an integration, or a new integration that is ready for core: you open a pull request, and that's it. Pull requests and reviews covers that path.
Larger work is different. When something spans several repositories, needs design, or changes how Home Assistant is built, the Open Home Foundation plans it in layers, in public repositories on GitHub. This page walks through those layers, shows where each one lives, and where you can follow along or join in. At the end, one real piece of work is traced from the first feature request to the release that shipped it.
Goals: where the foundation wants to go
Opportunities: problems worth solving
Epics: a body of work, often one phase of an opportunity
Tasks: one piece of work in one repository
Next to these layers, not in them, sits the architecture. It guards how Home Assistant is built, for everything that goes in, whether it comes from the roadmap or not.
At the top are the goals of the Open Home Foundation, in the goals repository. The board of the foundation sets them, and they define where the foundation wants to go. Examples are Make Home Assistant more approachable and Proxy all the things. The board also maintains them, and each goal links to the roadmap opportunities that work toward it.
Only members of the foundation write goals, but the discussion is open: you can comment on a goal and share your view.
Most ideas start as a feature request. Anyone can open one, vote on one, or join the discussion. Describe the problem you want to solve, not only the solution you have in mind. Where we talk has more on writing a good one.
The product team of the foundation regularly reviews popular and strategic requests, and turns some of them into roadmap opportunities. Votes and thoughtful discussion count, but not every request makes it onto the roadmap.
The roadmap of the Open Home Foundation covers Home Assistant, ESPHome, Music Assistant, and the other projects of the foundation. It is not a list of features with dates. It is a set of opportunities: problems worth solving. Each one is an issue, linked to the goal it supports.
An opportunity can start as a rough idea and get shaped over time. Its issue has room for:
- Problem statement: what the problem is, who has it, and why it matters
- Community signals: the feature requests, discussions, or Discord threads that point to it
- Scope and boundaries: what is in, and what is explicitly out
- Foreseen solution: the solution, shaped enough to understand what it means to build it
- Risks and open questions: what is still uncertain
- Appetite: how much time the opportunity is worth, roughly small, medium, or large
- Execution issues: links to the work, once it is approved
- Decision log: key decisions and pivots, with dates
A large opportunity can have smaller opportunities below it. For example, shaping the UI around how a household uses its smart home holds several more focused ones.
Who takes part: only foundation staff and authorized contributors create opportunities. Issues opened by anyone else are closed automatically. Comments are open to everyone, and they matter: they can add signals, question the scope, or change the solution, as the example below shows.
How opportunities are picked: the decision log of the template mentions the outcomes of a "betting table", where opportunities are chosen for work. How that works, and who takes part, is not described in the public repositories.
Follow along: the roadmap project board shows the active opportunities and their progress, and you can watch the roadmap repository on GitHub. The roadmap category of the Home Assistant blog has the bigger picture, the most recent being Roadmap 2025 from May 2025. When the work ships, the release notes often link the opportunity, like 2026.6 did when it closed the opportunity to make infrared a two-way platform.
Work that needs design goes through the UX design discussions of the foundation. How we design explains that path.
An epic is a larger body of work made up of several tasks, often across several repositories. Epics live in the epics repository. Each one states:
- The roadmap opportunity it delivers
- The problem it solves and the outcome it aims for
- Its deliverables
- When it counts as done
- Context, like the feature requests, design documents, or Discord channel that go with it
An epic is a sub-issue of its opportunity. Epics can also block each other, which GitHub shows in the sidebar of the issue.
An opportunity is often delivered in phases, and each phase gets its own epic. For example, HTTP server configuration through the UI has phase 1, the port default and the UI, which is done, and phase 2, SSL/TLS in the UI and dual stack, which is in progress. Phase 3 is listed in phase 2, but has no epic yet.
Later phases can be a plan rather than a promise. The epic for phase 3 of making Home Assistant OS easier to install says so itself: its scope is a plan, not a commitment, and items may move between phases or be dropped.
Not every epic comes from an opportunity. Some are cleanups across many integrations, like translating file system errors with the common OSError helpers. They explain the right pattern, list the integrations that need a fix, and ask you to reference the epic in your pull request. If you are looking for a well-defined piece of work in Home Assistant Core, these are a good place to look.
Who takes part: members of the home-assistant organization on GitHub create epics. Issues opened by anyone else are closed automatically. Reading and following them is open to everyone.
A task is a smaller piece of work in a single repository. It is an issue of the type Task, in the repository where the work happens: Home Assistant Core, the frontend, the documentation, the Supervisor, or any other. Each task is a sub-issue of its epic, so the epic shows how far along the work is.
Work that doesn't fit in any repository goes to the tasks repository. Only members of the home-assistant organization open issues there.
Who takes part: not everyone can open a task. In most repositories, a workflow checks every new issue of the type Task: if you aren't a member of the home-assistant organization on GitHub, it closes the issue with the auto-closed label and a comment that points you to the bug report form and to feature requests. Home Assistant Core and home-assistant.io also accept tasks from anyone listed in the CODEOWNERS file of the repository, like integration owners. Once a task exists, it's an ordinary issue: you can comment, ask questions, or offer to help. Want to work on one? Say so on the task before you start, so nobody does the same work twice.
The work itself happens in pull requests, like any other contribution. Link the task in the description, for example with fixes #12345, so the task closes when the pull request is merged. Documentation for a new feature goes to the next branch of home-assistant.io, so it goes live with the release. The review is the same as for every other pull request: see pull requests and reviews.
Who takes part: everyone. Opening a pull request, and reviewing one, is open to all contributors.
Merged work ships in the next monthly release. The week before, it is in the beta, where anyone can test it in their own home. How releases work explains the cycle, and your first release contribution shows how to join the beta.
The architecture meeting guards the technical architecture of Home Assistant. It is not a step in the roadmap flow: it sits next to it, to look after the technology. Any change to how Home Assistant is built needs its approval, wherever the change comes from: an opportunity, an epic, or a pull request of your own. Think of a new type of entity, a change to an entity model, or new triggers and conditions for an entity component.
The meeting handles proposals, which are discussions in the architecture repository.
When roadmap work touches the architecture, the two link to each other. An opportunity can lead to an architecture discussion, which links back to it as the place where the reasoning lives. An opportunity can also build on an architecture discussion that was there first, like the opportunity to let Home Assistant send radio frequency commands.
A proposal is discussed in the open, and then decided in the meeting. The outcome is posted on the discussion and marked as its answer: approved or rejected, with the date of the meeting and any remarks, like changes the meeting wants. Decisions that set a lasting rule for the whole project are also written down as an Architecture Decision Record. How architecture decisions are made explains that process.
Who takes part: anyone can start an architecture discussion or join one.
| Layer | Where | What you can do |
|---|---|---|
| Goals | OpenHomeFoundation/goals | Read and comment |
| Feature requests | Feature requests | Propose, vote, and discuss |
| Opportunities | OpenHomeFoundation/roadmap and the project board | Follow and comment |
| Architecture | Architecture discussions | Start a discussion, or join one |
| Design | UX design discussions | Share ideas and give feedback |
| Epics | home-assistant/epics | Follow along, and pick up work from the cleanup epics |
| Tasks | The repository of the work | Comment, and offer to help |
| Pull requests | The repository of the work | Open and review pull requests |
| Release | The beta | Test, and report what breaks |
Here is one piece of work, traced from start to finish. It made the sun triggers and conditions work with the actual position of the sun, instead of fixed time offsets around sunrise and sunset.
- Feature request. In March 2026, a user asked for dawn and dusk triggers, next to sunrise and sunset.
- Opportunity. In April 2026, the opportunity Improve sun-based triggers and conditions was opened, with that request as its community signal. It described the problem (an offset that matches dusk in spring is wrong in winter, and useless above the Arctic Circle), proposed a full set of triggers and conditions based on the elevation of the sun, and set a small appetite. In the comments, community members added signals and questioned the choice to leave out time offsets.
- Architecture. A maintainer pointed out that new triggers and conditions for an entity component need architecture approval. So the architecture discussion was opened in May 2026, linking back to the opportunity. The architecture meeting first asked for changes, like one dawn trigger with a type option instead of three separate triggers. In June 2026, it approved the revised proposal.
- First release. The high priority triggers and conditions were built in core#174485 and core#174537, and shipped in 2026.7.
- Epic and tasks. In July 2026, after that first release, the epic Improve sun-based triggers and conditions was opened below the opportunity, with tasks in two repositories: the work that had just shipped, time offsets, the remaining triggers and conditions, and the documentation.
- Feedback changes the plan. After 2026.7, people on Discord and in the comments of the opportunity asked for time offsets. That needed its own architecture discussion, approved in the core meeting at the end of July. The pull request was merged the next day and shipped in 2026.8.
- Last release. Golden hour, blue hour, midnight sun, and polar night came in core#180106, documented in home-assistant.io#47624, and shipped in 2026.9.
- Closed. The epic was closed in September 2026, and the opportunity a week and a half later. One follow-up task, triggers and conditions based on the azimuth of the sun, is still open.
A few things stand out. The work started from a feature request with about a dozen votes. Comments from the community changed what was built. The architecture decision came before the code, and a later change needed a decision of its own. And the real order is messier than the layers suggest: here, the epic was opened after the first part had already shipped.
- A question about an opportunity or an epic? Ask it in a comment on that issue, so the people working on it see it.
- A question about the architecture of a change? Use the architecture discussions, or ask in #developers on Discord.
- Not sure where your idea belongs? Start with a feature request.