Ipstenu (Mika Epstein) 5:30 pm on March 1, 2018  

Reminder: Paying for reviews is a guideline violation

Normally this comes up because we have to explain that paying a single person for a review is bribery.

This isn’t that.

I’m talking about when company or consultant on those websites like Fourrer (not it’s real name) offers to, for $50 or $450, leave 5 star reviews on your plugin. That’s a practice known as ‘salting’ (go look up ‘salting mines’ if you’re interested in why) and it is prohibited behaviour.

Reviews of your plugins should be made by users who actually use the plugin. When you pay people, either individually or en masse, to review your product, you get disingenuous reviews that are inclined to be of a higher nature. When you pay a company to get a series of 5-star reviews, you’re outright lying to people. You’re making them believe other users have reviewed when they have not.

If we catch you paying for reviews, you will lose ALL reviews made during the time period. Sadly, this is because we do not have a way to quickly or easily verify each and every review and user account. It’s an inefficient use of our resources to do so manually. In addition, we cannot accept a developers ‘word’ about which are and are not the purchased reviews, as many have lied about that in the past, and few have incentives to be fully honest. Finally, the fate of ‘valid’ reviews caught up in the removals are considered ‘fruit of the poisoned tree’ and cannot be restored.

And if that’s not bad enough, if you do it again, you lose your plugins.

Don’t pay off people for reviews.

Samuel Wood (Otto) 5:22 pm on March 1, 2018
Tags: make.wordpress.org/support, p2-xpost   

X-post: Dealing with Angry Users – Workshop on March 16, 2018

X-comment from +make.wordpress.org/support: Comment on Dealing with Angry Users – Workshop on March 16, 2018

Ipstenu (Mika Epstein) 10:34 pm on February 20, 2018
Tags:   

Keyword Stuffing is Spamming

In January 2017 we clarified what was meant by not spamming in the directory.

Since then, the language has been tweaked slightly, but the crux of the matter remains as follows: Public facing pages on WordPress.org (readmes) must not spam

To whit:

Public facing pages, including readmes and translation files, may not be used to spam. Spammy behavior includes (but is not limited to) unnecessary affiliate links, tags to competitors plugins, use of over 12 tags total, blackhat SEO, and keyword stuffing.

If you have a keyword or phrase repeated over 30 times in your plugin, you’re probably spamming. There are exceptions, especially when a term is a common word or you’re listing your shortcodes. However please be reasonable. If we see you using the same word 50 or more times in the readme, you’ll likely be receiving a warning.

Please take these warnings seriously. If you get asked to fix one plugin, we expect you (and ask you) to take care of any plugins we didn’t list as well. Be mature humans.

#guidelines

Ipstenu (Mika Epstein) 6:44 pm on February 13, 2018
Tags:   

“Not Updated In …” Warning

The old warning that a plugin has not been updated in 2+ years has been changed to an indication of what version of WordPress a plugin has been tested up to. If that version is more than 3 major releases old, a plugin will be flagged as being maybe out of date.

Why the change?

Two years was rather arbitrary, but also wasn’t helpful to as many people. That is, two years had little meaning, since there were many plugins that didn’t need updates.

In addition, developers failed to understand what we meant by the multiple emails (the ones we send every major release) asking them to bump the tested-up-to value, without releasing new code. By doing that, the 2-year warning would go away. With this change, developers have a clearer one-to-one understanding of why their plugin is showing up as ‘old’ and users can see that a plugin has or has not been tested with the version of WP they’re using.

What do I put in for ‘tested up to’ versions?

We recommend the MAJOR release. For example, WordPress is currently on version 4.9.4. If you put in 4.9, then it will show as compatible. Don’t use words like “WP 4.9†– just use the version number.

Can I put in 5.0 as a version?

Yes, but it won’t do what you think it does. That is, you won’t show as compatible with 4.9. Don’t try to be clever on that one.

Does this make more work for developers?

