I think the assumption here is wrong.
The CP directory was intended to be a list of plugins/themes that are available for users. The list needs to be accurate or it’s less useful. But there is no intention to store or maintain the code in the list.
The WP repository actually provides storage space, forums, and visibility in the admin. For that privilege, authors follow the rules. When they don’t, the code is removed.
CP has a roadmap that includes some visibility in the admin, installation and updates for code in the CP directory. But there really is no reason for a mirror or state of emergency over plugins disappearing. It is out of scope for CP to be concerned about external plugins. If, however, this plan for core plugins ever happens, there would need to be a place for those plugins to be stored, and they would need maintenance just like core. (I think splitting things up makes more work than keeping it all together.)
Just one thing to think about: one of the plugin we are talking about was not GPL. Don’t know about the others, but eula.txt in the one I’ve installed it’s clear about it.
If I understand this right we listed non gpl plugins on our directory?
That’s breaking rule 7 of the directory guidelines:
All Plugins must be compatible with the GNU General Public License; using the same license as ClassicPress (GPLv2 or later) is strongly recommended, but any GPL-compatible license is acceptable.
So I guess it’s good it’s gone. If the others also weren’t gpl … then they never should have been available for cp?
I’m not asking to store code
I’m asking to create a git repo where we can mirror plugins and themes so they are available when they are disappearing
That’s all.
I don’t ask to create a code repo from which we can access to in admin or similar.
All that takes as work is:
create a repo
click “fork” as the owner of that repo so to “save” a plugin to the repo (and for that I am pretty sure we could somehow create a script which would avoid all manual work)
Now, done that, assume a plugin disappears, a wiling dev comes along, they can fork it out of the repo and continue maintenance.
As it is now, we also can do that, but a user would have to come forward and ask + share said plugin for someone to pick it up eventually.
Perhaps that’s ok. Since consensus seems to be no such backup repo is needed I’ll consent …
Seems quite simple. And even if you have to manually fork a plugin the first time it’s approved in the directory (it adds very few to the approval process) then a simple cron that uses GitHub API to keep the fork even seems quite easy to set up.
Yes, Tim is correct about the fundamental issue. But managing expectations is actually not that difficult… you only need to tell people what to expect. The problem is that no-one appears to know.
To me, CP consists of a bunch of random people doing random jobs in a random manner. There is no coherent plan of action, no goals, no timeline, no priorities. It is littered with projects that are half-finished, stalled, forgotten or abandoned. Maybe this is typical for open source projects… I don’t know, it’s my first experience. But I can certainly understand why people get disheartened, lose interest and leave.
And please don’t point to the “roadmap” as if it has any answers. It’s not a roadmap. A roadmap is something you can use to plan a journey from A to B. ClassicPress only has a wishlist. It mentions some vague goals in a vague order and basically says: “We hope these will happen some day”.
The result is that contributors work in a sporadic way and have no idea whether their input is important, or somewhat useful or a total waste of time. That’s how I feel now - I spent a lot of time working on something that I thought was a significant contribution, but maybe I was just wasting my time. Who knows?
By the way, I think the plugins under discussion were never in the directory, nor were they on GitHub. They were made available to CP users via a private website.
I agree with plugins being automatically forked (to a private GitHub repository) as soon as they are submitted to the ClassicPress directory.
This is technically feasible, and (in my opinion) ethical as long as we inform developers that this is what will happen and why. I’m envisioning that submitting a plugin would require agreement to a statement that explains that we would use this backup repository in case of the original plugin disappearing and ClassicPress needing to provide a way for existing users of the plugin to receive support/updates.
The plugin directory should provide the ability to change “ownership” of a plugin, so that when a plugin is abandonded, and CP staff changes it over to a new owner/maintainer, existing sites which ask for upgrades would be pointed to the new repository.
For the record… any piece of code that is a derivative work of WordPress (same as CP btw…) automatically lies under the GPL2 license, no matter what the developer of the code says, or suggests otherwise.
So, any theme or plugin, free or premium, one that costs $0 or $1,000,000 once someone obtains that piece of code, because it cannot run as a standalone application, it needs WP or CP in order to work, they automatically come with a GPL2 or later license, and nobody can change that license - period.
And because the license is GPL2 or later, once you get a copy of the said derivative work, you can do anything you want with it. Distribute it for free, sell it, change the code, re-brand it, adapt parts of it in another theme/plugin, etc…, you have all the freedoms in the world !
@James - would you be able to set up said git Repo?
I am willing to - for now and if I get access to it - fork each one of the plugins manually out. We can write the code later, as we have time and go along, there are not 1000 plugins each month in CP, rather like one a year.
So I am even willing to keep this doing manually for a long time, until it become unbearable.
That would move the topic to a “somewhat resolve Status”
Next up is - please - if possible give me access to the plugin directory so I can start doing that work needed in revising and removing/contacting developers with the bad apples, because … it doesn’t move. We seem to be waiting for something, but I am not sure what we are waiting for.
This shouldn’t be too difficult to do as part of the submission process, we require CP plugins to have a repo so we can just fork it automatically. We will want to run it on existing plugins but that should be pretty easy too.
… not what I see happening… and probably also because we say it is not always needed (too many “if” make any rule even less useful than they are by nature)
Would we maybe want to make it strict and “a GIT is required, no matter what”?
Right now we say
The developer will maintain their own GitHub repository for each plugin which will include a stable version of the plugin (as defined by the creation of a release).
It is recommended best practice, but not required, that a release zip is included in a release (added in the Attach binaries by dropping them here or selecting them section).
Plugins defined as “Working with ClassicPress” do not require a GitHub repository, although it is recommended, but source code must be available. Plugins without a repository will not benefit from full ClassicPress Directory and core integration.
In either case, yes, it should not be too hard and I have receive access from James for the repo already, so asap I will start forking out plugins. I will then also add this to the project list under “Plugin directory” as a task.
And while doing that, I would really love to prune the bad apples. I already have the list, while forking I will find more. How can we ensure this time we really remove those plugins? It is been a couple weeks now since we know about them but I have no tools/access to remove those plugins and/or devs, or start contact with them, which perhaps would be the friendly way (one week time, then delete)
Seems logic and in line with the concept of open source. Any person publishing a plugin for the sake of sharing, will not have an issue with this requirement.
Yes, I thought this was always the plan. We should be requiring GitHub at first, with the option to expand to other providers (GitLab, other self-hosted git with some convention for “release” assets) as our development time permits.
This is getting a bit off-topic but it’s not clear to me how/where to split the thread. If someone else wants to give it a shot then go ahead.
It is
It’s the same with other areas of contribution: if you want to see these things, then help make it happen.
One clear challenge is that ClassicPress is “community-led” which means a lack of clear leadership. Still, so far, I don’t think anyone has put serious and sustained effort towards organizing and communicating what we are working on and why.
The CP Plugin Mirror is created and all existing, published plugins of CP are now mirrored into it:
@james - we also need this for Themes (I know we do not yet have a dir for them, but we do in fact have themes meanwhile).
Also, if you don’t mind adding a logo to the organization I messed something around that could be used…
The developer will maintain their own GitHub repository for each plugin which will include a stable version of the plugin (as defined by the creation of a release).
It is recommended best practice, but not required, that a release zip is included in a release (added in the Attach binaries by dropping them here or selecting them section).
Plugins defined as “Working with ClassicPress” do not require a GitHub repository, although it is recommended, but source code must be available. Plugins without a repository will not benefit from full ClassicPress Directory and core integration.
So those plugins which recently disappeared never would have been intended to be added, because their code obviously was not public (neither on GIT, nor elsewhere).
I am wondering if we need to add a mention somewhere in the Plugin Guidelines about our mirroring process?
If so - would this be ok to be added here? Add a last bullet point:
Once approved the plugin will/has to be mirrored in the repository here. This is solely used as a backup and development resource.
I think we should set all of these repositories to private. The reasons being that we should prefer and respect the author’s copy of the repository first, avoid confusion by putting multiple public copies out there, and these repositories should only be used as a last resort by CP staff.
Can we use the same organization for themes and rename it to e.g. ClassicPress-dir-mirror?
Not sure about privatization of the repo.
WPs mirror is also public, and if we consider that we’re the only 2 members there, that adds again to the “access debt” we already have. After all gpl is gpl and the source would be always visible since the fork states where it was forked from
A description would do, imo, clearly stating it’s purpose
About themes, that’s perfect imo, having it all under one roof, so yes
Thanks for adding the ugly logo
Now if we also put themes there I’ll have to amend it, will share the new version asap (I guess just mirrored feathers without icon)
