RFC: Unmaintained Plugin Process

[awanlin]

Summary

This RFC proposes a formal, time-boxed process for identifying, communicating, and archiving plugins in the backstage/community-plugins repository that have become unmaintained. It defines two explicit stages — Unmaintained and Archived — with clear timelines, a GitHub Issues-based communication plan, and a rollout approach for handling existing behind plugins when the policy takes effect.

Motivation

Plugin owners are expected to keep their plugins up to date with Backstage releases as a condition of hosting them in this repository. Over time, some plugins inevitably fall behind — owners move on, organizations reprioritize, or plugins become neglected. Without a formal process, this creates a growing tail of stale plugins that degrade the quality and trustworthiness of the ecosystem.

Community Plugins maintainers do not have the capacity to indefinitely chase owners or proactively search for replacements. However, the broader community often has a stake in specific plugins, and a transparent, time-boxed process gives them a clear window to step in — either by pushing their own organization to act, or by volunteering to take over ownership.

This RFC defines the human-facing policy layer that sits in front of the existing technical archive process, which handles the mechanics of archiving a workspace.

The Process

Definitions

• Backstage version: A Backstage release version. Backstage follows a monthly release cadence, so "3 versions behind" corresponds to approximately 3 months of inactivity.
• Version bump: A merged PR that updates a plugin workspace's Backstage dependency to the current release version. A merged version bump is the only action that resets the unmaintained clock.

Stage 1: Unmaintained (3 Backstage versions behind)

When a plugin workspace has not been version bumped and is 3 or more Backstage release versions behind the current release, the following actions are taken:

1. The plugin is marked as Unmaintained
2. The technical archive process is triggered: an archive PR is opened against the workspace
3. A GitHub issue is opened to notify the owner and the community (see Communication Plan)

Stage 2: Archived (5 Backstage versions behind)

If no qualifying action is taken within 2 additional Backstage versions (~2 months after Stage 1), the following actions are taken:

1. The archive PR is merged
2. The plugin workspace is archived

Clock Reset

The unmaintained clock is reset only when a version bump PR is merged for the plugin. An owner stating their intention to catch up does not reset the clock — the merged version bump is required. This keeps the process objective and avoids open-ended delays.

In exceptional circumstances (e.g. a confirmed temporary absence), maintainers may exercise judgment, but a merged version bump remains the only guaranteed reset trigger.

If a new owner takes over and merges a version bump, the clock resets as though the plugin is actively maintained.

Communication Plan

GitHub Issues

When a plugin enters Stage 1, a GitHub issue is opened on backstage/community-plugins. The issue should:

• Be titled: [Unmaintained] <workspace-name>
• Carry an unmaintained label
• Link to the open archive PR
• Tag the current code owners for the workspace
• Clearly state the timeline: when the archive PR will be merged if no action is taken
• Explicitly invite:
  • The current owner to confirm active maintenance by merging a version bump
  • The community to volunteer as a new owner if the current owner is no longer able to maintain the plugin

The issue is closed when one of the following occurs:

• A version bump is merged by the current owner (archive PR is closed; plugin is back in good standing)
• A new owner is confirmed and merges a version bump
• The archive PR is merged (plugin is archived)

Upgrade Dashboard

The existing Backstage version upgrade dashboard already provides visibility into which plugins are behind on version bumps. The archive process should be surfaced within or alongside this dashboard so that plugins trending toward the Unmaintained threshold are visible to the community before a formal Stage 1 issue is opened. The specifics of how archive process status is integrated into the dashboard are left for implementation.

Transition and Rollout

This process does not take immediate retroactive effect.

RFC Timeline

• May 5, 2026: RFC opens for community feedback
• June 16, 2026: RFC closes (~6 weeks of open comment)
• ~June 30, 2026: Two-week window to follow up on any critical comments and complete implementation of the process
• Backstage 1.52.0: Designated as the start version — the unmaintained clock begins counting forward from this release for all plugins

Rollout Steps