No. A year ago I would have said yes, but now that we’re not releasing new major releases of WordPress 3 times a year, it works out to needing to update plugins’ readmes every 18 months or so. That changes the time by roughly six months, depending on the status of projects.

Can we indicate version compatibility with other plugins?

You mean like bbPress, WooCommerce, and so on? No. We recommend doing that within your plugin code.

Will this change the functionality of plugins?

No. This will neither alert your users nor will it disable your plugin within WordPress itself. You still have to handle that manually.

Is this a guideline change?

Nope. If you don’t want to update it ever, we don’t mind. The only reason we’d close a plugin for being ‘old’ is if it was broken or your email bounced.

#directory

Ipstenu (Mika Epstein) 7:32 pm on December 28, 2017
Tags:   

Guideline Update

The previously proposed changes have been merged into the plugin guidelines.

It’s important to note that I do not think this is a ‘complete’ or ‘finished’ project. The guidelines are imperfect, in part because it’s impossible to create a rule for every single possible variant of a possible conflict, but also because we cannot predict the future.

There are people who are unhappy we didn’t go far enough with certain guidelines — like not saying “you may have 3 links to your own products on your plugin admin pages.†Others are unhappy we’ve gone as far as we did in certain situations — such as the 9th guideline’s prohibition against harassment.

Accepting the imperfection of English, as well as the flaws built in to creating guidelines for such a large audience, many of whom do not speak English natively, has led to situations where we have to settle. These guidelines are not perfect. They are not complete. They will be constantly evolving and adapting as we try to please and protect the majority of developers and users.

I encourage all of you to help us write them better. You can email us at plugins@wordpress.org or make pull requests on the GitHub repository. While we may not accept all requests, I promise we do listen to and read every last one.

#guidelines

Ipstenu (Mika Epstein) 4:37 pm on December 3, 2017
Tags: ,   

Reviewing the Guidelines – 2017

I do this regularly, but recently I received a comment that the guidelines were still too vague.

I need to stress that this is by intent. If we make guidelines like “You can only have 3 external links†then people will find ways to exploit that. However I do not think that guidelines are perfect. Which is why I’m proposing a minor update to them to address the following concerns:

  • Overall tense of guidelines made consistent
  • Update introduction for readability and unpack what we mean by keeping email updated
  • Explain the converse of 3
  • Put the important part of 5 on top
  • Add link to forum guidelines to 9
  • Add prohibition against harassment to anyone in WP
  • Clarify self-dismissible alerts are acceptable in 11
  • Changed tense of 12 and 13 to emphasize their importance
  • Grammar fix for title of 15
  • Fix reference to zips in 16 (upload now vs link to)
  • Reword title of 17 to explain that PLUGINS must honor…
  • Guideline 18 has received a full rewrite to clarify what rights we reserve and reiterate our promise to do this as fairly as possible.

You can see all the changes proposed here on GitHub

Please read the guidelines and leave comments or pull requests on Github. The plan is to make these live in January 2018 so please jump in and help! Thanks.

#announcement, #guidelines

Ipstenu (Mika Epstein) 4:42 pm on November 28, 2017  

Last Updated On Nov 27/28 Without Updates? Don’t Panic!

This post was corrected at 1901 UTC

In the last 24 hours, a fair amount of plugins were “updated†even though no one pushed any code. At first we thought this to be due to a re-run of the string importer, but as it continued, Otto theorized it was actually due to the checksum generator.

If a plugin shows a ‘recent’ last update, even though no code changed, do not panic.

Nothing ‘bad’ has happened. We’re currently looking into a way to mitigate this and have a more accurate time show up, as SVN is unaffected.

In the last 24 hours, a fair amount of plugins were “updated†because of the strings importer having an issue. Those had to be rerun in order to get the strings pulled in to be translated properly. This had the adverse impact of causing the “Last Updated†value to change.

Which scared people. Sorry about that.

