Nov 2017 Update

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-01.md

@@ -1,3 +1,3 @@
-**1. Plugins must be compatible with the [GNU General Public License v2](https://www.gnu.org/licenses/gpl-2.0.html), or any later version, to be hosted on WordPress.org.**
+<h4>1. Plugins must be compatible with the GNU General Public License v2</h4>
 
-Though any GPL-compatible license is acceptable, using the same license as WordPress — “GPLv2 or later” — is recommended. All code, data, and images — anything stored in the directory — must comply with the GPL (any version, two or later), regardless of their creator. Included third-party libraries must also be compatible. For a specific list of compatible licenses, please read the [GPL-Compatible license list](https://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses) on gnu.org.
+Although any GPL-compatible license is acceptable, using the same license as WordPress — “GPLv2 or later” — is strongly recommended. All code, data, and images — anything stored in the plugin directory hosted on WordPress.org — must comply with the GPLv2. Included third-party libraries, code, images, or otherwise, must be compatible. For a specific list of compatible licenses, please read the <a href="https://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses">GPL-Compatible license list</a> on gnu.org.

guideline-02.md

@@ -1,3 +1,5 @@
-**2. Plugin developers are responsible for the files they upload and services they utilize.**
+<h4>2. Developers are responsible for the contents and actions of their plugins.</h4>
 
-It is the sole responsibility of the plugin developer to ensure all files within their plugins comply with the guidelines. They are expected to confirm, before uploading to SVN, the licensing of all included files, from original source code to images and libraries. In addition, they must comply to the terms of use for all third party services and APIs utilized by their plugins. If there is no way to validate the licensing of a library or the terms of an API, then they cannot be included.
+It is the sole responsibility of plugin developers to ensure all files within their plugins comply with the guidelines. Intentionally writing code to circumvent guidelines, or restoring code they were asked to remove, is prohibited (see #9 illegal/dishonest actions).
+
+Developers are expected to confirm, before uploading to SVN, the licensing of all included files, from original source code to images and libraries. In addition, they must comply to the terms of use for all third party services and APIs utilized by their plugins. If there is no way to validate the licensing of a library or the terms of an API, then they cannot be used.

guideline-03.md

@@ -1,3 +1,5 @@
-**3. A stable version of your plugin must be available from its WordPress Plugin Directory page.**
+<h4>3. A stable version of a plugin must be available from its WordPress Plugin Directory page.</h4>
 
-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.
+
+Distributing code via alternate methods, while not keeping the code hosted here up to date, may result in a plugin being removed.

guideline-04.md

@@ -1,3 +1,3 @@
-**4. Keep your code (mostly) human readable.**
+<h4>4. Code must be (mostly) human readable.</h4>
 
-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/)
+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 <a href="https://make.wordpress.org/core/handbook/best-practices/coding-standards/">WordPress Core Coding Standards</a>

guideline-05.md

@@ -1,7 +1,5 @@
-**5. Trialware is _not_ allowed in the directory.**
+<h4>5. Trialware is not permitted.</h4>
 
-Attempting to upsell the user on other products and features is acceptable within limits.
+Plugins may not contain functionality that is restricted or locked, only to be made available by payment or upgrade. They may not disable included functionality after a trial period or quota. Paid functionality in services _is_ permitted (see guideline 6: serviceware), provided all the code inside a plugin is fully available. 
 
-* 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.
+We recommend the use of add-on plugins, hosted outside of WordPress.org, in order to exclude the premium code. Attempting to upsell the user on other products and features is acceptable within limits of guideline 11 (don't hijack the admin); they should not be overly prominent or annoying to users.

guideline-06.md

@@ -1,4 +1,4 @@
-**6. Software as a Service _is_ permitted in the directory.**
+<h4>6. Software as a Service is permitted.</h4>
 
 Plugins that act as an interface to some external third party service (e.g. a video hosting site) are allowed, even for paid services. The service itself must provide functionality of substance and be clearly documented in the readme file submitted with the plugin, preferably with a link to the service’s Terms of Use.
 

guideline-07.md

@@ -1,12 +1,13 @@
-**7. The plugin may not “phone home” or track users without their informed, explicit, opt-in consent.**
+<h4>7. Plugins may not track users without their consent.</h4>
 
-In the interest of protecting user privacy, plugins may not contact external servers without the explicit consent of the user via requiring registration with a service or a checkbox within the settings. This method is called ‘opt in.’ Documentation on how any user data is collected, and used, should be included in the plugin’s readme, preferably with a clearly stated privacy policy.
+In the interest of protecting user privacy, plugins may not "phone home" by contacting external servers without the _explicit_ and authorized consent of the user via requiring registration with a service or a checkbox within the settings. This method is called ‘opt in.’ Documentation on how any user data is collected, and used, should be included in the plugin’s readme, preferably with a clearly stated privacy policy.
 
-This restriction includes the following:
+Some examples of prohibited tracking include:
 
-* No unauthorized collection of user data. Users may be asked to submit information but it cannot be automatically recorded without  explicit confirmation from the user. 
-* Intentionally misleading users into submitting information as a requirement for use of the plugin itself is prohibited.
-* Images and scripts should be loaded locally as part of the plugin whenever possible. If external data (such as blocklists) is required, their inclusion must be made clear to the user.
-* Any third party advertisement mechanisms used within the plugin must  have all tracking features disabled by default. Advertisement mechanisms which do not have the capability of disabling user tracking features are prohibited.
+* Automated collection of user data without explicit confirmation from the user.
+* Intentionally misleading users into submitting information as a requirement for use of the plugin itself.
+* Offloading images and scripts when not acting as a service.
+* Undocumented (or poorly documented) use of external data (such as blocklists).
+* Third-party advertisement mechanisms which track usage and/or views.
 
-The sole exception to this policy is Software as a Service, such as Twitter, an Amazon CDN plugin, or Akismet. By installing, activating, registering, and configuring plugins that utilize those services, consent is granted for those systems.
+An exception to this policy is Software as a Service, such as Twitter, an Amazon CDN plugin, or Akismet. By installing, activating, registering, and configuring plugins that utilize those services, consent is granted for those systems.

guideline-08.md

@@ -1,9 +1,11 @@
-**8. The plugin may not send executable code via third-party systems.**
+<h4>8. Plugins may not send executable code via third-party systems.</h4>
 
 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:
 
 * Serving updates or otherwise installing plugins, themes, or add-ons from servers other than WordPress.org’s
 * Installing premium versions of the same plugin
 * Calling third party CDNs for reasons other than font inclusions; all non-service related JavaScript and CSS must be included locally
 * Using third party services to manage regularly updated lists of data, when not explicitly permitted in the service’s terms of use
-* Using iframes to connect admin pages; APIs should be used to minimize security risks
+* Using iframes to connect admin pages; APIs should be used to minimize security risks
+
+Management services that interact with and push software down to a site _are_ permitted, provided the service handles the interaction on it's own domain and not within the WordPress dashboard.

guideline-09.md

@@ -1,16 +1,18 @@
-**9. The plugin and its developers must not do anything illegal, dishonest, or morally offensive.**
+<h4>9. Developers and their plugins must not do anything illegal, dishonest, or morally offensive.</h4>
 
 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
+* Compensating, misleading, pressuring, extorting, or blackmailing others for reviews or support
 * 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
+* Utilizing the user’s server or resources without permission, such as part of a botnet or crypto-mining
 * 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
+* Intentionally attempting to exploit loopholes in the guidelines

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.**
+<h4>10. Plugins may not embed external links or credits on the public site without explicitly asking the user’s permission.</h4>
 
-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

@@ -1,9 +1,9 @@
-**11. The plugin should not hijack the admin dashboard.**
+<h4>11. Plugins should not hijack the admin dashboard.</h4>
 
 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 must 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 must 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.
+Advertising within the WordPress dashboard should be avoided, as they are generally ineffective. Users rarely visit settings screens, and when they do, they're trying to solve a problem. Making it harder to use a plugin does not generally encourage a good review, and we recommend limiting any ads placed therein. Remember: tracking referrals via those ads is not permitted (see guideline 7) and most third-party systems do not permit back-end advertisements. Abusing the guidelines of an advertising system will result in developers being reported upstream.
 
 Developers are welcome and encouraged to include links to their own sites or social networks, as well as locally (within the plugin) including images to enhance that experience.

guideline-12.md

@@ -1,9 +1,9 @@
-**12. Public facing pages on WordPress.org (readmes) may not spam.**
+<h4>12. Public facing pages on WordPress.org (readmes) must not spam.</h4>
 
 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,5 +1,5 @@
-**13. The plugin should make use of WordPress' default libraries.**
+<h4>13. Plugins must use WordPress' default libraries.</h4>
 
-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.
+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. Instead plugins must use the versions of those libraries packaged with WordPress.
 
 For a list of all javascript libraries included in WordPress, please review [Default Scripts Included and Registered by WordPress](https://developer.wordpress.org/reference/functions/wp_enqueue_script/#notes).