X-post: Strengths and Challenges: Organization

X-comment from +make.wordpress.org/updates: Comment on Strengths and Challenges: Organization

X-post: 5.0 Release Retrospective Kickoff

X-comment from +make.wordpress.org/updates: Comment on 5.0 Release Retrospective Kickoff

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

X-post: Strengths and Challenges: Follow Up

X-comment from +make.wordpress.org/updates: Comment on Strengths and Challenges: Follow Up

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

X-post: Our Strengths and Challenges

X-comment from +make.wordpress.org/updates: Comment on Our Strengths and Challenges

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

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

Backwards Compatibility Breaks in 5.0.1

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