Why are dozens of apparently dead/abandoned Beta plugins currently being presented in the MOD Plugin Store? What is the purpose of this?
As an example- all the plugins shown in the included screen shot all lead to a dead end (non existent GitHub page). Shouldn’t this stuff just be deleted? This type of “house cleaning” is important to user experience.
Additionally- why are Beta plugins even accepted for availability to MOD users without a description? IMO, if a dev can’t be bothered to include a simple and very basic description of what their plugin is, it shouldn’t even be published. No? Yes? The STORE shouldn’t be filled with “mystery meat”
I do not get it, most of the plugins from screenshot are AMS, and github is not absent:
Would be great to ask somebody responsible to add descriptions, as no description is surely not user friendly, but are these actually dead, non-working useless plugins to sacrifice?
Actually, I even not sure about links - as soon as lv2 URI is more like unique ID of the plugin, than some actual link, it not really guaranteed to point to a real page.
If we are trying to determine if plugin is dead by it’s URI, then MOD plugins can be (absurdly) considered to be dead as well, for example DS1 URI: http://moddevices.com/plugins/mod-devel/DS1 leads to nowhere currently.
It’ just a couple of URIs from top of my head I know to be like that, for sure there are others.
Therefore, are there more clear methods to determine the plugins eligible for euthanasia?
Like, I understand the point why dozens of undescriptive tuna can plugins might annoy, but:
enabling beta already means that you are seeing plugins that are in Beta for a reason, not being ready for the prime time.
plugin library was supposed to grow, not shrink, so maybe there could be some third way, to improve user experience without reducing the library.
Probably it could be solved as below:
add Alpha channel for plugins like that, as soon as Beta now seemingly raises the requirements bar. People could decide on their own, if they are ready to deal with that quality of Alpha plugins, on their own risk. It just has to be clear that if you do not like what you see in Alpha - it was your own choice, you can always disable Alpha and forget about it.
try fixing plugins,
share the list of plugins in danger for removal and the deadlines
contact contributors and give them some time to fix descriptions, give them opportunity to evade removing plugins
try crowdsourcing these descriptions somehow, like if you are the end user who is actually using such plugin and will be affected by it’s removal - you probably are interested to prevent it from being removed, and know enough about what is it doing to write couple lines of description.
A process has to be in place for anything coming into something like an app/plugin store. I believe MOD has already created such a defined process no?
When you provide access to an app/plugin store/library such as this, you are providing direct access to your product’s customer base to the plugin’s developer. A customer base that the company no doubt has spent enormous resources to connect with via their product. That high level quality and detail must be respected.
Developers submitting their plugins to this process really need to adhere to all it’s requirements or just move on. A dead URL should mean a dead plugin, gone until remedied. A plugin without basic data like a description should be gone (or offline etc) until remedied. It’s the developer’s responsibility, full stop. It has to be. No crowd sourcing, nor additional work by MOD staff who already have their own projects and schedule, little to no additional amount of work should be required or necessary by MOD beyond devising all the requirements of the app submission process and enforcing such.
This product will literally LIVE or DIE by the quality of it’s plugins and all experiences related to it. That BEGINS with the customer’s first contact with the plugin store/library via the MOD UI.
Yes, this includes BETA plugins too, as these plugins can show to MOD users what the FUTURE of the device is going to be like (BETA was one of the first places I looked after getting my new DUO X pedal because I wanted to see if it’s FUTURE was worth waiting for). And so with that in mind- what would YOU like to see in that future?
On a side note- has this whole path into a user’s system via the plugin store and direct remote downloads been looked at from a security risk viewpoint? Would hate for this to become a vector for nasty things.
the point we discussed internally at MOD was to have beta section be only of plugins that we plan to eventually move to stable.
stuff like the MOD convolution reverbs, ChowDSP things, and others as pushed by the community,
anything that is in beta but not being maintained/updated by someone, we would remove and host somewhere else.
I have some ideas on how to do this, having some external site with a “dump” of all the stuff from mod-plugin-builder that still allows to push to a device with a single button.
that would allow us to have the experimental/catch-all area, separated from a proper beta area.
with the idea that everything in beta is worth testing and give feedback on.
Beta/Prod for shiny - polished - good impression - finished product - no caveats - user friendly stuff as I assume @tllk expects,
And some kind of an experimental sandbox, where you can pay with you blood and sanity for the exotic half-baked power features, as a dedicated tinkerer, and have freedom to shoot yourself in the leg if you clearly want that.
Maybe you could just add an additional level of granularity to the store.
Beta: all plugins not considered stable, complete or tested enough enough to be in the official store, but with at least a graphical UI and user documentation.
Alpha: for all other submissions, for very brave users.
I had suggested this before, but this is apparently kind of tricky to implement. It could also give a wrong impression to users still since there are definitely plugins that are not even “alpha” status.
Well, I think almost everybody knows that if something is labeled “alpha” it’s not expected to work well, at least for the vast majority of people, so if you are not a developer or tester for a given plugin you’re not really supposed to switch on the visibility flag in the store.
If there are other technical considerations under the hood, then it’s another matter
Sure. I’d move everything that is currently in beta into such an “alpha” section.
And then selectively bring plugins into Beta that need actual testing and finalization before moving to the main store. (maybe maximum a dozen or so at a time so that they actually get some focus)
The entry of a plugin in the beta section should be managed by the team and announced on the forums just like additions to the official store are, and should both be a reward for a good plugin and a call to attention to the community.
One of these AMS plugins is nothing but an on/off switch, so I think the author(s) started working on something that was not developed past the bare minimum stage. It should not be Beta at all.
