Plugin Directory Rules

With Christmas and my job search now out of the way, I’m hoping to have a bit more time to spend here.

To that end, unless anyone objects (or wants to do it), I was thinking I could go through the WordPress documents around plugin submission, maintenance and adoption and put together some new docs for ClassicPress.

Obviously these would be first drafts to be reviewed and updated as required by the community here.

6 Likes

That would be a fantastic start!

If you post it here we can make it a wiki so we can update as required :slight_smile:

First draft of the rules are below:

The ClassicPress Plugin Directory is intended to be a safe one-stop source for all ClassicPress compatible plugins for all types of user, from the non-technical end-user to the developer.

The following rules are intended to provide transparency around the plugin submission process for developers who submit their plugins to the directory; further the rules aim to provide consistency and a level playing field for all developers.

If you have suggestions on improving the rules, or questions about them, please contact the plugin moderators at [email protected].

  1. All developers, users with commit access and all who officially support a plugin are expected to follow the ClassicPress Plugin Directory Rules.

  2. All developers will ensure their contact information is accurate and up-to-date.

  3. Developers must take a security first approach to their plugins and ensure their plugins are as secure as possible.

  4. Plugins may not contact external servers without explicit and authorized opt-in consent from the user. Documentation on how user data is collected and used must be included in the plugin’s readme along with a clearly stated privacy policy.

  5. Free/Freemium/Premium plugins are all welcome in the ClassicPress Plugin Directory, but must be identified as such by use of the appropriate tag. Software-as-a-Service must be categorised as a Premium plugin.

    • Free - completely free, un-crippled, and not soliciting in any way.
    • Freemium - some functionality free, but some requiring payment to plugin developer.
    • Premium - paid, with no functionality available otherwise.
  6. All Free 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.

  7. Where a plugin includes GPL-licensed code, the plugin must fully adhere to the GPL license.

  8. Developers are solely responsible for the content and actions of their plugin and must not do anything illegal, dishonest, or morally offensive, including exploting loopholes in the Plugin Directory rules. Furthermore, developers must respect trademarks, copyrights and project names; including such terms in the plugin name may be acceptable depending on use, but never at the start of the name.

  9. Only completed plugins are acceptable for submission to the Plugin Directory. Incomplete or misleading submissions are not permitted.

  10. All files within the plugin must adhere to the rules and the developer will, prior to submitting their plugin to the Directory, confirm the licensing of all included files (including all code, images, etc.) and that the terms of use of any services or APIs called by the plugin are met. If this cannot be done, the plugin should not be submitted.

  11. Each time code is updated in the repository, the version number must be incremented. Frequent updates are not acceptable and will be seen as an attempt to game the search results; only release ready code should be committed.

  12. ClassicPress ships packaged with libraries such as jQuery, Atom Lib, SimplePie, PHPMailer, PHPass, etc.; plugins must not include their own versions of any standard libraries.

  13. Developers will act in good faith and will not restore code they were previously asked to remove or write code to circumvent the rules.

  14. The developer will maintain their own GitHub repository for each plugin which will include a stable version of the plugin.

  15. Code must be human readable. Obfuscating code by use of systems or techniques such as p,a,c,k,e,r’s obfuscate feature, uglify’s mangle, or unclear naming conventions such as $abc123, is not permitted in the directory.

  16. Publicly facing pages and files, such as Readme files, must not be used to spam users or game search results.

  17. Only critical or highly important notifications should be displayed outside of a plugins settings pages; adverts are not permitted outside of the Plugin settings pages.

  18. Plugins must not include credits or links on the public facing site without explicit opt-in permission from the user. Free plugins may not require permission for plugins to function.

  19. ClassicPress will maintain the Plugin Directory to the best of our ability, but reserve the following rights:

    • To update the rules at any time.
    • To suspend or remove a plugin from the directory for breach, in word or spirit, of the Plugin Directory rules.
    • To allow new, active, developers to take over an orphaned plugin (see adoption rules for further details).

Failure to follow the rules, or respond in a timely manner, will result in a plugin being suspended from the directory until such time as the issue has been resolved; repeated failure to follow this rule may result in all a developer’s plugins being removed from the directory and the developer banned from future submissions.

If you are uncertain whether a plugin might violate the rules, please contact the plugin moderators at [email protected].

5 Likes

Another great job on this one, @azurecurve! These sound like a logical set of rules and I pretty much agree across the board. A few additional thoughts…

#5 Free/Fremium/Premium plugins are all welcome in the ClassicPress Plugin Directory, but must be identified as such by use of the appropriate tag. Software-as-a-Service must be categorised as a Premium plugin.

Even though I want to offer plugins under a model that most would consider freemium, I wouldn’t include it as a category. To avoid inconsistency in interpreting the infinite possibilities of what may constitute freemium, I think the line between free and premium should simply be black and white: if a plugin 100% works without any form of consideration, then it’s free. Otherwise, it’s premium. I believe users will quickly become accustomed to the idea that they can use the free features of a premium plugin without it being called freemium.

#11 Each time code is updated in the repository, the version number must be incremented. Frequent updates are not acceptable and will be seen as an attempt to game the search results; only release ready code should be committed.