1. The unmaintained clock begins counting from the 1.52.0 release. Plugins that are 3 or more versions behind 1.52.0 will enter Stage 1; plugins that are 5 or more versions behind will be archived.
2. Before enforcement begins, maintainers will make a good-faith one-time outreach effort to owners of any plugins already behind at the time of the 1.52.0 release, ensuring no plugin is archived without prior notice.
3. Plugins already at or beyond the 3-version threshold at the time of adoption will not be archived until the new process has been in effect for the full 5-version window from the 1.52.0 start version.

Open Questions

The following are left open for community feedback and are not blockers on the proposal:

1. Clock reset cap: Should there be a maximum number of version bumps without other meaningful maintenance activity before the archive process proceeds regardless? This would guard against owners who bump versions minimally but are otherwise disengaged.

2. Issue template: Should a standardized GitHub issue template be created for unmaintained notifications, to ensure consistent communication and clear calls to action for owners and potential new owners?

3. Pre-Stage 1 heads-up: Should owners receive an informal notification at 2 versions behind — before Stage 1 formally kicks in? This is not proposed as a formal stage, but it could reduce the number of plugins that reach Stage 1 in the first place.

[Sarabadu]

Some thought,

What it means the workspace is archived? Will be moved to a different folder? Only lives on a branch? (I didn't find the current archive process sry I missed it)

As part of the the archive maybe we should also tag the package as deprecated on npm https://docs.npmjs.com/using-deprecated-packages

At the current version pace 2 versions to action between unmaintained to take over by a different owner, do a possible needed work. Maybe the take over should trigger some extension 🤔

[Pike]

I like the idea of clearly denoting and at some point demoting stale plugins.

I wonder if we have the right signals, though. The way I read it, a version bump of a plugin updates the minimum supported backstage version. What I think we want to track is the maximum supported backstage version, right?

My concern is that adopters would need to do a version upgrade of backstage just to get a feature of one of their community plugins, which might not be technically required. That feels like the tail wagging the dog.

Anything coming down the pike with the updates to the release process that blam hinted at in backstage/backstage#32083 (comment) ?

[awanlin]

Edit: added link to the documentation on the existing technical archive process, I though I had it linked but it wasn't, thanks for mentioning it @Sarabadu. Here's the link as well: https://github.com/backstage/community-plugins/blob/main/docs/plugin-maintainers-guide.md#archiving-a-plugin

[hopehadfield]

Thanks for putting this together @awanlin! Here's my two cents regarding the open questions:

1. Clock reset cap: I think so long as the version bumps are merged cleanly, the archival process should not be triggered. It feels like it would be a shame to archive a plugin that works but is only receiving minimal updates. That being said, this might allow the repo maintainers to almost step out completely from picking up any maintenance slack. Ultimately, if a plugin owner only looks to bump versions every three months and nothing else, there could be quite a bit of effort just to get the CI green in order to merge. Hopefully this would encourage owners to either be more on top of the maintenance on a regular basis, or decide they don't have the time needed to own the plugin (and thus pass it off or let it be archived).
2. Issue template: Definitely would streamline the process for maintainers if we had this. I'm happy to work/collab on creating this once the RFC has closed.
3. Pre-Stage 1 heads-up: This feels like a good idea to me. For owners who intend to keep up-to-date but have been busy with some other work for a little bit, a gentle nudge to update is likely all that's needed and prevents any stress associated with being marked as unmaintained.

One question that came to mind - to what degree are we looking to have this process automated? On one hand, it would be nice to have this PR/issue creation be automatic based on the upgrade dashboard stats as it would reduce the load on the repo maintainers. On the other hand, maybe we still want to leave it as manual so that discretion can be used (and to prevent noise in these cases). I think I'd lean towards the latter for now, and perhaps automate it in future once plugin owners are familiar with the process and need less involvement by the maintainers.

[04kash]

I'm wondering whether, in addition to identifying unmaintained workspaces based on version bumps, we should also identify inactive plugin maintainers based on the inactivity criteria outlined here: https://github.com/backstage/community/blob/main/GOVERNANCE.md#inactivity, as suggested in #6019?