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)
If you’re referring to plugins mirror, that’s unofficial and done by a third party. Their reasons for doing it are not the same reasons we want it. Our use case is basically an emergency backup, and backups are usually kept private.
Humm… I was certain that’s a wp project, but indeed seems not
I’m still not convinced this should be private. Isn’t the point of it that anyone could / if needed / use it as a backup?
It’s a backup of publicly available code - not of a private website.
If we privatize it, they’ll have to ask and either of the members of the org would have to … I don’t know, share it? Somehow? That’s making it public again.
I just see an additional step if it’s private that wouldn’t be needed. But if consensus is private I’ll go thru the repos and set them hidden
We’re not privatizing the code, that implies ownership. Keeping it private simply avoids unnecessary forks, PRs, issues, etc. It keeps it safe until it’s needed. Like a spare tire hidden underneath the car or in the trunk under the floor panel.
Things we still might want to do as filtered from this thread which I cannot do:
rename entire org to “ClassicPress-dir-mirror” or similar so to umbrella both themes and plugins (altho the mess that creates, I am not sure it is best, because it will mix themes with plugins…)
check way to make the single repos private (if then that is really necessary, there are points in favour of this, like the PR issue mentioned by Viktor above… and yet if the work to do that is too much or simply not possible, I see no issue in leaving this as is)
force beda back to the AI sketchbook and make a nicer looking logo and then upload that (this is what I cannot do and will need again owner help from James), the stuff I provided earlier is ugly AF. I should simply leave this to the designers, but my friend is busy, so I have to experiment on my own
- kind of left my radar).