The term frequent updates is subjective and needs definition. What constitutes frequent to one plugin shop may be an eternity to another. To prevent gaming, last updated date might be avoided for sorting purposes.

#17 Plugins should not hijack the ClassicPress admin dashboard with constant or overwhelming notifications and alerts; adverts are not permitted outside of the Plugin settings pages.

The phrase constant or overwhelming notifications and alerts is subjective and needs definition. The idea of plugins only printing notices on their own pages is something that seems long overdue. Big +1 on that!

2 Likes

I’ve updated 5 based on feedback here and in the Plugin Directory Structure thread.

For 11, what is an acceptable commit? If a Latest plugin page is available, should this only be showing new and not updated plugins? In which case, does this rule matter? WordPress have it because they generate a zip file on each commit as it is their repository.

I’ve updated 17; I think sometimes it is appropriate to have notifications on the main dashboard page? Is there a consensus on this in one direction or the other?

My two cents:

11, I think leaving some subjectivity is okay but understand @anon71687268’s point (would love some more input from others on this).

Additionally, I would like to see us enforce the semantic versioning we are using for CP onto plugins as well. Meaning fundamental changes in the plugin have to be classified as such.

17, I think we need to say that dashboard notifications should 1) be dismissable, and 2) be unintrusive. That should be clear enough while also leaving the plugin review team some flexibility.

I am afraid that I completely disagree with @anon71687268 about the need for a freemium category. I think it’s absolutely essential.

As a user, I never consider using any premium plugin that I cannot try out first. So the distinction between freemium and pure premium is very important to me. I can investigate those in the former category, while completely ignoring the latter. If you merge the two, you are expecting me to have to go through each one to find out which form of offering it is. That negates a major part of having a directory in the first place. There is certainly no benefit to users in merging the freemium and premium categories.

But there is no benefit to developers either. In fact, if you merge the two, you take away any incentive for the developer to offer a free version, while also disincentivizing those who want to offer a free version from having a premium upgrade.

So I think it’s essential to stick with @azurecurve’s original idea of three categories: free, freemium, and premium. Transparency is fundamental here just as much as it is with every other aspect of ClassicPress.

2 Likes

I also think that is important to have the Freemium category and why I think that being an author of a Freemium plugin?

I think it’s more important for the user than for the author, for me it doesn’t make a difference because there are always other ways to tell the user that there is a premium version with more features.

Why is it better to download a Free plugin that has a Pro version vs Just Free version?

Probably it has better support since there is a premium version that keeps the money rolling so both versions (Free and Premium) are actively developed and supported. So its a more stable solution that helps the user to decide.

At the end of the day is about giving options to the users, and having a Premium version of a Free plugin is always cheaper than customizing the Free version for specifics(that sometimes still happens with the Premium version).

And if the hosting is made in Github don’t see any problem of having also the Premium versions.

1 Like

For what it’s worth I also agree with having a freemium category. I use a lot of plugins that are just that and pay for the extra features on sites that need them.

Would you exclude a plugin such as Elementor simply because it has optional upgrades?

I can update 17 to include these requirements.

I’ll wait for more on 11 before making any changes.

1 Like

I’m happy to add back Freemium to the rules,if that is the way the community is leaning,but don’t want to keep toggling between them.

1 Like

Let’s have a poll on it on it.

How should the categories in the plugin directory be broken down?

  • Free, Freemium, & Premium
  • Free & Premium only

0 voters

In the second option, freemium plugins would fall under the Premium category.

Note: this poll is to see which the community favours, and is no way an official vote. It is used to allow the community to join in on this discussion without the fear of choosing sides.

Edit: edited for clarity following feedback, the edit is made available so you can see the original.

3 Likes

To me, the difference between premium and freemium is semantics. Update: I meant interpretation, not semantics.

1 Like

To me, “freemium” means “this plugin has some features that are available for free and some that are paid”.

“Premium” means “the entire plugin is paid and does nothing (you can’t install or use it) unless you’ve paid”.

5 Likes

This is the definition I use.

2 Likes

I’ve done away with the freemium verbiage on my end in favor of using the term premium, but am happy to wait until the directory opens up to premium plugins.

1 Like

Maybe I’m wrong but for me the Freemium isn’t about the plugins, it’s about the business model. Freemium is a business model, not a plugin version or something like that.

Just like Google that has their Free stuff and try to upsell the premium features.

In terms of code doesn’t make sense to include blocked features(and it isn’t allowed in the WordPress repo) to potential thousands of people that will never use that code.

So usually there are 2 versions. The Free and the Premium. That’s my POV.

4 Likes

I disagree with the logic (to me, Google is a premium service even though it’s free; it costs your data, habits, etc.) but do agree with your conclusion. The way I want to do it (on my end) is to offer all my premium plugins for free (premium, because they’re exceptional quality, not because they cost money) with the option to upgrade to a paid version for those who want more features or even just to support the work.

1 Like

My mind was talking about that Google that maybe 15 years trapped us with the Free Email, etc. At that time all seemed beautiful and “Free” :slight_smile:

1 Like

I figured. :slight_smile: The old adage applies, “If a service is free, it’s us who are the product.”

3 Likes