Plugins whose authors do not update them, should be removed

I’d much prefer we go with a GitHub README.md file over readme.txt.

A readme file is not really a great place to embed metadata, but there is a standard way of doing this on GitHub (raw file, rendered example).

5 Likes

I’m assuming we’ll be listing plugins we know work but where we don’t have direct engagement from the author. In that case we’ll need to parse the readme.

For plugins that explicitly support CP I’d like to see the meta in a json file, but now we’re starting to head OT.

But why can’t the developer simply update the readme.txt file to inform the world that the plugin has been tested with the current version?

That is the single point of starting this topic. If a plugin developer cannot be bothered updating the files (if only to reflect compatibility with current versions) then CP should not be bothered to list those plugins.

2 Likes

I agree 100% with @Pieter.

This thread has gone off topic quite a bit. This is, for example, nothing to do with security. This is to do with keeping the directory clean and composed only of plugins whose developers are at least somewhat active.

Several of the comments have also overlooked the significance of the point that we are talking about a directory and not a repository. If a plugin is removed from the directory, that does not mean that its code disappears. Not at all. It just means that there is no link to that code from the ClassicPress website. But the code will still be where it will always have been: on the developer’s Github site.

The effect of removal will thus be to withdraw the developer’s privilege of being somehow endorsed by CP. Current users of that plugin won’t be any worse off, because the plugin will work just as well as it would have if the plugin had remained listed in the directory. Potential future users will not, however, have an easy means of finding the plugin unless and until the developer updates the readme.txt file.

That all sounds really straightforward and sensible to me.

4 Likes

Me too!

We’re going to have plugin dependencies - we need that to make core plugins work; we can mark plugins as unmaintained, we can stop tracking them for new major CP versions, we can flag them as “author doesn’t respond to security issues”, we can even hide them from certain searches - the only thing we cannot do is delete them. We all remember the npm debacle, yes?

Using semver means plugin compatibility will be tied to major versions, which makes the directory effectively self cleaning. If the author doesn’t update the plugin meta for the next major CP version it won’t be listed - simple as that.

The assumption in the WP repo is that plugins that work with e.g. the last release of v3 will work with the first release of v4. Our assumption is the opposite; because we know there will be breaking changes between e.g. v2 and v3, we cannot assume plugins will carry on working.

So, to address the title of this thread directly: no, but they should be appropriately flagged.

4 Likes

Sorry, but this is a complete red herring.

We aren’t talking about core plugins here. We are talking about bog-standard, regular plugins. The only dependencies involved will be those that the plugin needs from core.

Using semver means plugin compatibility will be tied to major versions, which makes the directory effectively self cleaning.

Sorry, but that’s not even close to being true for an ordinary user. A directory is effectively just a list of (CP-approved) plugins. Those plugins stay in that list until removed. If the developer isn’t sufficiently active to update a simple text file, s/he should not get the benefit of having his/her plugin listed. It really is that simple.

No, it isn’t. Once we provide any feature - like plugin dependencies - it will be used, and almost certainly in ways it was never intended for and that we’d never thought of. That’s just how it goes.

Once the facility is there for plugins to define dependencies on other plugins, we are responsible for maintaining that relationship.

I think you are projecting the current WP experience onto what we’re still designing.

For a given search, why would we return results for plugins that we don’t know are compatible with the user’s version of CP?

If they search or browse the website directly we default to the latest CP version.
If they search from within CP we have the CP version so we only list plugins we know to be compatible.

The “ordinary user” never sees listings that aren’t directly useful to them. The “advanced user” can still find what they’re looking for.

3 Likes

Once we provide any feature - like plugin dependencies - it will be used, and almost certainly in ways it was never intended for and that we’d never thought of. That’s just how it goes.

OK, let’s assume you’re right. It still makes no difference whatsoever. An installed plugin will still work, and the code will still be available on the developer’s site. So this argument remains a red herring.

For a given search, why would we return results for plugins that we don’t know are compatible with the user’s version of CP?

You are completely missing the point. This isn’t about what works or does not work. It’s about rewarding plugin developers who are participating as members of the community, while making it clear that those who don’t do so will have their plugins de-listed.

I think you are projecting the current WP experience onto what we’re still designing.

Clearly, that’s not what I’m doing at all. This has nothing to do with functionality, and everything to do with incentivizing developers to keep at least somewhat active.

I agree with the sentiment that we need to reward active developers, but I do disagree with complete de-listing.

If plugin isn’t actively maintained, it needs to simply be marked “inactive” and it will no longer be available for installation inside CP. But, we’re building a directory so there’s no reason to remove listing completely. What’s the point of abandonment policy if our directory can’t show abandoned plugins?