If you’re worried, check your SVN changelog. If nothing was updated, then it was just us 🙂

Of course, if someone you don’t remember giving access to did your last commit, please DO email us at plugins@wordpress.org right away and we’ll help you out.

Ipstenu (Mika Epstein) 4:43 pm on November 6, 2017  

Concept: A Developer Dashboard

One of the ideas that came from WCEU was a centralized dashboard for plugin developers. A place they could go to see all their plugins, and the current status on these plugins. What follows is concept art of what that kind of dashboard may look like.

This is something I dreamed up in Nacin’s talk about the government. This idea has no code backing behind it.

So why am I posting it? I’d like to hear people’s thoughts on this. What do you think would work or won’t work? Too much automation or not enough? Do you actually already HAVE this code written and want to share? Here is a zip of the Balsamiq Mockup: WP-Developer-Dashboard.bmpr_.zip – You know the drill. Edits welcome!

Concept Art

Goals

  • Make a centralized location for developers to manage their plugins

That’s really it. Making this public means a question of moving the ‘advanced’ tab to this page, and would it be duplicating data unnecessarily? In a way, it would move the developer page here as well, leaving only that which is controlled by the readme left on the readme. But then again, jumping between urls could be a mess. I don’t know. That’s why it’s a concept.

Also it should be easier for a developer to contact the plugin team when they have issues. And yes, the communication would be public, unless a comment is flagged as ‘security.’ Again, no code at all exists to make this a reality.

What’s Missing

There’s no contact form for a closed plugin. There should be. But this is really just concept art and starting to get an idea of what may work.

There’s also a dearth of data on the main dashboard page. That could lift from plugins like WP Dev Dashboard or WP Developers Homepage to fill in data. That’s the same general concept of what we’d want on the Support page (which you’ll notice is also left missing).

Misc. Thoughts

One of the stated goals we have is to allow everyone to leave a review on a plugin, with regards to the reviews before approval. In doing so, those reviews and all discussions about a plugin would need to be public. This is not necessarily a bad thing, though it will lead to some developers thinking long and hard about how they address issues in public. My concerns are that people who continually make the same error or neglect to fix something will be publicly embarrassed, but also that a free-for-all with reviews would lead to developers not wanting to host code here due to public backlash.

However, it’s been pointed out to me that coddling developers as much as we do may be causing them more harm in the long run. We do spend an inordinate amount of time hand-holding people who don’t want to take the time to read and think through a debugging process. Certainly we don’t mind helping out people who are brand new, or who aren’t native English speakers. But they’re vastly the minority of people who act the goat in our emails. And generally, they’re very respectful and nice.

Right now, my gut feeling is that there should still be a private way to talk about security issues.

But behavioural ones? They can be handled in public. It may stop people from some of the name-calling.

Ipstenu (Mika Epstein) 10:33 am on October 24, 2017  

One At A Time

As of last week, plugin uploads are restricted to one at a time.

That means if you have a plugin in the queue, be it submitted for review, in review, or pending your reply, you may not submit a second plugin. You have to finish your first one (or ask us to reject it) before you can move on.

This is not for the same reason that Themes does it. To whit, you’re not restricted to keep the queue low (ours is usually only a 3 to 7 day backlog anyway). You’re all being restricted because people aren’t finishing reviews, and it’s become a drain on resources.

We have over 700 reviews waiting on the developer to get back to us.

Now some of those are cases where people lost the email, or missed it somehow. Other people get the email and don’t know what to do or decide it’s too much work to fix all the things. And worse, some people decided that they’d get the review and never use the directory. In order to prevent this sort of abuse, and the disrespect to everyone else who actually finishes a review and uses the hosting we provide, everyone’s being restricted.

This should not be onerous. We have a tiny backlog. To the point that some people get rather rude when they don’t get a reply in 36 hours. And yes, that’s exactly as annoying as you think it is.

One review at a time. One plugin at a time. Please give us at least 5 business days to reply to emails.

