Why the Plugin Emails are ‘Anonymous’

In 2019, we transitioned to a new email service which has allowed us to make all emails anonymous. This decision was not initially well received by all, especially when people feel they are unfairly targeted for guideline violations, though over time it’s settled down.

I wanted to take a minute to explain the backstory about why this had to happen.


Over the last four years, there has been a disturbing escalation in behavior with regards to plugins. Reviewers have found themselves targeted in rather terrifying ways, including:

  • emailing someone’s employers to complain
  • making credible threats against safety at an upcoming WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more.
  • doxxing a reviewer by publishing their address
  • publicizing information about their families
  • death threats
  • sending physical packages/mail to them

All those things happened from people who were censured for not complying with the guidelines. Some of them even chose to quit, asking us to pull their plugins, and then retaliated in that manner.

Their reactions are always rather odd to look at in the community because the PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Team does not publicize these issues. That is to say, we generally will not explain, to the general public, the full details on why something was closed or a developer banned. We don’t do this to hide anything for our own benefit, though that appears to be a common misconception. The reason we keep those issues private is that we feel it gives developers a chance to walk back from a very bad day.

We know we’re sending out some pretty devastating emails to people. Being told “Your plugins have been closed” is a gut-punch, and it’s one we really try to avoid. When people are hurt, they have a tendency to lash out, and in doing so they can cause irreparable harm to their own standing in society. The Internet never forgets anything, and the words said in anger and frustration will haunt us to our dying day and beyond.

By keeping the conversations private, we are allowing developers to have the ability to survive their bad day. You can think of it as giving people a second chance. Of course, you can’t help everyone, and we do know to cut our losses. Not everyone will come back, and some people will burn bridges so badly that it would be detrimental to the community at large to allow it, no matter how much they apologize.

The Decision

2019 was the worst year on record for categorical abuse of the members of the team. It’s difficult to express without violating confidence (and in some situations, legal cases still pending) exactly how bad. When we say ‘Someone mailed things to a reviewer’ we literally do mean that unasked for items were sent via physical mail. And when we say that someone’s home address was leaked, it was absolutely done with intent to harm.

All this leads to the great cost we bear, willingly, as we shoulder the outrage quietly. When we had people’s real names attached to the emails, we had them targeted specifically and personally. They were clear attacks on people, many times misguided and misdirected, that prompted us to change the emails to anonymous.

Because of the attacks on people’s safety and out of a desire to protect their health and well being, we have chosen to make all emails from the Plugin Review Team anonymous.


This choice has not really gone over as well as we’d hoped.

It’s no secret that people get very passionate about their plugins. They’ve created something out of their heart and minds, and getting emails from us telling them that there are issues with their work is disheartening. It’s worse when those are clearly a form email.

When we moved to form replies years ago, in order to expedite the review process, they were generally understood to be the cost of the high volume of reviews. Having impersonal emails sent from a real human was annoying, but acceptable. Having impersonal emails sent from an anonymous account makes us feel like we’re not valued as humans.

That’s why we’ve worked hard to rewrite a lot of the emails to be more clear about what the problem is and what you need to do to resolve it. We’ve tried to make our dreaded ‘Final Warning’ email even more clear.

We Want You To Do Well

We want nothing more than the continued success of the Plugin Ecosystem, hosted on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ and not. When we’re reviewing your code, we want the code to be safe and to be well documented so that you have every possible opportunity to be a success.

We can no longer sacrifice ourselves in doing so.

Our emails are always sent by a real human being, who is just as flawed as you are. They’re never personal attacks. While we always do our best to make sure we’re in the right before we send a warning, we are humans, like you, and we make mistakes.

We Will Continue to Be (Mostly) Anonymous

With rare exceptions, emails from plugins will remain anonymous. In some cases, the person replying may divulge who they are, but that is their personal choice to do so. No one on the team will ever be required to reveal their identity in an email.

We hope you can understand this frustrating, but needed, action.

#abuse, #explanation, #privacy

WP 4.9.6, Privacy, Hooks, and You

WordPress 4.9.6 has been released. This was a focused release, a little different than other minor releases, in that it adds a system for a privacy policy to WordPress. While the only change to plugins has been our requirement that you not claim (or imply) 100% compliance in anything, the changes to privacy awareness are far reaching.

The tl;dr of the whole post is “You’re going to need to consider the impact of data collection in your plugins, even if you don’t collect anything.” So yes, I know it’s long, but please read the whole thing.

NOTE: We are not lawyers. We cannot tell you if what your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is doing is going to break a law. Please don’t ask us to try and figure that out for you. The purpose of this post is to make you aware of what’s going on, and give you a place to start with making your plugins better.

Does This Impact You?

Yes. This impacts everyone. Plugins are used internationally which means you actually do have to be aware of the world, Net Neutrality shenanigans aside. Your plugin could, in fact, cause someone to get in legal trouble. While that is technically their responsibility, you should be as aware as possible of the implications of your code and how it’s used.

Ask yourself this: Does your plugin…

  • … write any private data of users (registered or visitors) to the database?
  • … send any data to remote servers (i.e. act as a service or embed content)?
  • … edit the comments form in any way?

If yes, then this absolutely, without a doubt, impacts your plugins.

If no, then this may still impact you, so please keep reading, because people are going to ask you about this.

Privacy Means Disclosure

If you’re a service, like you pull a library from a remote server, then you have to tell people that you pull data remotely. This has always been a policy, so if you’re not disclosing this now, please go fix it right away.  But you also need to tell people the obvious things, like embedding content via your plugin means the site administrator is consenting to the embed terms of that service.

An example for you. Let’s say you have a plugin that embeds YouTube playlists. Your plugin should be clear “This plugin embeds YouTube Playlists.” We also recommend you include a link to YouTube’s privacy doc. It’s alright to say “By using the embed features in this plugin, you will be agreeing to YouTube’s Terms of Use.”

The same holds true now for data stored locally. If your plugin stores browser data of visitors, then yes, you need to document and disclose this. You can’t force site admins to publicize this in turn, but by making sure they know, you’re helping them determine what their own reasonable disclosure should be.

Some Code To Help

WordPress has gone the extra step to make it easier to make a privacy page and hook into it, both for users and developers. The moving parts you need to be aware of are the tool for users to request an export of all the stored data associated with them on the site. There’s also a tool for users to request erasure of that same data. Both tools include admin workflows to fulfill those requests. And there’s one to suggest what kind of text should be on someone’s site.

The handbooks have been updated to help you out here:

Also, while this is a little more aimed at theme developers, if your plugin happens to mess around with comments, please read the changes that affect themes, as there is going to be a new checkbox for comments.

Update Your Plugins

The tl;dr of all this is that plugins should…

  • … disclose what user/visitor information it saves in the readme;
  • … hook into the privacy page creator to inform people there too;
  • … provide a way to export said information;

We aren’t (currently) changing any policy to require all this. At the same time, I strongly recommend at the bare minimum everyone put a privacy policy in your readme. Even if you don’t save any data and you don’t send anything, make a Privacy Policy anyway and tell people that.

Why? At the very least, it may stop people from asking you “Is this plugin collecting any data?” which saves you time. But more importantly, this is to protect yourself. After all, if people come through with a 1-star review that you caused them to become non-compliant because you didn’t disclose local data collection, well, that would be a very justified review.

#core, #guidelines, #privacy