Describe the problem you would like to solve
As developers of new features for OJS, we rely on the OJS plugin mechanism to extend all aspects of OJS. It works great. However, if we develop a novel feature and want to test it with collaborating journals, we need the journal administrators to install the plugin manually. This is a hurdle for many because of the technical knowledge and access privileges required. Due to the fact that innovative ideas may be built based on funding from grants, even possibly broadly interesting plugins cannot easily be tested because they cannot be added to the plugin gallery due to the (completely justified) review that submissions receive.
Describe the solution you’d like
I can imagine two paths:
a. Open the plugin gallery to accept also alpha/beta/etc. plugins and transparently tag which plugins are checked by PKP staff.
b. Provide a second plugin gallery, to avoid any confusion, running in a separate GitHub repository, possibly even not managed by PKP but by volunteers, which welcomes plugins more freely, even in early development stages or with limited funding.
In both cases there should be a double confirmation before installation (“Warning, you are installing a not-reviewed plugin…”) and OJS admins should be required to actively enable the community plugin gallery for their journals.
Maybe the community plugin gallery should be a plugin itself?
Who is asking for this feature?
Developers, Journal Administrators
With the expanding community of OJS developers I also think is important to improve the way we collaborate around plugins to facilitate the way we introduce community changes in PKP software. It probably means a change in practices but also a clear documentation.
I think we should make a global plan and then break it down in parts from the easiest/urgent to implement to the les relevant.
About your specific proposal, I need to say that I like it… but only if comes accompanied with a big button in config for admins called “enable non trusted plugins”. Some teams (as yours) are solid, but not everybody in the community work with the same grade of professionalism.
Forwarded this post to the TC channel in mattermost to be included (again) in future conversations.
Thanks for the link to the TC minutes, I was not aware of them. They are really useful because they also outline what is actually part of the review check - I did not find clear documentation on that before.
The “levels of trust” seem to be the right extension point to me and also adds transparency (and even higher trust in official ones) if these are carried through to the UI in OJS.
Our current recommendation for “not ready for prime time” plugins is to use the Site Admin’s plugin upload tool to upload the .tar.gz package. I suspect you’re already aware of that, but if not, it might meet your needs.
Beyond that, I’d be quite nervous about opening up the plugin gallery to unvetted plugins. We don’t have mechanisms in the plugin for review or flagging – like the Wordpress ecosystem does – and when I do review 3rd party plugins for inclusion it’s quite common to come across security flaws in the first round of review.
Perhaps we could give more options for folks who want to do this by moving the URL for the list of plugins from the PHP code into the configuration file. That way anyone who wanted to use a different source for the plugin list could configure it there. It could be easily managed as a fork of the OJS github repository.
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks Alec! Yes, that is the current path. It will not lead to surprise users, though, which might be fine for “not ready for prime time” (I like that perspective).
Maybe it could also be possible to add multiple URLs for the list of plugins? That way a user could add several “app stores” to their OJS, which should be a concept that most users today get. Even if it is just one URL you might want to tag the installation source, so managing multiple sources could be acceptable overhead.
Otherwise forking the original gallery repo of course means that an independent maintainer of a plugin gallery can always update their list to include the latest official plugins. I get this is the smallest footprint on your end, would be great to see this implemented.
For services with a good support I don’t worry about it but thinking about the community it’s essential to label well which plugins have the “PKP seal of approval” and which plugins haven’t gone through this expert review.
Currently this info is already shown when visiting the detailed info of the plugin, but I think it should be even more evident even in the listings (it doesn’t need to be in blinking red, 40px size and with an animated gif of a dancing Homer… but almost :-P) and may be even with a confirmation banner asking “Are you sure you want to activate a third party plugin”?
I understand the need expressed by Daniel, but it scares me to think how some journals can start activating sources (and then plugins) without even knowing what they do, because then the problem is for the support colleagues who have to pick up all the pieces there.
In any case, as long as we’re talking about feature requests, I’m very much in favour of one (or several) improvements in the way plugins are handled.
Several ideas have emerged. Does it make sense to compile a list of ideas and then sort them out and decide whether they are feasible or involve new risks?