Reminder: Developers Must Comply with the FORUM Guidelines

The forums team has notified us of an uptick in developers unnecessarily reporting posts and reviews. This post is to remind you that if you chose to use the WordPress.org support forums and review systems, you are required to comply with their guidelines.

This means abuse of volunteer services, or misusing the ‘report this post’ feature will result in formal warnings from the plugins team. If the behaviour persists, your account will be suspended and your plugin closed. This includes directly asking forum moderators to remove reviews via Slack DMs. Yes, we know.

We know that sometimes people leave really annoying reviews that are frustrating and inaccurate. But attacking your users, calling them names, claiming they’re fake, and reporting the review is far less helpful than you might think. Bad reviews, reviews that should be support, and angry users are a part of maintaining a plugin. It’s the annoying part, and no one likes it, but if you’re giving your plugin away for use, people are going to have opinions.

A review is someone’s opinion of your plugin and the experience using the plugin.
A bad review WILL NOT BE DELETED. Negative feedback reviews will not be reviewed.

The only time a review is removed is when it is, of itself, in violation of the forums guidelines. Not liking your plugin is not a violation. It’s just someone who doesn’t like your plugin.
Please try to be more respectful of the volunteers’ time, and don’t needlessly flag forum posts and reviews for moderation. If you’re not sure if something is a violation, you can come to Slack and ask in the #forums channel.

Trademark Enforcement

Many of you have received an email from us regarding plugin closures for trademark violations. These emails were absolutely not made in error.

Due to recent demands by trademark owners, we will now be more strictly enforcing trademark abuse when it comes to plugins. While it should be sufficient to tell you “Don’t abuse someone’s trademarks.” the reality is that those things are complex and confusing.

We will have altered our system to prevent the submission of those plugins that violate trademarks. This is not something we do lightly, however we have been compelled to close a great many plugins recently. It’s more efficient to prevent potential abuse than to clean it up after the fact.

How Trademarks Apply

Trademarks apply to the following aspects of your plugin:

  • The Slug – Your plugin slug may not begin with someone else’s trademarked (or commonly recognized) term
  • The URL – You may not use someone’s trademark in your domain name
  • The Display Name – You may not begin the display name with someone else’s trademarked (or commonly recognized) term and, in many cases, you may not use the name AT ALL.
  • All Images – You may not use trademarked logos/images in your banner, screenshots, logos, etc

We do our best to take care of the first one – the slug – when you submit your plugin. Plugins approved pre 2015 with trademarks in the URL are ‘grandfathered’ in and permitted to remain. All plugins approved after 2015 are required to meet this restriction. All plugins, no matter when they were approved, must comply with trademark usage in display names and images.

We also keep our eye on similar names. There’s a concept known as brand confusion, so naming your company or plugin similar to another company (like Facerange, say) you can still be legally compelled to change the name. This is why, for example, you cannot use ‘pagespeed’ in your URL for a site optimization tool, even though Google’s only trademark is on ‘page speed’ (two words). The name is similar enough that we have been required to close plugins.

Additional Restrictions

In addition to the above, many brands have an above-and-beyond requirement. You must also avoid representing the brand in a way that:

  • Makes the brand the most distinctive or prominent feature
  • Implies partnership, sponsorship or endorsement
  • Puts the brand in a negative context as part of a script or storyline

Also many have statements like this when regarding applications specifically:

  • Don’t modify, abbreviate or translate the brand name to a different language or by using non-English characters, or use any logos to replace it.
  • Don’t combine shortened versions of the brand with your own brand.
  • Don’t use our ‘wordmark’

This is where it all gets crazy weird. But an example would be the brand Facerange. With the above restrictions, naming your plugin (which is an application) “WordRange” or “FacePress” and having it be a plugin to work with Facerange would be a violation of their terms.

It all comes back to making it painfully clear that you and your work have NO relationship to their products. Some allow you to use their product name wherever you want, and some won’t permit it at all. When in doubt, the best course of action is to assume you don’t have permission and not to use it.

Quick FAQ

Can I use ‘for BRAND’ in my plugin display name?

Sometimes. It depends on the brand. We don’t have a complete list, which makes this very complex. It’s important to pay attention to the rules for brand usage and application uses. Some brands have separate rules. In general, if they’ve trademarked their wordmark then no, you cannot use it for an application. And yes, a plugin is an application.

