The Capacitor project has grown tremendously since its inception, and the pace of active development and community contributions is a testament to its success. With that growth came a reality we need to own as maintainers: over time, we did not invest enough consistent attention in open-source triage and follow-through.

As a result, technical debt accumulated most visibly in our GitHub Issues and Pull Requests. Across several repositories in the Capacitor ecosystem, hundreds of issues and PRs — many dating back years — remain open, unreviewed, or no longer actionable. This makes it difficult to track what still matters today, slows down contributors who want to help, and can create the impression that Capacitor is not actively maintained. 

This backlog is a sign that our previous processes and capacity for managing open-source work at scale were not sufficient. We also recognize that this has led some in the community to feel unheard, and that’s something we’re committed to changing—starting now.

To ensure Capacitor continues to move forward in a healthy, sustainable way, we’re taking a focused step to reset expectations, clean up outdated work, and put better long-term backlog management practices in place.

Why a Backlog Reset is Necessary

The sheer volume of open Issues and Pull Requests makes it difficult to distinguish between:

• Active bugs – Problems still impacting users today
• Resolved issues – Fixed long ago but never explicitly closed
• Outdated feature requests – Ideas that no longer align with the modern Capacitor roadmap
• Duplicate reports – Multiple entries describing the same problem

A one-time, comprehensive cleanup of this backlog is the most effective path forward. It allows the core team to focus where our attention delivers the most value: current development, forward-looking roadmaps, and bugs affecting the latest releases.

Behind the scenes, we’re also investing in better automation to help route community contributions more directly into our internal planning tools—improving triage, reducing manual overhead, and ensuring important signals don’t get lost in the noise.

This cleanup is not a one-time event; it’s a reset, paired with clearer triage rules and ongoing review so the backlog remains healthy going forward.

The Process: Clear and Fair Rules

Our goal is not to dismiss community input, but to ensure that the issues which remain are relevant, actionable, and aligned with the modern Capacitor framework. For this process to be transparent and fair, we’re establishing clear, objective rules for which items will be closed and which will be retained.

Impacted Repositories

This initial pass will focus on the highest-volume repositories in the Capacitor ecosystem:

• https://github.com/ionic-team/capacitor
• https://github.com/ionic-team/capacitor-docs
• https://github.com/ionic-team/capacitor-plugins

Future cleanups may extend to additional repositories as part of ongoing backlog hygiene, based on clear activity and relevance. Any such efforts will be communicated in advance through a dedicated blog post.

Closure Criteria

We will begin closing issues and PRs that meet the following criteria:

• Pull Requests targeting branches for Capacitor ≤7
  These will be closed to keep development aligned with current release lines. Contributors are always welcome to reopen or rebase their work against the latest version if the change is still relevant.
• Items with no activity in the past 12 months
  This helps remove legacy reports that no longer reflect today’s codebase.
• Issues marked as needing reproduction that receive no update within 7 days
  In these cases, we’ll leave a clear request for reproduction steps before closure. If new details are provided, the issue will remain active. If you need more time, simply comment and we’ll keep the issue open.

These rules are designed to prioritize relevance and maintainability—not to discourage contributions. In fact, we encourage you to update issues if you are still experiencing them.

What’s Next

To give everyone time to review and respond, the cleanup process will begin February 23rd, 2026 — 3 weeks after the publication of this post.  

Between now and then, we strongly encourage the community to:

• Review any older issues they’ve opened
• Add updated reproduction steps if the issue still affects the latest versions of Capacitor
• Confirm whether a pending Pull Request is still actively maintained

Once the review window has passed, we will begin applying the closure rules across the impacted repositories.

Closed issues that are later found to be valid on current releases can always be reopened with updated reproduction details.

Our goal is simple: to provide a clean, focused, and efficient contribution tracker that better serves both the Capacitor team and the broader community going forward.

Thank You

Finally, we want to sincerely thank the entire Capacitor community: maintainers, contributors, and users alike. Your support is what makes this project thrive. This reset is about making sure your contributions continue to have the greatest possible impact, now and into the future. 

We truly appreciate your collaboration and your continued support.