On better managing the growing plugins collection
I just recently began working with Vanilla. I like the idea of keeping Vanilla vanilla and leaving most functionality to plugins, but this makes plugin discoverability a major concern.
I had the patience to go through the description pages for the 500+ plugins available for Vanilla 2 and download those that seemed interesting. Then I still had to test them individually, debug those that didn't work (with a lot of help from the posts here), fix some code, etc. With an ever growing collection of plugins, I think the current system to manage and browse plugins could benefit from some improvements to make it easier for developers to find the right plugins and stay away from the wrong ones. Here are my 2 ideas:
- Flag deprecated plugins: Some plugins have been superseded by newer, better plugins that offer the same or improved functionality, written specifically with the newest Vanilla coding standards in mind. Probably a few others have become unnecessary due to Vanilla implementing their functionality in the core, or have become obsolete due to external changes. Which plugins are deprecated isn't at all obvious to those new to Vanilla like me. One could try to rely on the last date updated, but unfortunately there are many very useful plugins that haven't been updated for years. This leads to my second idea.
- Adopt a plugin: Some really nice plugins have been abandoned by their original developers. This can't be avoided, it's the nature of open source. Often, problems with these older plugins are dealt with via unofficial patches (most of them by @peregrine) and solutions suggested here in the forum, but this is far from ideal. Not everyone finds these patches or knows how to apply them. Moreover, this is only maintenance mode. There is no real further development on them, and they slowly fade into obscurity. Wouldn't it be cool if plugin developers could apply to adopt abandoned plugins to continue their development? In my opinion, this would be better than duplicating the old one with a new name, only to create more confusion about plugins with duplicated functionality.
There are many other ways in which browsing the plugin collection could be made better. Plugin categories? Please, share your opinions and hopefully the guys above will come up with something useful.
I will write another rant about the lack of documentation for developers next time 
Comments
https://github.com/vanilla/community
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
Were you able to find the community wiki? http://vanillawiki.homebrewforums.net/index.php/Main_Page
The biggest problem with documentation is keeping it updated.
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
@hgtonight I see you already added some very interesting issues there on GitHub.
About the ideas I suggested, I'm not sure if that's a direction you guys would like to take, so I just commented it here hoping someone else can comment on it.
I'd like to help more. Unfortunately, at most I can fix some basic bugs here and there, but that is as far as my skills will take me. I don't see myself crafting new code for Vanilla, as I am into a very different programming paradigm and have literally no idea about web stuff.
@ozonorojo: Hi, nice to see you care much. Some of your points were already discussed here and waves of improvements have hit the forum.
Still we have not enough people who care here and so we are happy about everyone who wants to join forces. There was a Google drive list done by @peregrine, @vrijvlinder, @hgtonight mainly i think. The Vanilla team has als published the code of the repo if people want to make improvements. I offered help to make the repo mobile friendly but it seemed unheard. And also a lot others provided input and help.
Also important to know is that the Vanilla team wasn't capable to draw more attention to the OS product, but since the last 9-12 months @Linc is quiet active and they are steering much more into stronger openess, tools and access to manage the OS developments. For example Vanilla's development is now open in GitHub and everyone can file issues.
But sure, there is also little tricks sometimes that could make extension repos more usefull. I think that we need some more functionality here like "Send in a translation for this plugin", "Hand your plugin to another developer", "Provide a GitHub link if you also host it there" and so on.
One thing I think is confusing is that plugins now says "Updated June 5 [2015]", but the latest version available of the plugin might be from October 2014. Also since many new plugins authors insist on discussing issues on Github, and also posting new versions to Github. It makes it chaotic for me as a plugin-end-user to get a glance of what the latest version is, what is new, etc. Github-only plugins could perhaps have the "latest plugin version" removed from its Vanillaforum-plugin-repo-entry and only have a link to the respective Github.
It'd be great to see more folks sending PRs to the docs repo: https://github.com/vanilla/vanilladocs (the source of http://docs.vanillaforums.com)
I have been having a look at the docs repo option @linc suggested, but after following the instructions to run a copy locally and managing to build them successfully with npm, I must be missing something. All the links are absolute and relative to the root of the disk drive, so the result is totally broken. Any ideas? Should I specify any path when running the "bpm run build" command? Some option to make path relative?
I'm not clear why you need to have docs running locally. They are all in Markdown - use an editor like MacDown to edit them.