What’s a wordmark?

That’s the name. So Facerange’s wordmark would be “FACERANGE.”

I have permission from PayBuddy to use their wordmark/logo, is that okay?

We’d rather you not use it on your PLUGIN pages. It’s impossible for us to verify, and many agreements with brand owners are rescinded. Brand your webpage all you want, but leave their official logos and word marks off your plugin.

A brand contacted me directly and asked me to change things. Is that a real demand?

More than likely they are. They’ll usually include links and directions and contact information. Use that and comply with them, because if you don’t, they’ll come to us.

What about existing violations?

We’re handling them in batches. You don’t need to report them to us.

But if you haven’t closed them, why are you closing my plugin?

Because there are thousands of plugins and we do them in small batches for sanity. Also brand owners sometimes give us a priority list, and you just happened to be higher than someone else.

Don’t they get an SEO boost?

No. Write a better readme that uses the brands properly and contextually, and you’ll be fine.

Someone’s infringing on MY brand, what do I do?

Contact them first. Ask them to stop (nicely please). Link them to your brand documentation. If they ignore you, email us the same. We’ll close the plugin until they fix it.

We recommend you BE CLEAR about what you require. Remember, most people aren’t familiar with trademark laws and their intricacies, so it’s very easy for them to get confused.

#guidelines, #trademarks

Proposal to Modify Plugin Guidelines

This post is a proposal of changes to be made to the Plugin Guidelines.

The majority of changes are intended to address significant issues faced by ESL (English as a Second Language) developers. This proposal also contains a significant rewrite to the lamented 11th Guideline (hijacking the admin dashboard).

This proposal will remain open until after WordCamp EU 2019, at which point it will be closed and either re-proposed (if there are significant changes), implemented, or scrapped.

The rest of this post will go over an overview of intent, the proposed changes (with summary), and information as to how to contribute. All community members are welcome to participate.

Continue reading

#guidelines, #proposal

The Proposed New Guidelines Must Be Revised

Following WCEU and in reviewing the number of changes people have brought up regarding the proposed new guidelines, I have determined that they will need some more work and a re-proposal in the coming months.

The main issues people have raised are:

  1. Limiting what kind of notices are permitted unbalances the state in a manner that would give an unfair advantage to larger plugins, or developer that have multiple plugins.
  2. Permanent dismissibility is really easy to work around by using content spinners or just changing the language slightly. That would be impossible to monitor and wouldn’t help users at all.

In addition there were a LOT of small language fixes involved in the process, which I feel should be re-reviewed from the top down.

In the coming months, I’ll be making a new pull request with a new attempt at this, taking all that advice into account.

Thank you everyone for your help on this! It’s not an easy process to craft guidelines that are equitable and understandable, and I hope we’ll have a better version soon.

Don’t Get Scammed

There’s a company who regularly emails people telling them that for $50 or $100 they’ll review your plugin or theme and you’ll get 5 star ratings on WordPress.org. They’ll tell you that doing this will get you SEO and traffic and they’ll link to their domain as proof of their success.

They’re lying.

Don’t fall for this. Never pay anyone for a review, it’s all a scam and the worst case scenario is that they actually do write a review. Why is that worst? Because if we find out you paid for reviews, we remove your plugins from hosting.

If you got a mail from a certain company offering a Valentine’s sale, know that we already know about them. They’ve been banned from here for years but we’ll be monitoring reviews just in case they slip through.

#reminder

Reminder about Behavior

This really shouldn’t need to be said however, based on three recent incidents, it is clear we need a reminder.

You are responsible for your own actions and choices. If you decide to do a thing, you are assuming responsibility for the outcome and, like it or not, the repercussions fall on you and you alone.

When you work with a team of people to support and maintain your plugin, everyone is required to follow the plugin and forum guidelines. Choices made by the team will impact the group as a whole, for good or ill.

Recently a company was banned due to having never briefed their employees on the plugin guidelines. This led to a new, un-monitored employee, egregiously violating the guidelines, harassing and abusing the volunteers of the forums as well as the end-users, who were just trying to get help with the plugin.

The company had been warned about this kind of behaviour before. In fact, they had been issued a final warning. As this was a repeat of the exact behaviour they’d been warned on, their plugin was closed and the company prohibited from hosting anymore.

