As mentioned in discord, there is some desire to deprecate and remove plugins, but no formal procedure. Below is my proposal for a formal procedure for deprecation and removal
Conditions for removal
Incompatible with last 2 major release OR backend/external API is broken and no replacement/ update planned
No active maintainer, either by own admission or extended failure to respond
Deprecation
A “help-wanted” issue should be created asking for community maintainers to take over development
An meaningful effort to maintain the plugin code should be evident (documentation changes not enough to supplement functional problems)
If no community members come forth as maintainers or no meaningful contributions are made, the plugin will be removed after 30 calendar days
I agree with this. The plugin can always be revived at a later date as it’s still in the git history. I think the proposal probably doesn’t need to be as conservative as it is (in terms of timelines), but that’s more at the discretion of those maintaining the repo.
I wasn’t sure what timeline would be acceptable, since most users won’t spot that a plugin was removed until much much later or when they start having issues with it, so having a quick turnaround is not really helpful. Timelines can always be moved up
Slightly tangential to this point, but I think we should encourage more plugin authors to have their own index. This is already the case for the newer plugin authors such as Serechops, Valkyr, etc. and IMHO it’s leading to better support and hopefully longer-lived plugins.
I believe the original goal was to make it easier for users to find plugins by centralizing them, but putting a plugin into the Community repo unfortunately means that users will expect them to be better maintained because they’re “official”. I fear the current structure actually makes that less likely because pull requests can be hard to review for anyone but the original author, and we end up with “rotting” plugins such as the infamous RenamerOnUpdate.
I agree. The issue from what I have seen is that people are unfamiliar with how to set it up on GitHub/git side. We need to expand on documentation from developer perspective on how to set it up. Right now there is only limited details about it in Plugins - Stash-Docs.
I think this would also be better, to remove duplicate plugins like stats and extendedstats from CommunityScripts into their existing gh repos and indicies
How useful or unnecessary would it be to move deprecated plugins to a new directory to preserve code (even if it’s available in git history already)?
Theoretically someone could then pick up the plugin and start maintaining it. In practice, I’m not sure how common that would be as working on someone else’s code is not ideal.
Moving instead of deleting is acceptable, hiding it from plugin index and being able to give closure to issues and support rather than no response forever is the main goal.
