A systematic way to remove or avoid outdated/broken Community plugins

Basement
1

I know there’s a process for reviewing & approving plugins for the Community Plugin list. Is there a process of reviewing them for continued inclusion? (I searched for threads on this – sorry if I missed anything.)

Use case or problem

I’ve followed links to some plugins that the author pulled when they broke or became outdated. But I’ve run into more that the author hasn’t had the chance to fix. A plugin may be essentially unusable and/or break core Obsidian functionality. The author might not be available, or they might say “pull requests welcome.” But the plugin remains in the shop, available to the unwary user.

Current workaround (optional)

We can see the “Updated” date when browsing plugins, but who knows – it might still work perfectly after 2 years, or it might cause bonkers behavior, or it might have never worked quite right from the start. The obvious workaround is to check Github for the age, number, and nature of open issues before installing anything, but that’s not a reliable indicator for newer or more obscure plugins.

Proposed solution (optional)

Of course I’d like Obsidian to test and review all Community plugins on a rolling basis. LOL. There are 1300 plugins and counting.

It would be nice if there was some gauge of compatibility/quality within the plugin listing, to indicate to users–and to Obsidian–that the plugin may have become questionable. But I’m not sure how one would go about that.

It’s tempting to suggest user reviews within the plugin directory. Apple’s App Store reviews are a trash fire of deceit and irrelevance, and Apple can’t solve that problem. I think the current Obsidian user base and environment are better than that, but maybe it’s asking for trouble in the long run…? I dunno.

The Github API can query for open issues count, but a popular & current plugin could have tons of “issues” that are just pet feature requests, so a raw number isn’t helpful. Could an LLM poll and process all open Github issues for approved plugin repos, evaluate their frequency and nature, and raise a flag at a certain threshold?

Related feature requests (optional) In conclusion…

Apologies if I’m retreading ground. If there’s already a process, I’ve probably hit edge cases that slipped through.

If there’s no process – well, at the rate things are going, we may end up with thousands of plugins to sift through, and I’d be concerned that leaving it at caveat emptor could eventually degrade the whole Obsidian experience and reputation.

1 Like
2

There is a process that’s more modest than what you describe. Plugins may be removed if they are determined to be both broken and unmaintained.

1 Like
3

I wonder if my post on remotely-save was the inspiration for this thread. remotely-save according to the plugin manager hasnt been updated in 2 years, although the thread for the plugin seems to suggest otherwise. i am quite confused.

4

Ah, thanks!

Followup: What is the process?

5

I don’t know the details, I just know they maintain a list of ones that might need to be removed at some point.

6

i am the author of remotely save.

i just wanna say the plugin was not outdated / broken. it has some bugs (as every software!), and sometimes users use it incorrectly and report “bugs” incorrectly.

And i am updating and releasing many new versions these days.

you are welcome to give it a try.

1 Like