Sadly this isn’t the only time that’s happened in the last 4 months.

If you work with a team of people, the company/group is responsible for each other. If one person in your group/company violates the guidelines, it’s the whole group who will suffer as you’ve demonstrated an inability to manage your team. The same is true if a rogue intern or SEO marketer spams the forums. They’re doing those actions in the name of the company, which makes the company accountable for their actions.

Don’t hire random people from companies like Fourer to do your marketing. Don’t let people loose in the forums without making sure they understand the guidelines and our expectations.

Abuse, name calling, harassment, stalking, and spamming the forum moderators is not permitted behaviour by anyone. Users are banned for this, and developers will find their companies and all plugins similarly removed. We feel it’s unfair of people to put the burden of monitoring and managing their team on the volunteers of the forums and the plugin team. This is especially true of companies.

Please make sure the people who work with you understand not just the guidelines, but the stakes. Quite often we find an enthusiastic intern is the cause of sockpuppeting, or a well-meaning SEO consultant who took the wrong lessons to heart and made a readme filled with spam.

If we have to contact you multiple times about your behaviour, or that of the people you’re working with, we’re simply not going to permit you to use our services any longer.

#guidelines, #policy, #reminder

Year End Summary – 2018

Well 2019 is almost here so it’s time to look at a years worth of plugin reviews.

Everything

Here’s the chart of everything for the whole year. That gap in January-March is due to a snafu in the system. It wasn’t properly recording anything, so we weren’t able to collect stats.

Highs and Lows

Due to the above gap, our ‘least’ for the weeks are a little off, but you’ll get the general idea of how much we review a week:

Requested Rejected Closed Approved Pending
Most / week 281 99 1171 149 730
Least / week 101 2 9 36 566
Average / week 164 21 341 87 651
YEAR TOTAL 7095 1062 13034 3752 566

What it Means?

We can see that roughly 52% of all submitted plugins are actually approved.

Why are only about half of all plugins approved? I could give you a lot of math explanations, but the crux of it is this: people don’t reply to emails.

Around 35-40% of plugin submissions are pended, either for more information or for code issues, and the majority of those simply never finish a review.

This year, though, we have an abnormally high number of closed plugins (see those gold spikes). This comes from a lot of cleanup of unused plugins (ones where code was never committed) as well as plugins with email-bounces. Due to GDPR, many email servers changed their reporting so we’re finally getting some accurate data on bounced emails.

Of the closed plugins, about .003% of developers reached out to us about them, and of those, the majority were because emails were out of date. This is why I’m always harping on people to make sure their account emails work and don’t auto-reply or bounce.

If your email bounces, we’re not going to email you or hunt you down to figure out who’s supposed to own a plugin. It’s not an efficient use of our time for people who aren’t maintaining their accounts. We’re aware it’s not very nice, but since our accuracy rate is well into the 99th percentile, it’s more effective to close the plugin.

What’s the take away from this? Check your emails. If you submitted a plugin and didn’t get an automatic reply telling you it was received and what the plugin slug was, then you’re having trouble getting our emails and you should add plugins@wordpress.org to your email’s never-spam list. If you did get that email, count 7 days from that. You will have another email from us by then, either as an approval or a rejection (which always comes with a reason why).

Bounces, AutoReplies, and You

Over 150 plugins were closed during WCUS due to auto replies, bounces, and confusing plugin ownership.

In our plugin developer expectations, we say this:

It is the responsibility of the plugin developer to ensure their contact information on WordPress.org is up to date and accurate, in order that they receive all notifications from the plugins team. Auto-replies and emails that route to a support system are not permitted as they historically prevent humans from addressing emails in a timely fashion.

Your email has to work. If we can’t get a hold of you, we’re going to either remove you from your plugin or, if you’re the owner, close it. This is especially true if we can’t figure out who’s meant to own a plugin, or the ‘official’ company account is bouncing.

If your email sends an auto-reply, or a partial bounce (that is, you have a group email and one address in the group bounces) we ALWAYS email you with as much detail as needed to resolve the issue.

Since we sent out a mass email in October, pre 5.0, and another last week, we had a 50 day window for many people to correct the issues.

Let’s hit up some of the reasons why we do this:

Auto-Replies are a bad developer practice

