Can it be a requirement that developers have to put in a description?
There are plugins which I have no idea what they do or how they work.
Descriptions would be great especially when I’m looking for something specific or understanding what each control does.
Just something I’ve been wanting.
Many developers really hate writing this sort of stuff. Requiring them to do so probably will just result in push back. I believe it’s already suggested to improve descriptions when a dev submits plugins to be added to the store.
I’d suggest you take it case by case. I personally feel like I write fine descriptions of my plugins, but maybe they make no sense to others! You can contact most of the developers, and if you understand a plugin well enough yourself, perhaps you can contribute to their documentation. I know I sure appreciate any contributions to my projects.
We tried this when we were putting in place the Publishing/Promotion of plugins but unfortunately it backlashed.
The problem is quite clear: the expectations and requirements from musicians are very different than the expectations and requirements from developers and hackers.
We actually already had a good idea about these differences, but we did not expect that some developers would see it as a problem.
Our response to this and other issues is coming in the next days with MOD Labs. Stay tuned
If I don’t see a description and the module has been on-line for months I post my version of a description from what I figured out from using the module.
Others are free to correct my findings and eventually the original developer can take what we made and make minor edits to make an ‘official’ description easily.
I’ve noticed some plugin descriptions are from Wikipedia. I think I saw it on a compressor plugin and the description was the definition of a compressor taken from Wikipedia…
I agree some are generic descriptions but even these are usefull to a person that has never used that kind of effect or sound source.
I would rather have something in the description than nothing.
Agree. Something is better than nothing but it would be nice to have a description that describes what makes that specific plugin special.
that one probably wasn’t special
At work, we have someone responsible for the documentation. It’s not a developer. We also have what we call a Proxy customer. Someone who represents a typical user. A good dialog between us all allows the documentation person to write stuff which conveys the developer’s knowledge of the product in a way that is useful for the user.
Here, we may want to create a mechanism that encourages the creation of such teams for each plugin.
As a start, we may want to allow a way to very visibly flag plugins that the users find difficult to use because of a poor documentation.
That would encourage people to gather as a team around it and to start a good and productive discussion with the developer. One or several people could volunteer to write the doc, based on the decisions the group makes on the wording.
That should not be so difficult. And it benefits everyone : the developer sees their plugin getting more exposure and possibly getting more popular. The users get the info they need. The people helping get credited.
Actually, a Wiki may work well for this.
It is a well intentioned idea, and I hope it happens, but I’m skeptical anything will happen unless the MOD team makes it a priority. To get momentum, I feel there needs to be someone driving the process, coordinating efforts, and validating work. It’s important to have some guarantee that someone ‘official’ will be able to collaborate with you, and that your efforts will have a good chance of getting published to the community in a timely manner.
Given the small team size and relatively small community size, an effort like this could be a good candidate for hack days or meetups where you have a few people working together on a shared goal. “We’ll buy you lunch and drinks if you work on Plugin docs for a few hours!”. I’d guess a lot could be accomplished in that kind of setting, and it would be rewarding for everyone to see their work go live as the event wraps up.
I think it should be okay for MOD to require a description before moving a plugin from Beta to non-Beta…
Sending me off to a Wiki page for a plugin description should only be needed for plugins that need images to teach on what it’s for. Just a short description on the plugin page will work for many plugins. I would just like a line on how this plugin is unique (guitar amp has tremolo feature for example) If the developer wants a training wiki then they can add that web link to the short description on the plugins page.
I was mentioning the wiki as a collaborative tool rather than the mean by which the user access the doc.
I wonder when you’ve seen the last move of a plug from beta to stable?