The Zimbra roadmap provides a visual representation of the current status of requested features and fixes, helping our customers understand what’s being worked on and when they can expect to see changes. However, we understand that it’s not always easy for team members outside of Zimbra to understand the meaning of each stage on our roadmap. In this article, we’ll provide an overview of the different stages and what they mean, helping everyone, including our customers, to better understand our product development process.

1. In review: When a feature request is submitted, it first goes through the “In review” stage. This is the initial stage of the feature request. At this stage, we evaluate the request to ensure it aligns with our product vision and goals, and the customer segments we serve. We assess the potential impact on customers, required resources, and the potential return on investment.

   We may reach out to the submitter or other stakeholders to clarify any uncertainties or ambiguities related to the request and determine its importance relative to other requests. We also consider whether the feature is a must-have or nice-to-have, as well as its potential impact on customer satisfaction.

   Users will not be able to submit bug fix requests. Bug reporting will continue to be routed via Zimbra Support team, and bug related communication via the bug portal. The board “Bug fixes” is only intended to provide a more comprehensive picture of the roadmap by sharing details of the planned, in progress and released bugs.

2. Accepted: Once a feature request has passed through the reviewing criteria and meets our acceptance criterion, it is moved to the “Accepted” stage. At this point, we have agreed to consider the feature request and added it to our backlog for future consideration. The accepted stage marks the beginning of the process to turn the request into a tangible product fix or product feature.

   The accepted request is evaluated using the RICE prioritization framework. The RICE framework helps us to focus on the most impactful features and ensure that we’re delivering the most value to our customers. This means that the feature has been added to our development roadmap and will be considered for implementation in a future release based on its reach, impact, confidence, and effort required to address it.

3. In progress: Features are prioritised using the RICE framework and they remain the in the backlog until picked for active development. This means that features with higher RICE score always moves to the top of the backlog and then the development team picks up features from the top of the backlog.

   When our development team begins work on a feature or a bug fix, it is moved to the “In progress” stage. This means that we have started development and are actively working on implementing the feature or fixing the bug. A bug that has been fixed and a feature that has been implemented and tested may still sit in this stage, unless the release that they have been tagged to, does not get released in production.

4. Released: Finally, when the feature or bug fix gets released in a EA or GA release, it is moved to the “Released” stage. At this stage, the feature or bug fix has been released in a production build and is available for use by our customers. A released feature or bug fix will be updated with the production release related information.

5. Closed: This stage signifies the decision to close a bug without implementing a fix. The decision is based on Zimbra's prioritization criteria, where we balance resource allocation, user experience impact, and the bug's reach. Bugs with non-critical impacts (S3/S4 severity level) may be closed to allow focus on higher impact areas. This stage reflects our commitment to address critical issues related to security, compliance, and high-value features.