By the way. If you’ve submitted a plugin within the last 7 days and haven’t gotten a reply, check your spam because I promise, we ended Friday with an empty queue.

Ipstenu (Mika Epstein) 6:16 pm on October 17, 2017
Tags: ,   

Reminder: Research Before You Sell Out

Are you thinking of selling your plugin? Did someone offer you money to put a link to their sites in your readme or wp-admin settings page?

STOP. THINK. BE CAUTIOUS.

I’m sure most of you are aware of the recent bad behaviour that’s gone on with regards to unscrupulous people purchasing plugins and using them to leverage malware, spam, and backdoors. While we would never tell you that it’s wrong to sell the plugins (they’re yours after all), we do want to help you recognize the warning signs of a bad-faith purchase.

Above all, if anything in the process makes you nervous and feel like something is wrong, call the deal off. You can email us at plugins@wordpress.org and we can help vet the buyer for you.

But remember this: The primary reason people want to buy ‘popular’ plugins is to use it to spam.

Signs To Watch Out For

Here are some basic red-flags:

  • You get an unsolicited email that reads like a generic form
  • The offer includes different prices based on how many people use the plugin (i.e. $500 for every 1000 users)
  • The amount offered seems to be rather high ($50,000 USD for a plugin)
  • The offer comes from a company who claims to be purchasing a ‘suite’ or ‘collection’ of plugins
  • They want you to sign an NDA, and not talk about the purchase
  • They don’t offer to show you an improvement of the code right away
  • They have (or plan to have) a special domain and user account just for this plugin
  • They have a brand new (less than a year old) account on WordPress.org with no other plugins
  • They have no visible, active participation in the WordPress community (forums, plugins, themes, WordCamps, etc)

Do Your Homework

When people come to us asking to adopt plugins, we vet them. We look at the code first. If there’s no new version of the code, with fixes, we don’t even consider it. If the prospective buyer of your plugin can’t show you how they’ll update it, don’t do it. Period.

No matter what you must do the work to vet these people. Ask them serious questions. How do they plan to handle support and reviews? How familiar are they with the directory guidelines? Do they already know how to use SVN? How will they take care of your existing users?

Review their code. Sit down and look over every single line of code and make sure it’s safe and well written. If you see base64 and it’s not for images, tell them no. If you see them phoning home, tell them no. If you see them doing things in an insecure way, tell them no.

At the end of the day, what they do is going to reflect on YOU, and your reputation could suffer.

Many times, good developers find their names dragged through the mud when a plugin they own is purchased by people who do horrible things with their code. Make absolutely certain, beyond shadow of a doubt, that they understand what owning the plugin means, and that they must abide by all the plugin and forum guidelines.

Worst Case Scenario

If we find out you sold your plugin to someone who does evil with it, the odds are you won’t get that plugin back. Among other reasons, you sold it. To have you take someone’s money for the access, and then give it back to you, would be tantamount to theft. At the very least, it would be a bad-faith action on our part. Once you sell a plugin, accept the money, and your access is removed, that’s it. You’ve indicated you’re done with it, and we will enforce that.

This means if evil is done and we need to fix the plugin, we’ll roll it back to a safe version, remove everyone’s access, and disable the plugin permanently. That will it will push a final update, but no one new can install it. We feel that once a plugin has been sold and used like that, it’s near impossible to recover any reputation, and it’s better for the community to walk away.

Should You Sell Your Plugins?

The directory was never intended to be a sales marketplace, and it’s unlikely it will ever be one. If your deepest wish is to make a super popular plugin and sell it for gobs of money, this is probably not the place for you. Selling your plugin is a chancy business, and it’s hard to make money legitimately on a free plugin. After all, they can legally just fork it and make a new one.

You certainly can sell your plugins, but sell it smartly. At the end of the day, it may be better to retire a plugin than sell it or give it away to someone you’re not sure will do good.

#notice, #warning