… 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).