RFC process purpose and goals
The RFC (Request for Comment) process provides a consistent and controlled path for new features to enter the Storybook project. It helps ensure that new features are well-designed, well-implemented, well-tested, and do not conflict with the project's overall direction and scope. The process aims to provide a transparent system for proposing new feature ideas, establish a reliable and well-regulated process for introducing new features, and provide a way for the community to participate in developing new features.
Feature request versus RFC distinction
A feature request is a straightforward and relatively informal way for users to suggest a new feature or enhancement. Feature requests typically do not involve an in-depth design process or require consensus among the core team, and may or may not be implemented based on popularity, feasibility, and alignment with project goals. An RFC is a more formalized and structured process for proposing substantial changes that significantly impact the project, such as introducing new API functionality, removing existing features, or establishing new usage conventions. Accepted RFCs are more likely to be implemented than regular feature requests.
RFC lifecycle status: Proposed
To enter the Proposed status, open a new GitHub discussion in the RFC category at https://github.com/storybookjs/storybook/discussions/new?category=rfc and fill out the form as instructed. Details matter in RFCs; those that do not present convincing motivation, demonstrate a lack of understanding of the design's impact, or are disingenuous about drawbacks or alternatives tend to be poorly received.
RFC lifecycle status: In review
RFCs remain in the In Review stage for a while, giving the community and core team members time to weigh in. The RFC author should be prepared to revise the proposal, integrate feedback, and build consensus. RFCs with broad support are more likely to progress than those without comments. Every week, the Storybook core team conducts a triage meeting to review open RFCs as part of the agenda, publicly scheduled in the Storybook Discord Watercooler channel. The RFC author(s) and interested community members are invited to participate. If necessary, a core team member is assigned as the RFC champion to collaborate with the author and assist throughout the process.
RFC lifecycle status: accepted or rejected
Eventually, the core team decides whether an RFC is a candidate for inclusion in Storybook. An RFC may be rejected by the team after a public discussion has settled and comments have been made summarizing the rationale for rejection.
RFC author not obligated to implement accepted RFC
The author of an RFC is not obligated to implement it. The RFC author, like any other developer, is welcome to post an implementation for review after the RFC has been accepted. However, the accepted status does not indicate priority or whether the RFC is being actively worked on. Anyone interested in implementing an accepted RFC can ask by leaving a comment to determine if someone else is already working on it.
Experimental feature status definition
Experimental features mark the beginning of feature development where ideas are being validated and direction is being shaped. These features are functional but still evolving, with room for iteration based on real-world use. They are ideal for trying out in prototypes or early integrations, not for building critical paths around. Each experimental feature has an associated RFC where the initial idea is shared and progress is reported. Implementation details may change significantly before stabilization.
Preview feature status definition
Preview features are nearly production-ready and generally reliable, with documentation in place and most known issues addressed. They should be fully functional for at least one supported framework, but may still be incomplete or less polished in others. Preview features are suitable for use in real projects and teams are encouraged to adopt them and share feedback. While the feature is stable in direction, minimal breaking changes may be introduced in minor releases to address gaps or refine behavior. Automigrations are provided where possible. The team aims to collect feedback and iterate for 1-2 minor releases before promoting to stable.
Stable feature status definition
Stable features are fully supported and safe for production use across all projects. They are well-documented, thoroughly tested in all core frameworks, and follow semantic versioning. Users can expect long-term support, with any breaking changes reserved for major releases.
Deprecated feature status definition
Deprecated features are in the process of being phased out and will be removed in an upcoming major release. Users should begin migrating to supported alternatives as soon as possible. These features no longer receive active development or bug fixes, and their functionality may degrade over time. Typically, a deprecated feature is removed within the next major release cycle, for example if deprecated in 8.x, removal is expected in 9.0.
Storybook feature lifecycle labels
Storybook classifies features using four lifecycle labels: Experimental, Preview, Stable, and Deprecated. These labels help users understand the team's level of commitment, expected quality, likelihood of breaking changes, and anticipated timeline for each feature.
Storybook roadmap structure and columns
The Storybook roadmap is maintained as a public GitHub project. Each card represents a Storybook project, and the columns represent how larger changes progress from idea to shipped feature. The columns are: Candidates (ideas being considered for the current major release), Under consideration (projects being discussed for the next dev cycle), In progress (projects currently being worked on), and Done (completed, documented, and released projects).
Storybook release schedule
Storybook ships a minor version every eight weeks and a major version once per year, typically in February or March.
Candidates column: fuzzy ideas for current major release
The Candidates column contains ideas on the radar being considered for the current major release. For example, if 8.0 is the most recent major version, these would be ideas for 8.x or 9.0. The ideas in this column are the fuzziest and may come and go depending on priorities.
Under consideration column: RFC-documented projects for next dev cycle
The Under consideration column contains projects being discussed for the next dev cycle. For example, if the most recent minor version is 8.1 and the team is currently working on 8.2, the projects in this column would be under consideration for 8.3. Unlike the candidates column, projects under consideration must be documented with an RFC.
In progress column: tracking issues and community projects
The In progress column contains two kinds of projects: (1) Tracking issues that are fully scoped and expected to ship in the next minor release (for example, if the most recent minor is 8.1, these should ship in 8.2, eight weeks after 8.1); and (2) Community projects facilitated by the core team and side projects that don't have an ETA but should ship as part of the current major.
Done column: completed and released projects
The Done column contains projects that are completed, documented, and released. Storybook follows a 'fixed time, variable scope' policy for core projects, meaning scope is adjusted into milestones to provide value to users as early as possible and cut scope if necessary to ship on time. If a feature is scoped out of a project, it may be fit into a follow-up project, treated as general maintenance work, or deferred.
Roadmap is estimation, not commitment
The Storybook roadmap is an estimation, not a commitment. In general, every tracking issue 'in progress' should be available in the next two months. Everything else on the board has a decent chance of getting into the next major release. If a project is not likely for the next major, it will be kicked off the board.
Getting items onto the roadmap
To get something onto the roadmap, if there is a significant product improvement with an existing issue or RFC, upvote that issue and comment with more information about your need or use case. If nothing suitable exists, submit an RFC. The Storybook team prioritizes based on a combination of user and contributor interest (upvotes, comments, Discord conversations) and their own strategic ambitions for the project.