Ipstenu (Mika Epstein) 5:28 pm on December 31, 2018  

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

Ipstenu (Mika Epstein) 9:25 pm on December 17, 2018
Tags: ,   

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

Ipstenu (Mika Epstein) 3:24 am on December 13, 2018  

https://make.wordpress.org/core/2018/12/13/backwards-compatibility-breaks-in-5-0-1/

Backwards Compatibility Breaks in 5.0.1

Samuel Wood (Otto) 9:09 pm on December 7, 2018
Tags: blocks   

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

Ipstenu (Mika Epstein) 7:35 pm on November 21, 2018
Tags: ,   

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

Ipstenu (Mika Epstein) 7:15 pm on October 22, 2018
Tags: ,   

Reminder: Plugins are closed if emails bounce

We emailed out the ‘5.0 is coming’ email and received a record high number of bounces. Over 2000. Normally we get a couple hundred, mixed in with vacation notifications (which we ignore) and auto-replies.

When your email bounces, we close your plugin because we no longer have a way to communicate with you. We even email you to tell you, just in case it’s a one-off glitch. If your email auto-replies, you get a warning. If you don’t fix this, the next auto-reply gets you closed. There are a couple exceptions to this, like the person who’s system got stuck in a loop and emailed us back 6 times for one plugin.

  • If the email was the owner of the plugin, and there’s no clear secondary owner, the plugin’s closed
  • If the email was the owner but we can tell another account is the co-owner, we transfer the plugin and email the new owner to explain
  • If the email is a committer, their account is removed and the owner emailed to explain why

Why so many?

But this number being so high was astounding to us. Like I said, it’s 10x the norm. In looking into it, we’ve determined the following facts led to this number:

  • Yahoo will delete your email account if you don’t use it for a year
  • Google reserves the right to deactivate your email after 9 months of inactivity
  • Free Windows Live Hotmail accounts become inactive if you don’t sign in for more than 270 days
  • Google email groups default to not allowing external emails.

My guess is that with GDPR being a thing, many email servers have gone ahead and deleted things. Also I suspect they changed the defaults on Google email groups, since a few of these accounts have been around for a while.

How do I get my plugin reopened?

First check that your user’s email is correct. If not, fix that. Then email us and ask if your plugin can be reopened. Most everyone has been reopened immediately. The stragglers are due to ownership issues. This is why we’re so pedantic about official accounts owning plugins. If the owner bounces but other people from the company have official accounts as committers, we’ll transfer the plugin.

What can I do to prevent this from happening?

The simple answer is “Make sure your email is up to date and functional.”

  • Add wordpress.org to your email’s white-list so you always get our emails
  • If you have a plugin that is a company plugin, make sure that the plugin owner’s email us up to date, and not an auto-reply
  • If your email is an alias, make sure everyone who gets the copy of the email is an active users
  • If you use a group/mailinglist account for your plugin, make sure wordpress.org can email it (groups need to allow ‘world’ access to send to)

#email, #reminder
Ipstenu (Mika Epstein) 4:26 pm on September 26, 2018
Tags: ,   

Reminder: Respecting Trademarks Includes Icons and Banners

This is a reminder that one of our guidelines is respecting trademarks and brands.

tl;dr

Using someone else’s trademarked logo in your plugin logo or banner is a trademark violation, and they have the right to have us remove your plugin at any time.

Explanation

Normally trademark situations come up when you submit a plugin like Facerange Messenger, but you don’t happen to work for Facerange. We change your slug from facerange-messenger to messenger-for-facerange (or something to that effect) and ask you to rename the plugin to “Messenger for Facerange”. Another common instance is when we have to explain bobo-facerange-messenger.com is a violation of their trademark use, and you need to rename your domain.

As of late, companies have begun enforcing logo usage as well. Originally they were just picky about the icon or banner being only their logo, but now they’ve moved on to the use at all. What this means to you is simple: Don’t use someone else’s logo in your plugin’s icon or banner. Period.

If you don’t have the legal rights to use it, don’t. If you’re not sure if you do, assume you don’t. If you lose the legal right (like no longer being a part of PayFriend’s trusted developer program), you must immediately remove their logo from your plugin’s public facing pages.

FAQ

What happens if a company complains?

You will receive a warning via email that a complaint has been filed and you are to correct the icon and/or banner immediately.

How long do I have to comply?

0-days. Technically you’re already a violation. They don’t have to let us give you a chance to come correct, so we would appreciate it being done within 48 hours.

Do I have to push a new version of my code to do this?

Nope. Just fix the images in your assets folder.

Addendum by Otto: This includes screenshots. If you have somebody else’s logos in your plugin itself, or displayed on your service, then you might want to consider getting those removed as well.

What do I do if a company asks me to change my icon/banner?

Change it. Seriously, it’s not worth it. Make your own unique and distinct logo for your plugin. It’ll make you more memorable in the long run.

Do I have to change my display name as well?

