How to make a plugin an "officially supported" one

Software Support
1

In a different thread, I asked about submitting the code of my not-yet-complete plugin (supporting Review Quality Collector aka RQC) to the OJS master branch.

@asmecher replied that

  • the PKP project wants to see more and more plugins in separate git repositories (rather than the OJS repository) and
  • that this was true even for “officially supported” plugins.

I now recognize that I asked the wrong question. The motivation behind it was to save the pain of adjusting my code to the many internal changes that frequently happen in PKPlib and OJS.
I am fine with having my plugin in a separate repo (maintenance may even become simpler that way). The point is to get rid of adjustment changes that are easy for the OJS/PKP developers, but super difficult to me as an outsider.

So my actual question is: What do I need to do to get the RQC plugin promoted to “officially supported” status?

Here are reasons why it might be attractive for OJS to have official RQC support:

  • RQC is about giving reviewers what they strive for the most: reputation. I expect RQC use to become widespread eventually. Supporting it will be an great feature.
  • OJS will be the very first manuscript handling system supporting RQC. This could become a nice item in the PKP history.

Here are reasons why it will not be overly painful to support the RQC plugin:

  • I expect hardly any functional changes once the plugin is functional. The functionality is narrow and the RQC API will have to be super stable, because RQC will need support to be present in many manuscript handling systems and many of them are proprietary and presumably difficult to influence.
  • My code is written in a straightforward fashion and is reasonably commented.
  • If changes in OJS’s workflow require changes to the RQC plugin, I will be happy to help.

Lutz Prechelt

2

Hi @prechelt,

Unfortunately we’re very conservative about adopting third-party code for our own maintenance, as it offloads maintenance work to the core team and centralizes ownership of of the software, which is best decentralized for a strong free/open source community. Think of it like Wordpress – if the Wordpress team adopted themes and plugins, they would quickly find themselves overwhelmed with the work, and the ecosystem would be less healthy.

However, one thing Wordpress does well – that we are working towards – is better articulation of breaking changes, roadmaps, etc., and as a result it’s probably easier to maintain a third-party plugin for Wordpress than it is for OJS.

The move from 3.1.1 to 3.1.2 introduced a breaking change (which we thought long and hard about, as we try not to do this for x.y.z-type releases) – the Smarty upgrade from v2 to v3, and resulting changes in how plugins need to refer to template files (e.g. 630af1 and 8bf068 for Static Pages). If this is the change that tripped you up, I suspect you’ll find that the change was not very complex, but identifying that it needed to be changed was probably tricky. That’s a clear lack of documentation on our part and we’ll try to do better in the future.

OJS 3.2 will definitely have some breaking changes and it’ll be a good test case for us to work with!

Thanks,
Alec Smecher
Public Knowledge Project Team

3

Hi @asmecher,
sigh. OK, I’ll get used to the thought of having to maintain compatibility myself.

Suggestion

That’s a clear lack of documentation on our part and we’ll try to do better in the future.

A good first step might be to include a fixed tag (such as #BRK) in the commit message of each breaking change.
Then you can review them at release time and document them in a compact fashion.

Question

Assume my plugin’s XML snippet says

    <compatibility application="ojs2">
        <version>3.1.2</version>
    </compatibility>

and that’s the latest version I have released.
Assume somebody runs their journal with OJS taken from a recent snapshot of the current master branch (the <version><release> of which currently says 3.2.0.0).

  1. Are there any sites that might do such a thing?
  2. If they are using the RQC plugin in its above 3.1.2 version, am I right to assume OJS would refuse to activate the plugin?
  3. But the plugin would be active when installed with OJS versions 3.1.2.1, 3.1.2.2, etc.?
4

Hi @prechelt,

  1. It’s a big world and someone is probably trying it. But we definitely don’t recommend it – the master branch is currently unstable and we can’t support production use of it.
  2. The compatibility check is performed by the Plugin Gallery before permitting installation of the plugin. Once it’s installed, the check no longer applies. It wouldn’t be possible to install the RQC plugin using the plugin gallery on an OJS master-branch checkout.
  3. Compatibility needs to be specified explicitly and fully, i.e. 3.1.2-0, 3.1.2-1, 3.1.2-2, etc.

Regards,
Alec Smecher
Public Knowledge Project Team