Yes, plugin is still on GitHub, but why are we expecting developers to leave CP.net and go find abandoned plugins on GitHub? We need to keep people on CP.net. They can find abandoned plugins in directory and a link to GitHub repo, so they can fork it if they wish to.

De-listing isn’t necessary and counter-productive. Should only be removed at the request of the developer.

5 Likes

De-listing is necessary for two reasons.

First, if CP is successful, it will be storing up huge trouble for later if we keep a mass of inactive plugins.

Second, despite @invisnet’s optimisim, we at CP cannot control the results of a search. We can control only the results of a CP search. But there is such a thing as Google. And that’s how many users find plugins. If we leave the plugins of inactive developers listed, then we will be seen to be endorsing them, and so plugin developers would have little incentive to remain active. That precisely what happens at present with WP’s repository.

1 Like

Can you tell me if WordPress is endorsing this plugin by having it listed in repo?

This is what I’m referring to. It’s still there, but a clear sign says it’s no longer available. And it can’t be installed.

We’re not hosting source code, it’s a directory. It will be as easy to manage as we design it.

My questions are, if de-listing:

  1. What’s the point of abandoned plugins policy if plugin is already gone from directory and no way to confirm if it’s a fork or not?
  2. What will happen if plugin developer does come back and wants to be listed again? Re-listing? That’s extra work that isn’t necessary.

Also, to add, listing something in your directory doesn’t mean endorsement. Look at Google, I doubt they endorse any of the listings in search results, Google My Business, etc. But it’s still there.

1 Like

No, I don’t think that’s an endorsement. But nor have I understood that as what is meant by being “marked as inactive.” And there’s a good reason for that. Because that plugin was removed not because of a decision taken by those running the WP repo, but at the request of the developer. So it’s simply not analogous to what we are talking about at all.

1 Like

I don’t understand your seeming obsession with de-listing.

I don’t understand why a list of “plugins that worked with v3” is a problem when we’re on e.g. v5.

I don’t understand why it matters how a user found a plugin; the plugin contains meta data, we can check at install time whether we know if it’s compatible.

I don’t understand why, if we have 3 plugins, A → B → C, you feel it’s acceptable to break A and B by de-listing C.

I don’t understand why a suitable notice on the plugin listing explaining it’s unmaintained/insecure/whatever isn’t at least as much incentive as de-listing.

I’m beginning to think we’re not talking about the same thing at all, but I don’t understand what that other thing might be.

1 Like

I’m beginning to think you don’t have the faintest clue what it’s like to be an ordinary user of WP/CP.

2 Likes

I disagree, it’s completely relevant. We’re not talking about who took the action to “close” the plugin. Rather, we’re discussing public’s perception of a listing in CP directory if plugin is “closed” or “inactive”. The warning/label can be whatever makes sense, “inactive” label is just what I call it.

Again I’m curious to see pro de-lesting camp answer my 2 questions:

  1. What’s the point of abandoned plugins policy if plugin is already gone from directory and no way to confirm if it’s a fork or not?
  2. What will happen if plugin developer does come back and wants to be listed again? Re-listing? That’s extra work that isn’t necessary.

I would like to understand your side of the argument for de-listing as it fits within the whole plugin ecosystem.

I’m beginning to think CP isn’t as open as it wants to be. We’re trying to parent users a bit too much. Yes, average users are quiet inexperienced. I deal with them daily providing support, free and paid. Typical users look for plugins inside admin, so if the plugin isn’t listed there most users won’t know about it and won’t be able to install it. Even if it’s still listed, but “inactive”, on CP.net directory.

To add, if they do search in Google, it doesn’t matter if plugin is listed in CP directory or not, they will find GitHub report and manually install it. And if they do find “inactive” listing, so what? They still can’t install it. And most users, even average users, won’t install a plugin that has a warning on it or is very old or has low star rating. They try to stay away from them, they rely on social signals to figure out what plugin to use or not.

2 Likes

Here’s a quick example of what I’m referring to, based on my previous WP example.

No, it’s not the label that indicates that WP does not endorse that plugin. It’s the fact that it has been made completely impossible to install the plugin from that location. If that’s what you are proposing instead of de-listing, then I could get behind that.

But relying on a particular label alone is just not going to cut it. “Inactive” to you and me makes sense; to many users, however, it just means they have’t installed it yet. And we’ll have similar troubles with any other label, especially as we aren’t catering just to those whose first language is English. You can see the problems that reliance on labels causes from all the discussions we’ve had about what being “business-focused” means.

So, yes, if you are suggesting that we prevent installation of an inactive plugin, along with an accompanying message that says just that, that would be fine with me. If you are suggesting that mere labeling is enough, however, then I strongly disagree.

That’s exactly the kind of thing I’m thinking of - the “ordinary user” cannot easily install it, and it’s still listed so it still resolves dependencies.