It looks like you're new here. If you want to get involved, click one of these buttons!
See https://open.vanillaforums.com/discussion/comment/251825/#Comment_251825 for full comment chain.
TL;DR description of the problem: Lots of addons are subtly broken. Of the older addons, the original authors can't be contacted anymore, which means they will stay broken unless uploaded with a new name.
This topic is intended to facilitate a discussion how to best fix that issue issue.
I've assembled the relevant ideas from the other thread here:
I think right now just being able to mark an addon as deprecated, unmaintained or remove it would be useful. Perhaps including version in the search.
I think there is an issue with other user taking over other's projects, really this is a fork and should be mark as such. A project may have a certain scope. If someone wants to go outside of that it should be a fork. In order not to cause issues, in that respect it should be uploaded as a fork and marked as such.
I like the idea of it being github driven as was discussed before.
Because my personal idea was that if A ) The last update to a plugin is > 3 months, B ) community has indicated it's broken (through the existing "It's broken" button), C ) you have a custom PluginFixer permission (to prevent scammers), you're allowed to contribute to a plugin even if you don't own it (There will also of course be an option for the plugin owner to disable this update functionality entirely).
Then if a user clicks the big "download now" button they'll get the latest version, but there will also be a list available with different versions of the plugin (grouped by author/minimum Vanilla version).
So if user A owns a plugin that requires Vanilla 2.2, and uploads a new version that requires the same version, it simply gets overwritten. If user B would upload an update to user A's plugin, both A's and B's version are available, but if one clicks download now they'll get user B's version.
If user A then subsequently uploads a new version, their version gets overwritten and will become the default to download again (B's version will still be available).
If user A uploads a new version that requires Vanilla 2.5.1 though, there will be three versions available: User A's 2.5.1 one, User B's, and User A's original one for 2.2.
In that way, as a plugin author you also don't have to be backward compatible as much. If a new version doesn't work with an older version of Vanilla, people can still download the old version anyway.
I hope this image helps illustrating what I mean:
Probably be better to get a trusted volunteer to upload fixes to an authors plugin, if the author agrees. there are moderators here, there are admins, there could be a plugin fixer.
Some fixes of plugins are already provided but the author doesn't have the 5 minutes to upload the fixes to the plugin and update the plugin for whatever re4ason, so the plugin fixer could take the 5 minute job to assemble the provided bug fixes.
If this idea has merit and you guys are open to alter the design in the manner I described above, I'm willing to work out a first version. But to be frank, I'll need help polishing the code I crap out to make it up to par to the rest of the code of Vanilla. Which practically means I'm going to need help from either @R_J or @hgtonight since as far as I can see from the Vanilla Github they're the two open source people who have experience contributing to the Vanilla core.
So... would you guys have time to check my code if I get the go ahead to write it? O:)
Of the 800 themes and plugins in the add-on section, probably less than 50 are bug-free and work with vanilla 2.5.1. Many probably haven't worked in years from the comments
Maybe all of them should default to broken. Despite bug reports with corrections, the downloadable code often remains unchanged by author. It would be advantageous if a simple update to downloadable plugin could be made with bug fixes, if the plugin author didn't have the 5 minutes to make the provided bug fix changes that were tested, the new position of "plugin fixer" could update the plugin.
I see a lot of potential abuse when multiple authors beyond plugin authors start adding mods instead of plain old bug fixes. willy-nilly versions and questionable improvements that might break more in the future.
Addons on github have a lot of discussion...
with diverging opinion gridlock.
from github ....
linc commented on Jul 16 2017 • >What would be a reason to remove one of the plugins? •Addon has become obsolete by core changes, another addon, or exterior changes. I think the two 'compatibility' addons may fall in this camp, now. •Addon is broken and no one cares enough to fix it. I suspect Mollom falls in this category. •Addon has issues that are not resolvable or experience has taught us it wasn't as good an idea as we thought. Example: CustomizeText, Whispers. >And it could still serve a) as an inspiration and b) as a code example.
Dead code should be used for neither, IMO. Our ecosystem is already littered with examples that are the opposite of a good idea and/or full of illegible code. Our examples should be our best curated work, not the junk heap.
probably the same standards should be true for addons here
To respond to River's idea, "Probably be better to get a trusted volunteer to upload fixes to an authors plugin, if the author agrees. there are moderators here, there are admins, there could be a plugin fixer.", that's what I intended to say with the custom PluginFixer permission you'd need to fix a plugin: A.k.a. you have to be trusted and promoted by a moderator to become a pluginfixer that can upload fixes of plugins that are not yours. The problem with requiring permission from the author is that for the plugins where it's truly necessary for someone to take over, the author can't be found. That's why I added the requirement that to be able to update the plugin, it had to be at least six months old, and the author can't have logged in for that period either. That at least guarantees that it's an "abandoned" plugin.
Re: "I see a lot of potential abuse when multiple authors beyond plugin authors start adding mods instead of plain old bug fixes. willy-nilly versions and questionable improvements that might break more in the future.", I'd say that if the plugin is broken, any change that makes it work is an improvement. But we can also draft a guide of best practices, which PluginFixers are supposed to follow if they want to stay PluginFixers.
That leads me to x00's comment: I feel with a best practices document, most of your concerns about project forks will be met right?
If the scope of the project is altered significantly, it should be uploaded as a different plugin. If not and the scope stays relatively the same, then people can upload a fix, and the old plugin will still be available for those who don't want the extended functionality.
I like it being github driven too, but I'll say that for the current problem of abandoned plugins it won't help that much. Authors will still have to approve merges of branches on github, and won't do that if they've disappeared completely.