Easier publish flow to "beta in plugin store"?

Developers
#1

Hi guys,

There’s been an increase of offered plugins here, which is great!

I am concerned about these plugin reaching their potential audience though.
What if we could get more people to actually, test, give feedback and promote these community made plugins?

It is a Strength of the platform that we can but it is also a Threat when it is kept as such a black box to many people.

What if we can create a smoother process of these plugins to reach the beta plugins list in the plugin store? Easier access = more potential people to test it and yet again shorter path to 1.0 publish in the live, public plugin store?

I count myself in the part of the audience that is able to manually copy plugins (which a command line refresher to brush up on those skills though) but to be honest, I don’t feel much to grab source code from a git hun an try to get it working on my MOD Dwarf somehow…

It would be SO much easier if I could test plugins right out of the “beta” plugin store; or even some kind of “alpha” store, so I can download from my mod GUI, get it on my board and try it right away.
It could define the role and necessary skillset as “tester” a little better as well and we could create a clear workflow to widen that publishing funnel sooner

What is needed in order to achieve this?

  • more testing of the plugins?
  • Standardization and documentation of tihs process?
  • a “alpha” plugin store in the GUI for this purpose?
  • more support to get people to wrap their plugins with a basic gui to make the UX nicer?
  • more support for people to package to a format that is beta or alpha store ready?
  • A designated “go to market” person acting as catalyst to help people get their plugins through the publishing funnel?
    …?
8 Likes
#2

I kind of feel responsible for the current influx of plugins. :sweat_smile:

I have prepared everything to go into beta though. But the bottleneck here is; the build script pull requests need to be approved by someone from MOD. I think this is a good quality checkpoint, but it takes a while before a new admission is checked. Which is why I decided to drop plugins on the forum before they’re even in the beta store. It would definitely help if reviewing pull requests were more of a priority for the MOD team. But that might be due to limited resources…

For me, it was a learning curve to set up the build scripts to get plugins into the store. But I think it’s fine and inevitable for that process to be technical. The documentation is clear enough. And I think there’s a knowledgable community of people here to help a developer out when they’re stuck.

6 Likes
#3

Yeah, You have a big stake in my impulse; once again thank you foor all of that!

What you mention is exactly what I care about;
a portion of the success of this tech and community ARE exactly these community plugins.

In all transparency; I’m trying to ignite the obviousness of the issue at hand:
How to get YOUR plugins to people like ME in the most fluent way.

As you mentioned; the MOD moderation is a crucial point in the critical path of the process.

2 Likes
#4

I agree, if we can find a way to make it easy for interested volunteers to test plugins, this could act as a pre-filter for the MOD team sign off for beta. Perhaps if there were some semi-formal test procedure/guidelines and a way for volunteers to register go/no-go results the community could be (seen as) a useful resource rather than a drain on MOD resources.

#5

Given the current state of MOD I think the best bet is to create something that doesn’t need the teams input.

My suggestion: Build a tool/website/storefront with all the plugins, rating system etc. that installs the plugins easy enough via ssh but without all the technical stuff.

patchstorage.com essentially was on board to integrate stuff but @gianfranco isn’t really a fan of that.

1 Like
#6

Well no not really. Patchstorage hosts non-reproducible LV2 binaries for raspberry pi.
It would be quite risky to upload such plugins to your MOD unit and more than likely things won’t work or might even break.

#7

of course you have to have the DWARF added as a platform, add the plugins compiled for the Dwarf, done. Then its just create a tool that talks to the api.

#8

There is no way to reliably know that the binaries are what they say they are. The risk remains.

#9

I like the idea of having a simple web tool doing the ssh operations. But including a rating system and other stuff related to beta testing seems a bit much to me (Although nice!). Because I think we shouldn’t want a second, workaround BETA store.

Thinking a bit further, wouldn’t it also be a requirement to be able to get the plugin out? Why not use WinSCP or a similar tool instead of building a custom solution?

1 Like
#10

I’m not sure how the beta plugin review process works exactly.
But I expect the review process to be mostly technical. I expect that once the plugin passes technical requirements (code quality of the build scripts) the plugin goes to BETA. So I don’t think this really helps the MOD team to sign off on beta quicker. But I might be wrong…
Hopefully someone from MOD can chip in.

Not to say that a test procedure wouldn’t be beneficial anyway. If there’s enthusiasm for that, that would be great!

1 Like