Clarifications

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

README.md

@@ -2,7 +2,7 @@
 
 This is the online repository for the rewrite of the WordPress.org Plugin Guidelines.
 
-As of October 20, 2016, these guidelines match the ones on WordPress.org.
+As of October 17, 2017, these guidelines match the ones on WordPress.org.
 
 ## Introduction
 

guideline-03.md

@@ -1,3 +1,5 @@
-**3. A stable version of your plugin must be available from its WordPress Plugin Directory page.**
+**3. A stable version of a plugin must be available from its WordPress Plugin Directory page.**
 
-The only version of the plugin that WordPress.org distributes is the one in the directory. Though you may develop your code somewhere else, please remember that users will be downloading from the directory, not your development environment.
+The only version of the plugin that WordPress.org distributes is the one in the directory. Though people may develop their code somewhere else, users will be downloading from the directory, not the development environment.
+
+Conversely, not using a directory and instead distributing code via alternate methods may result in a plugin being removed.

guideline-04.md

@@ -1,3 +1,3 @@
-**4. Keep your code (mostly) human readable.**
+**4. Keep code (mostly) human readable.**
 
 Intentionally obscuring code by hiding it with techniques or systems similar to `p,a,c,k,e,r`'s obfuscate feature, uglify's mangle, or unclear naming conventions such as `$z12sdf813d`, is not permitted in the directory. Unfortunately, many people use such methods to try and hide malicious code, such as backdoors or tracking. In addition, WordPress code is intended for anyone to be able to learn from, edit, and adapt. Making code non-human readable forces future developers to face an unnecessary hurdle. Minified code may be used, however the unminified versions should be included whenever possible. We recommend following [WordPress Core Coding Standards](https://make.wordpress.org/core/handbook/best-practices/coding-standards/)

guideline-05.md

@@ -1,7 +1,8 @@
 **5. Trialware is _not_ allowed in the directory.**
 
+Plugins may not contain functionality that is crippled or locked, only to be unlockable by payment or upgrade. Paid functionality must be part of an externally hosted service or a separate plugin, that is not hosted on wordpress.org.
+
 Attempting to upsell the user on other products and features is acceptable within limits.
 
 * Upsell notifications should not be overly prominent or annoying.
-* Plugins may not contain functionality that is crippled or locked, only to be unlockable by payment or upgrade. Paid functionality must be part of an externally hosted service or a separate plugin, that is not hosted on wordpress.org.
 * Plugins may not disable included functionality after a trial period or quota.

guideline-08.md

@@ -1,4 +1,4 @@
-**8. The plugin may not send executable code via third-party systems.**
+**8. Plugins may not send executable code via third-party systems.**
 
 Externally loading code from documented services is permitted, however all communication must be made as securely as possible. Executing outside code within a plugin when not acting as a service is not allowed, for example:
 

guideline-09.md

@@ -1,16 +1,18 @@
-**9. The plugin and its developers must not do anything illegal, dishonest, or morally offensive.**
+**9. Developers and their plugins must not do anything illegal, dishonest, or morally offensive.**
 
 While this is subjective and rather broad, the intent is to prevent plugins, developers, and companies from abusing the freedoms and rights of end users as well as other plugin developers.
 
 This includes (but is not restricted to) the following examples:
 
-* Artificially manipulating search results via keyword stuffing, black hat SEO, or otherwise within the readme
+* Artificially manipulating search results via keyword stuffing, black hat SEO, or otherwise
 * Offering to drive more traffic to sites that use the plugin
 * Compensating, misleading, pressuring, extorting, or blackmailing users for reviews
 * Implying users must pay to unlock included features
 * Creating accounts to generate fake reviews or support tickets (i.e. sockpuppeting)
-* Falsifying personal information to intentionally disguise identities and avoid sanctions for previous infractions
 * Taking other developers’ plugins and presenting them as original work
 * Utilizing the user’s server or resources as part of a botnet
 * Intentionally attempting to exploit loopholes in the guidelines
 * Violations of the [WordCamp code of conduct](https://make.wordpress.org/community/handbook/wordcamp-organizer/planning-details/code-of-conduct/) 
+* Violations of the [Forum Guidelines](https://wordpress.org/support/guidelines/)
+* Harassment, threats, or abuse directed at any other member of the WordPress community
+* Falsifying personal information to intentionally disguise identities and avoid sanctions for previous infractions

guideline-10.md

@@ -1,3 +1,3 @@
-**10. The plugin must not embed external links or credits on the public site without explicitly asking the user’s permission.**
+**10. Plugins may not embed external links or credits on the public site without explicitly asking the user’s permission.**
 
-All "Powered By" or credit displays and links included in the plugin code must be optional and default to _not_ show on users' front-facing websites. Users must opt-in to displaying any and all credits and links via clearly stated and understandable choices, not buried in the terms of use or documentation. Plugins may not require credit or links be displayed in order to function. Services are permitted to brand their output as they see fit, provided the code is handled in the service and not the plugin.
+All "Powered By" or credit displays and links included in the plugin code must be optional and default to _not_ show on users' front-facing websites. Users must opt-in to displaying any and all credits and links via clearly stated and understandable choices, not buried in the terms of use or documentation. Plugins may not require credit or links be displayed in order to function. Services _are_ permitted to brand their output as they see fit, provided the code is handled in the service and not the plugin.

guideline-11.md

@@ -2,7 +2,7 @@
 
 Users prefer and expect plugins to feel like part of WordPress. Constant nags and overwhelming the admin dashboard with unnecessary alerts detract from this experience.
 
-Upgrade prompts, notices, and alerts should be limited in scope and used sparingly or only on the plugin’s setting page. Any site wide notices or embedded dashboard widgets _must_ be dismissible. Error messages and alerts should include information on how to resolve the situation, and remove themselves when completed.
+Upgrade prompts, notices, and alerts should be limited in scope and used sparingly or only on the plugin’s setting page. Any site wide notices or embedded dashboard widgets _must_ be dismissible or self-dismiss when resolved. Error messages and alerts should include information on how to resolve the situation, and remove themselves when completed.
 
 Advertising within the WordPress Dashboard should be avoided. While developers are permitted to promote their own products and services, historically they have been ineffective; ideally users rarely visit these screens. Remember: tracking referrals via those ads is not permitted (see guideline 7) and most third-party systems do not permit back-end advertisements (notably, Google). Abusing the guidelines of an advertising system will result in such actions being reported.
 

guideline-12.md

@@ -1,9 +1,9 @@
-**12. Public facing pages on WordPress.org (readmes) may not spam.**
+**12. Public facing pages on WordPress.org (readmes) must not spam.**
 
 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.
 
 Links to directly required products, such as themes or other plugins required for the plugin's use, are permitted within moderation. Similarly, related products may be used in tags but not competitors. If a plugin is a WooCommerce extension, it may use the tag 'woocommerce.' However if the plugin is an alternative to Akismet, it may not use that term as a tag. Repetitive use of a tag or specific term is considered to be keyword stuffing, and is not permitted.
 
-Write your readmes for people, not bots.
+Readmes are to be written for people, not bots.
 
 In all cases, affiliate links must be disclosed and must directly link to the affiliate service, not a redirect or cloaked URL.

guideline-13.md

@@ -1,4 +1,4 @@
-**13. The plugin should make use of WordPress' default libraries.**
+**13. Plugins must use WordPress' default libraries.**
 
 WordPress includes a number of useful libraries, such as jQuery, Atom Lib, SimplePie, PHPMailer, PHPass, and more. For security and stability reasons, plugins may not include those libraries in their own code, but instead must use the versions of those libraries packaged with WordPress.
 

guideline-15.md

@@ -1,4 +1,4 @@
-**15. The plugin version number must increment every time a new version is released.**
+**15. The plugin version number must be incremented every time a new version is released.**
 
 Users will only be alerted to updates when the code version is incremented in SVN. Developers can deploy these updates either by incrementing the plugin version number in the readme.txt in the trunk branch or by creating a new tag branch with a readme.txt which has an incremented plugin version matching the branch directory name.
 

guideline-16.md

@@ -1,3 +1,3 @@
 **16. A complete plugin must be available at the time of submitting the plugin request to the directory.**
 
-All plugins are examined prior to approval, which is why a link to a zip is required. Names cannot be “reserved” for future use. Directory names for approved plugins that are not used within a reasonable amount of time may be given to other developers.
+All plugins are examined prior to approval, which is a zip file is required. Names cannot be “reserved” for future use. Directory names for approved plugins that are not used within a reasonable amount of time may be given to other developers.

guideline-17.md

@@ -1,4 +1,4 @@
-**17. Respect trademarks and projects.**
+**17. Plugins must respect trademarks, copyrights, and project names.**
 
 The use of trademarks or other projects as the sole or initial term of a plugin slug is prohibited unless proof of legal ownership/representation can be confirmed. For example, the [WordPress Foundation has trademarked the term “WordPress”](http://wordpressfoundation.org/trademark-policy/) and it is a violation to use “wordpress” in a domain name. This policy extends to plugin slugs. 
 

guideline-18.md

@@ -1,5 +1,11 @@
-**18. We reserve the right to alter the Plugin Guidelines at any time with or without notice.**
+**18. We reserve the right to maintain the Plugin Directory to the best of our ability.**
 
-We reserve the right to update these guidelines at any time as we feel necessary.
+Our intent is to enforce the guidelines with as much fairness as humanly possible to ensure plugins’ quality and the safety of their users. To that end, we reserve the following rights:
 
-We reserve the right to arbitrarily disable or remove any plugin from the directory for any reason whatsoever, even for reasons not explicitly covered by these guidelines.  Our intent is to enforce these guidelines with as much fairness as humanly possible to ensure plugins’ quality and the safety of their users.
+* ... to update these guidelines at any time.
+* ... to disable or remove any plugin from the directory, even for reasons not explicitly covered by the guidelines.
+* ... to grant exceptions and allow developers time to address issues, even security related.
+* ... to remove developer access to a plugin in lieu of a new, active, developer.
+* ... to make changes to a plugin, without developer consent, in the interest of public safety.
+
+In return, we promise to use those rights sparingly and with as much respect as possible for both end users and developers.

introduction.md

@@ -11,14 +11,18 @@ If you have suggestions to improve the documentation, or questions about it, ple
 In order to submit a plugin, [there are three steps](https://developer.wordpress.org/plugins/wordpress-org/#getting-plugins-hosted):
 
 1. Register on WordPress.org with a valid, regularly checked email address. If you are submitting a plugin on behalf of a company, use an official company email for verification.
-2. Whitelist plugins@wordpress.org in your email client to ensure you receive email communications.
+2. Whitelist `plugins@wordpress.org` in your email client to ensure you receive email communications.
 3. Submit your plugin with a brief overview of what it does and a complete, ready to go, zip of the plugin.
 
 Once a plugin is queued for review, we will review the code for any issues.  Most of the issues can be avoided by following the guidelines below. If we do find issues, we will contact the developer(s), and work towards a resolution.
 
 ## DEVELOPER EXPECTATIONS
 
-Developers, all users with commit access, and all users who officially support a plugin are expected to abide by the Directory Guidelines as well as the [Forum Guidelines](https://wordpress.org/support/guidelines/). Violations may result in plugins or plugin data (for previously approved plugins) being removed from the directory until the issues are resolved. Plugin data, such as user reviews, may not be restored, depending on the nature of the violation and the results of a peer-review of the situation. Repeat violations may result in all the author’s plugins being removed and the developer being banned from hosting plugins on WordPress.org. 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.
+Developers, all users with commit access, and all users who officially support a plugin are expected to abide by the Directory Guidelines. 
+
+Violations may result in plugins or plugin data (for previously approved plugins) being removed from the directory until the issues are resolved. Plugin data, such as user reviews and code, may not be restored, depending on the nature of the violation and the results of a peer-review of the situation. Repeat violations may result in all the author’s plugins being removed and the developer being banned from hosting plugins on WordPress.org. 
+
+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.
 
 All code in the directory should be made as secure as possible. Security is the ultimate responsibility of the plugin developer, however the Plugin Directory enforces this to the best of our ability. Should a plugin be found to have security issues, it will be closed until the situation is resolved. In extreme cases, the plugin may be updated by the WordPress Security team and propagated for the safety of the general public.