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.
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.
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.
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.
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.
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:
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?
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.
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.
@viktor I didn’t understood the democratic argument, we created this topic to discuss this and I gave my opinion above.
let’s do this exercise. Type “form” in the plugins search box. Search Results for “form” | WordPress.org
You will get 643 pages of results. Go to the last page and open the detail page of each plugin. You will have plugins updated 11 years ago, 10, 5, 4.
So what’s the point of listing them if CP started in 4.9 ?
If this is about parenting why are we increase PHP version? Let’s give the user the choice to use the PHP version he wants? Of course I’m beeing ironic, some decisions need to be made and talking like we are now it’s part of the process.
My mindset was in the oposite way since for now we are still using the WP plugins API to do the search I was only talking about limiting the universe of change inside the WP repo search.
But we have to draw a line somewhere by default, and maybe like you suggested have an additional option to search for all the plugins available no matter what.
When you have code that can depend on other code (in this case, plugin dependencies), you cannot delete or de-list a dependency without breaking other plugins.
Dependencies will need to be considered before we implement any kind of de-listing or deletion policy, whether this is due to inactivity, security issues, or some other reason.
