I have installation instructions in the README for MacrosOnTheFly, hopefully they are intelligible to people with little experience with Arduino or Git. Improvements welcome. It probably makes sense to have instructions in the Kaleidoscope documentation for how to install 3rd-party (i.e. non-Arduino-Boards) plugins as well.
I suppose there are two possible models for the long-term. One is that Kaleidoscope includes an easy-to-use process for installing 3rd-party (i.e. non-keyboardio) plugins. Maybe eventually there’s a plugin manager (not unlike vim-plug, for Vim, or Antigen, for Zsh) that can automatically download and install plugins from various sources.
The other possible model is that all external plugins eventually get “approved” and added to Arduino-Boards. In this case, keyboardio acts as gatekeeper/curator for 3rd-party plugins, and a default install of Kaleidoscope includes “all” the plugins in the universe. (A comparable model might be that of oh-my-zsh, for Zsh.) Note that Arduino-Boards totally has the ability to include plugins from anyone, without necessarily putting them in the keyboardio org - org membership could be a separate issue from Arduino-Boards membership. Probably Arduino-Boards membership would be a low-ish bar, whereas org membership would indicate which plugins keyboardio takes either partial or complete responsibility for maintaining.
The first model is a little more scalable - if the number of plugins and 3rd-party contributors grows very large, it could be burdensome for keyboardio to approve each plugin, or especially if keyboardio has to approve each plugin update via pull request. However, the second model seems intuitively more keyboardio-like - approving plugins is a step towards making sure users’ experience meets some standard. Note that ambitious users could still always install non-Arduino-Boards plugins manually, but Arduino-Boards would be considered the canonical list of “official” plugins.
I agree that it seems like there should be a few levels of support for plugins. Maybe there are some “core” plugins, which live in the keyboardio org, are actively maintained by keyboardio, and are part of Arduino-Boards and therefore included with every default install of Kaleidoscope. Then “officially supported” plugins, which would be at least partially maintained by keyboardio (in cooperation with plugin author, probably); in the first model above, they would not live in Arduino-Boards so not be installed by default but could be installed with the package manager, whereas in the second model, they would live in Arduino-Boards. Probably these would live in their original authors’ orgs and not the keyboardio org? although I could see that go either way. If an author of one of these plugins wanted to leave, a decision would have to be made which other category to transition the plugin to. Then “community-supported” plugins, which would not be maintained by keyboardio at all; in the first model, they would probably just be in a different section of the package manager, or in the second model, maybe a different section of Arduino-Boards. (Or in either model they could live directly alongside the officially-supported plugins - end users may or may not care whether keyboardio is involved in maintaining the plugin.) In either model, these would not live in the keyboardio org.
Another thing I’d totally like to see is a master list of available plugins (ideally, all plugins in all three of these categories). This goes regardless of which plugin model we use. Even a list with plugin name, plugin author/maintainer, single-line description of the plugin, and link to install would be great; most plugins already have all this info in their library.properties file, so we’d just need to scrape that. The resulting list should be distributed with Kaleidoscope core, or perhaps (to allow more frequent updating) we could just distribute a script or something to pull the latest list. In any case it should be very accessible to end users with little knowledge of Arduino or command-line tools.