Yes, you do. Remember: Don’t start your display name with someone else’s trademark/copyright/commonly known name. If it’s not your name, it’s not a good idea.

Isn’t this contrary to the GPL and open source?

No. Licences like GPLv2 are separate entities, and in fact the GNU supports the use of copyright in code. As for open source, it’s not above the law. Check out FOSSMarks for more information and as always, contact a lawyer with your legal questions.

Addendum by Otto: Also note that Trademark and Copyright are two entirely different things. There is no “licensing” for trademarked items. The GPL and any other license will not apply. Basically, if something is trademarked, then you need to get explicit permission to use it, in writing, or you just don’t use it.

I think it’s fair use. Will you let me keep the icon while I fight them?

Alas, no. We have to consider the directory as a whole and it’s over 60k plugins. The risk for us is too high, and we will side with the legal request.

Addendum by Otto: There is no concept of “fair use” in trademark law. Don’t use other people’s trademarks. Period.

What about existing plugins that you let violate trademarks in the slugs?

That’s because we do not have the technical ability to rename a slug without breaking it for all users. They’d be abandoned. And you can’t automatically migrate users from one plugin to another, so because of that limitation, most companies have permitted us to retain plugins that violate their trademark in the slug. Some have not, and we’ve been forced to close those plugins.

Since the logo and display name can be safely changed, it’s a different matter.

Someone else is violating too! Why didn’t you shut them down?

We email people in batches. You’re welcome to report fellow plugin devs who are violating the guideline, but the odds are we’ve already been in contact with them (or will be shortly). You’re not being singled out, we just have a lot of plugins to work through and we take breaks. Keep in mind, if it’s not YOUR trademark, we generally just warn.

Someone’s using my trademark in their icon/banner, how do I get them to stop?

Contact them first and point to this post (and the 17th guideline) and just ask them NICELY to please change it. If they blow you off or don’t respond in a reasonable time (like 2 weeks), you can email us at plugins@wordpress.org and we’ll follow up.

#guidelines #trademarks

Ipstenu (Mika Epstein) 4:07 pm on September 3, 2018
Tags: ccoc, crosspost   

Notice: Community Code of Conduct Meeting 4 Sept

The Code of Conduct will apply to all plugin developers and their support crew, so we encourage you to be aware of these developments.

Community code of conduct next meeting: 4th September 15:30 UTC

#ccoc, #crosspost

Ipstenu (Mika Epstein) 2:55 pm on August 29, 2018  

Unused Plugins Closed

I’m happy to say that at this point, all plugins that were approved and never used (that is, never had any code uploaded, ever) have been closed. Roughly 8500 plugins were closed for never having any code committed to them since approval.

In addition, the plugins that have been broken since we migrated to the new plugin backed (April last year) due to incorrect SVN usage have also been closed. They weren’t showing up anyway, so it’s not like anyone could have installed them in the first place.

This means we currently have 700 plugins that have been approved and never used, dating back to April 2017.

Going forward, we’ll be holding any new submissions from developers who have an unused plugin. This means if you submit a plugin and get it approved and immediately turn around and submit a new one, we won’t even review it until you actually use the approved one.

This is not a change to guidelines. We already require you to provide a stable version of your code from our SVN service, so this is simply a means to enforce that guideline. If you have hosting, you’re expected to use it.

Ipstenu (Mika Epstein) 9:23 pm on August 23, 2018
Tags:   

Guideline Update: Clarifications to trialware and human readability

Two situations have arisen where we feel it would be best to clarify the guidelines a little.

Guideline 4: Human Readability

We strongly feel that one of the strengths of open source is the ability to review, observe, and adapt code. By maintaining a public directory of freely available code, we encourage and welcome future developers to engage with WordPress and push it forward.

However with the advent of larger and larger plugins using more complex libraries, people are making proper use of build tools (such as npm) to generate their distributed production code. In order to balance the need to keep plugin sizes smaller while still encouraging open source development, we will be requiring plugins to make the source code to any compressed files available.

For example, if you’ve made a Gutenberg plugin and used npm and webpack to compress and minify it, you must either include the source code within the published plugin or provide access to a public maintained source that can be reviewed, studied, and yes, forked.

We strongly recommend you include directions on the use of any build tools to encourage future developers.

Guideline 5: Trialware

Historically we’ve not permitted test or trial plugins that arbitrarily limit usage, and then upsell, to be included in the directory. The primary reason we don’t permit this is that locking people down to a specific number of (say) images is foolish and a pointless endeavour. People can, and will, fork your locked plugin and unlock it, as well they should. That said, we’ve always allowed (and will continue to) plugins that offer a free limited service (think Akismet for a good example).

Related to this are ‘sandbox’ plugins, used for testing. For example, if your plugin only accessed the Instagram Sandbox API, and included upsells about a pro version that allowed full access, you would be a trial plugin. Since they are easily abused as turning the directory into a marketplace, we have modified the 5th guideline to address this more clearly.

#guidelines