Two reasons, besides the fact that they’re spammy, that a developer account should never auto-reply:

1. Security
2. Communication

Security is the biggest. An auto-reply generally comes from a SUPPORT account. A support account should NEVER be receiving our emails because they’re likely to be related to insecurity in your plugins. We don’t 0-day you, ever, that would be cruel. We want you to fix things ASAP, though, for your users, and if support gets that message, now you have more people, who may not understand not to tell customers about the problems. Also we have no way to be sure the developer got the email. You’re trusting support to escalate properly every time.

Communication is obviously related. We’ve got to be able to get a hold of you, and putting layers between us and you isn’t going to help.

Auto-replies cause developers to not get notifications

We actually DO inform everyone about the status of auto-replies. Once we determine what plugin causes the reply, we email everyone with commit access (i.e. your developers) that there is a problem and to please resolve it. The fact that a high number of you aren’t seeing those emails is indicative of the problem.

Developers aren’t support

For the majority of plugins, this is actually not true. That is, most people are developers and their own support. But those aren’t the people who make auto-replies. The people who have auto-replies tend to be companies. And for a company, there’s a reason they want the auto-replies for people contacting support. That’s perfectly sensible.

The disconnect here is that we expect the people who have commit access to be developers. We

Thankfully we have a solution for you! You can add your support users as Support Representatives for your plugin!

WordPress isn’t your user

All of that said, having an auto-reply on the account you use here to manage your plugin and support your users creates a poor experience. People can’t email you from WordPress.org and while you can chose to get emails for all new posts in your plugin’s forum, having that sent to an auto-reply is rather odd. Why would you want to auto-reply to an automated notification email?

Shared accounts are dangerous

This goes back to security. Don’t share accounts. NEVER share accounts. Give developers individual access to commit code. Add support reps individually. Doing this gives you an easy way to track who commits what code, who answered what question, and you can now hold them accountable for their individual actions! Got one support tech who goes off the rails? You can explain that it was one person and you’re handling it. Or the forums team can help you block their account if needed.

Bounces are harder to unravel than you think

Sometimes a bounce is obvious. If a user no longer exists, we can close the plugin. If a domain no longer exists, you’d think we could close it, but what if that happened because a company renamed themselves and forgot to update the emails? And what about when the bounce is from the domain, but doesn’t say WHICH user account bounced? It takes time.

We know a handful of people have been upset to find out we closed their plugins instead of trying to sort out who actually should own the plugin when the email bounced. We are sorry about that, but it was a case of prioritizing and expediency. It’s much more efficient for us to close the plugin and let you contact us than to spend a couple hours untangling who represents a company and is legally responsible for managing a plugin.

Questions?

As always, if your plugin was closed and you don’t know why, email us with a link to the plugin and ask. We’d rather have them up and active and usable too!

#reminder #email

Blocks, Plugins, and You

WordPress 5.0 has been released and with it the new block editor for composing posts has been released.

There are exciting possibilities afforded by the new interface and we like to show off new things. So, we’re showcasing plugins that are block-enabled.

If you’ve written a plugin that introduces or improves blocks, or know of a plugin that does, email us at plugins@wordpress.org. Note that these must be plugins with their block-enabled version currently available in the Plugin Directory.

We’re featuring these plugins in a new “Blocks-Enabled Plugins” section in the directory, as well as in a new section on the WordPress Plugins homepage.

We will be doing something similar with themes soon, so stay tuned!

#blocks

Reminder: We can’t rename plugins post approval.

When you submit a plugin, the plugin slug (i.e. the URL) is determined from your plugin’s display name, as set in the main plugin file. The slug can be changed while a plugin is in review but we cannot change it once your plugin is approved.

That’s why, when you submit a plugin, we send you an automatic email telling you what your slug is, and asking you to please reply immediately if that slug is wrong. We also show you what the slug will be on the post-submission page.

If you fail to tell us before we approve your plugin, you’re going to be stuck with the name you got, unless there’s an extenuating circumstance (like a legal issue, or a typo). We do not accept ‘resubmissions’ to fix the name, as we’re making every reasonable effort to get the information out there for you to act on.

Please. Make sure you read the emails. Make sure you check the slug after you submit. Tell us right away when you spot something wrong. And above all? Remember you have full control of your slug in your own submission 🙂

#reminder #policy