X-post: WordPress Community Code of Conduct Survey Draft

X-comment from +make.wordpress.org/community: Comment on WordPress Community Code of Conduct Survey Draft

Understanding Readme.txt

At it’s heart, the Readme.txt file is pretty basic. You put in the information, it generates a WordPress page. Of course, it’s not all simple magic, and there are some weird things to be aware of.

To help people better understand how it works, the Plugin Directory documentation has been updated, but here’s a quick primer:

If you use Tags, so will the directory

If you put the stable version of 1.2.3 in your readme, the rest of the content will be pulled from /tags/1.2.3 and not the trunk folder.

Readmes use Markdown (mostly)

Most Markdown calls work as expected. Tables do not. But this means don’t put JS or CSS in your readme. It will break things.

Videos

A YouTube or Vimeo link on a line by itself will be auto-embedded. It’s also possible to embed videos hosted on VideoPress using the wpvideo shortcode.

(File) Size Matters

If your Readme is over 10k, weird parsing things happen. Some tips to keep it small:

  1. Move your previous versions’ changelogs to their own file – changelog.txt
  2. Self-host seriously intensive documentation
  3. Make your readme a ‘how to’ and ‘why this is awesome’ but not a sales pitch for your pro version
  4. Don’t keyword stuff (someone dropped their readme by 4k when they cleaned it up)

Well written readmes get more users

Want to rank higher? Write a good readme. It’s actually much less about keyword stuffing than it is keeping users. After all, we’ve all seen a plugin with 20k downloads but only 10+ active users. That means you’re getting people’s attention and not delivering. So write a good readme that sells what you do, and sells it well. Don’t embellish, like saying you’re the ‘best’ contact form plugin. Ditch the hyperbole and just write good. If you can’t, hire a copy writer. It’ll pay off.

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.

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

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

“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

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

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

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.

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.