Criteria for $:/plugins/commons/ namespace

[saqimtiaz]

As discussed recently, a new namespace for semi-official plugins has been introduced: $:/plugins/commons/.

There is a need for documented criteria and guidelines for using this plugin namespace.

Examples of the kind of questions that need to be addressed:

• does a plugin need to be funded by OpenCollective or need the approval of the project maintainer to use this namespace?
• what are the requirements for the plugins in terms of code style, compatibility with older browsers, and stability (as in are prototypes and betas welcome or only finished products?)?
• what is the process for adding a new plugin to the commons namespace (and eventually repository)?

For example, the Github uploader plugin is a quick hack and while it works robustly from a user perspective, the code is sub-optimal in that it uses a large third party library that isn’t actively maintained and will not work with IE (uses Promises). Should that still use the same namespace?

Another example: If on my own time I were to write a WebDAV uploader plugin which might be rougher around the edges, or ignore compatibility with IE and older browsers, should that go in to the commons namespace or not? Should there be a review process for this?

[jeremyruston]

Thanks @saqimtiaz those are excellent questions. A couple more:

• from an end user perspective, presumably the commons would appear as a separate plugin library to the core? Would it be installed by default?
• what expectations should end users have for the maintenance and support of plugins from the commons?
• are core developers expected to verify that plugins from the commons work with the latest core versions?
• might there be scope for a role within the community for a volunteer to act as gatekeeper for the commons? and perhaps to start to think of a distinct core team and commons team to try to ensure that activity and decisions are not held up by the work of the core team

I’d like to hear other people’s opinions on all of this.

[boris]

I think these are all good long term questions.

I would think it is up to the collective of devs who place plugins there to work together to figure them out.

It might be that a plugin library is a lot of overhead to maintain (that is, literally the part that makes it a plugin library — there’s lots of work to maintain plugins over time) — but that a Commons plugin library has devs working together to make it less work.

@jeremyruston

might there be scope for a role within the community for a volunteer to act as gatekeeper for the commons? and perhaps to start to think of a distinct core team and commons team to try to ensure that activity and decisions are not held up by the work of the core team

I think this resonates the most strongly for me, other than the gatekeeper part

Whatever team of people work on Commons will need to define some ground rules, but I think mostly being a person who wants to maintain a plugin over time and get better at making plugins should be the base. You WANT people to climb the hill of becoming better TW plugin developers.

Typically core looks to plugin development to see what is hard or easy (in other systems). Often times, popular plugins make their way into core — and usually with the assistance of the plugin developer.

It is up to the plugin developers to do their own testing with upcoming releases.

[joshuafontany]

All great questions. I’m on board with the Commons group, as I have already begun shifting the name-spaces of my “multiplayer” plugin experiments over to that root. I feel that this is a great way to present things that are “core adjacent”. For example, I have separated out the ability to serve multiple wikis into its own $:/plugins/commons/multiserver plugins, that is simply an extension of the core Server object with a few wrapper functions to store “States” and present the correct “state wiki” object to each server route when it is called. It became it’s own clean little thing, and I can build my Yjs “realtime multiplayer” as a completely separate layer (sperate plugin) that can cleanly replace the TidldyWeb core plugin. Naming these as $:/plugins/commons/yjs for the core yjs libraries and $:/plugins/commons/yjswebsockets for the websocket specific layer.

Should I do a beta release of all of these under my own namespace first? (Having just converted it all from the Bob namespace… I mean, I could…)

I feel these are all needs the community has expressed, and especially for the $/plugins/commons/yjs plugin - which is essentially a repackaging of another library - because others can directly build their own plugins off of that (separate from the websocket logic). For example, YJS that has a browser-only sync layer (WebRTC) that would fit better for a Fission-based clientside-only TW setup.