We need an overview document describing available, "supported" Kaleidoscope modules.

[obra]

This document should include end-user friendly capsule descriptions of known, moderately-trusted Kaleidoscope plugins, as well as links to those plugins usage documentation.

It should include author and maintainer information for each plugin.

We can probably steal the content from https://asylum.madhouse-project.org/blog/2017/03/10/rose-tinted-glasses/ to get started. (With @algernon's permission)

This issue partially replaces #162

[algernon]

You can steal that content, it's under CC-BY-SA 3.0. I'm willing to relicense it to something else reasonable if another license would fit the result better. (GPL, GFDL come to mind as example licenses I'd be happy with.)

[obra]

CC-BY-SA seems totally reasonable for docs.

…

On Wed, Aug 09, 2017 at 01:53:36PM -0700, Gergely Nagy wrote: You can steal that content, it's under CC-BY-SA 3.0. I'm willing to relicense it to something else reasonable if another license would fit the result better. (GPL, GFDL come to mind as example licenses I'd be happy with.) � You are receiving this because you authored the thread. Reply to this email directly, [1]view it on GitHub, or [2]mute the thread. Reverse link: [3]unknown References Visible links 1. #165 (comment) 2. https://github.com/notifications/unsubscribe-auth/AACxaL7TSBuP_TscfHvjDhriNPVITh1Kks5sWhxQgaJpZM4OynwN 3. #165 (comment)

--

[algernon]

What if we made this automated? Go through Arduino-Boards/libraries, look at the README.md and library.properties, and if the README marks the plugin "stable", include it in the collection. If all our READMEs would follow a similar structure (they mostly do, with few exceptions), that would allow lifting out the introductions programmatically.

The upside of this is that it would be always up to date (and we can add travis badges, last commit info, version number, etc). The downside is that we need to mark plugins stable / experimental / obsolete / whatever. Another benefit of doing it automatically is that we could have a "Supported plugins", an "Experimental Plugins" and perhaps an "Obsolete / Broken plugins" section too, all generated from the same source by the same tool.

We could also add "Community plugins" by going through the repos on GitHub tagged with kaleidoscope-plugin, and collect info from those too.

[algernon]

It could be a bit like travis-status in Kaleidoscope-Plugin.

[algernon]

If we end up with an automatic method, and we write it in JS (as a library) or ClojureScript, that would allow me to reuse the same thing in Chrysalis too. ;)

[obra]

https://kaleidoscope.readthedocs.io/en/latest/#plugins solves this, I believe.