X-post: Component Maintainers in 5.3

X-comment from +make.wordpress.org/core: Comment on Component Maintainers in 5.3

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.

X-post: WP Notify Kick off meeting announcement

X-comment from +make.wordpress.org/core: Comment on WP Notify Kick off meeting announcement

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

X-post: Feature plugin discussion: a consent and logging mechanism for user privacy

X-comment from +make.wordpress.org/core: Comment on Feature plugin discussion: a consent and logging mechanism for user privacy

X-post: Feature Project Proposal: WP Notify

X-comment from +make.wordpress.org/core: Comment on Feature Project Proposal: WP Notify

X-post: Updates to the WordPress User & Developer Survey

X-comment from +make.wordpress.org/updates: Comment on Updates to the WordPress User & Developer Survey

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.

Do You Make Widgets?

Please take some time to read and comment on the proposal to move Widgets to the Blocks UX!

Widgets to Blocks UX Flow Proposal

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