already in “unstable” See http://ssj71.github.io/infamousPlugins/plugs.html#stuck
Thank you for your submission @ssj71!
@Jarno is currently working on a software tool that can check some of the requirements on the list for promotion. Since the tool is not finished yet, he will be giving us objectively measured data about your plugin that will help determine if it is stable.
On the side of being a worthwhile addition to the store:
- Overall, community feedback has been very positive for your Stuck plugin. (+ I personally like it )
- The GUI is exemplary, it is really nice that it is instantly clear that this is the Stuck plugin.
- The metadata is great, one question though: Why is the range of the Drone Gain *0 to *2, instead of just 0 to 2?
- Although the description would easily be accepted previously, we are trying to “up our game” a bit. It would be great if you could read through this guide and spice it up a bit.
- This are currently no drone plugins available in the official store, and this plugin fills that void perfectly.
Looking forward to Jarno’s test results, and your new description!
that must be added by mod-gui because I have indicated that it is in units of a coefficient. The metadata doesn’t add the *
I understand the desire to try to improve marketing, but I have a few problems with this both practically and technically. Practically, developers are quite bad marketers (at least in the open source world) but you can coach them through this. Some will just not want to bother, but I think those that follow the document will turn out some good stuff.
More problematic IMHO is that you are using doap:description for this which if you follow the link that resolves to is defined as “Plain text description of a project, of 2-4 sentences in length.” That length is pretty blatantly exceeded in nearly all your examples. For those plugins that will benefit from/deserve a more verbose description as you’ve added, perhaps we can promote plugins use an rdfs:comment for the very lengthy version.
The infamous stuck (and all the infamous plugins) do this, though the comment lengths are brief enough that they would be appropriate descriptions. Next time I work on these I will move the description to be doap:shortdesc and the current comment to doap:description, then compose an rdfs:comment following your guide. Can the mod ecosystem use that comment when it is defined?
As a last point, I understand I’m an early case, but I think it would be worthwhile to point developers to this documentation as soon as they submit to the community store, that way when they get to the promotion stage they already know what is required to enter the official store and hopefully will prepare the project to get in without any additional changes.
Please do not recommend nor require newlines or dedicated paragraphs in the doap:description and rfds:comment. Always treat it like running text. Do treat newlines equivalent so space. and multiple whitespaces as single space.
Hi Jesse, brace yourself, for I’m going to criticize the google-doc proposal for I am concerned that some may perceive it as being LV2 cannon.
I do value your time for coming up with the proposal. I do agree that plugins should have good documentation, ideally included with the plugin, but I do disagree with nearly all the points on how the description/doc should be formatted.
- The title: Plug in name without developer, abbreviations or codified terms. (ex. Gx, Rkr)
It makes no sense to add that to the description, does it?
The plugin already has a name, title and author in semantic RDF, properly formatted. There’s no need to add it again.
- Name of the plug in without developer, and direct mention to eventual inspiration models.
- A catchy and impactful short sentence about this model. (only if deserved)
Why only if deserved ?
A tagline or single sentence can be handy. Then again, ideally the name speaks for itself. So “only if appropriate” (not deserved).
- Historical context, legends who used it, main ways of use. (If applies)
Frankly, nobody cares nor should care about historical context when you want to use a plugin.
I also expect this will only lead to false assertions and bias. A user may believe a plugin emulates something while in fact it does not even come close. If the plugin emulates vintage gear it may or may not be mentioned in (5) below.
Furthermore you imply that a single effect can be responsible for the style and sound of [some legend], which is only rarely the case, if at all.
- What it does, strongest characteristics or usages. This is where we must make the greatest efforts in ensuring easy understanding.
Why only “strongest”? IMHO a description should be more like a reference manual and outline all general uses. Specific usage variants can be done with presets (which can also have a description).
- Important considerations such as controls added to the original inspiration or eventual significant modifications (If applies).
- Controls: If not self-explanatory, we should provide quick and simple instructions of what each button does and why using it.
Nope. controls should be documented themselves (the MOD already shows port-annotations in tooltips)
- Features: developer, inspiration model, version etc.
Features should already be mentioned in (5) above, no? Version is already present in the plugin’s RDF.
- Legal: all the legal disclaimers necessary.
There is already a special semantic license field in the RDF for that. Trademarked names in the description can be tagged with ®, ™ as needed.
I highly recommend to focus on 1. write once, 2. don’t repeat yourself.
Also keep in mind that there are other LV2 hosts using the description.
Also all the examples you provide are rather unprofessional (“messing with the gain parameter”) and read like marketing BS (“capture the sound of an era”) to me.
Stuck is in the “stable” now.