WIP: Clarifications to Guidelines re Privacy and Advertising.

guideline-01.md

@@ -1,3 +1,3 @@
-<h4>1. Plugins must be compatible with the GNU General Public License v2</h4>
+<h4>1. Plugins must be compatible with the GNU General Public License v2 (or later).</h4>
 
-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.
+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 that license, including third-party libraries. 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,5 +1,5 @@
 <h4>2. Developers are responsible for the contents and actions of their plugins.</h4>
 
-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).
+It is the responsibility of plugin developers to ensure all files within their plugins comply with the guidelines. Intentionally writing code to circumvent guidelines, or restoring code previously asked to be removed, is prohibited.
 
-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.
+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,5 +1,5 @@
 <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 people may develop their code somewhere else, users will be downloading from the directory, not the development environment.
+The only version of the plugin that WordPress.org distributes is what is hosted in the directory. Authors may develop their code where they wish, but users will be only download the completed product from the WordPress.org directory.
 
-Distributing code via alternate methods, while not keeping the code hosted here up to date, may result in a plugin being removed.
+Distributing code via alternate methods, while not keeping the code hosted on WordPress.org up to date, is not permitted.

guideline-05.md

@@ -2,6 +2,6 @@
 
 Plugins may not contain functionality that is restricted or locked, only to be made available by payment or upgrade. Functionality may not be disabled after a trial period or quota is met. In addition, plugins that provide sandbox only access to APIs and services are also trial, or test, plugins and not permitted.
 
-Paid functionality in services is permitted (see guideline 6: serviceware), provided all the code inside a plugin is fully available. We recommend the use of add-on plugins, hosted outside of WordPress.org, in order to exclude the premium code. Situations where a plugin is intended as a developer tool only will be reviewed on a case by case basis.
+Paid functionality in services is permitted as serviceware, provided all the code inside a plugin is fully available. We recommend the use of add-on plugins, hosted outside of WordPress.org, in order to exclude any premium code. Situations where a plugin is intended as a developer tool only will be reviewed on a case by case basis.
 
-Attempting to upsell the user on ad-hoc products and features <em>is</em> acceptable, provided it falls within bounds of guideline 11 (hijacking the admin experience).
+Attempting to upsell the user on ad-hoc products and features <em>is</em> acceptable, provided it falls within bounds of other guidelines.

guideline-06.md

@@ -1,11 +1,11 @@
 <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.
+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, complete with a link to the service’s Terms of Use and/or Privacy Policy.
 
-Services and functionality <em>not</em> allowed include:
+Services and functionalities that are <em>not</em> allowed include:
 
 <ul>
 	<li>A service that exists for the sole purpose of validating licenses or keys while all functional aspects of the plugin are included locally is not permitted.</li>
 	<li>Creation of a service by moving arbitrary code out of the plugin so that the service may falsely appear to provide supplemented functionality is prohibited.</li>
-	<li>Storefronts that are not services. A plugin that acts only as a front-end for products to be purchased from external systems will not be accepted.</li>
-</ul>
+	<li>Storefronts. A plugin that acts only as a front-end for products to be purchased and installed from external systems will not be accepted.</li>
+</ul>

guideline-07.md

@@ -1,8 +1,8 @@
 <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 <em>explicit</em> and authorized consent. This is commonly done via an 'opt in' method, requiring registration with a service or a checkbox within the plugin settings. 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 contact external servers without <em>explicit</em> and authorized consent. This is commonly done via an 'opt in' method, requiring registration with a service, or a checkbox within the plugin settings. Documentation on how any user data is collected, and used, must be included in the plugin’s readme, with a link to a clearly stated Terms of Use and/or Privacy Policy.
 
-Some examples of prohibited tracking include:
+Some examples of <em>prohibited</em> tracking include:
 
 <ul>
 	<li>Automated collection of user data without explicit confirmation from the user.</li>
@@ -12,4 +12,4 @@ Some examples of prohibited tracking include:
 	<li>Third-party advertisement mechanisms which track usage and/or views.</li>
 </ul>
 
-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.
+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

@@ -3,11 +3,11 @@
 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:
 
 <ul>
-	<li>Serving updates or otherwise installing plugins, themes, or add-ons from servers other than WordPress.org’s</li>
+	<li>Serving updates or otherwise installing plugins, themes, or add-ons from locations other than WordPress.org</li>
 	<li>Installing premium versions of the same plugin</li>
-	<li>Calling third party CDNs for reasons other than font inclusions; all non-service related JavaScript and CSS must be included locally</li>
+	<li>Calling third party CDNs for reasons other than font inclusions (all non-service related JavaScript and CSS must be included locally)</li>
 	<li>Using third party services to manage regularly updated lists of data, when not explicitly permitted in the service’s terms of use</li>
-	<li>Using iframes to connect admin pages; APIs should be used to minimize security risks
+	<li>Using iframes to connect admin pages (APIs should be used to minimize security risks)</li>
 </ul>
 
-Management services that interact with and push software down to a site <em>are</em> permitted, provided the service handles the interaction on it's own domain and not within the WordPress dashboard.
+Services that act as site management tools that interact with and push software down to a site <em>are</em> permitted. The management service must handle the interaction on its own domain, however, not within the WordPress dashboard.

guideline-09.md

@@ -3,14 +3,16 @@
 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:
+
 <ul>
-	<li>Artificially manipulating search results via keyword stuffing, black hat SEO, or otherwise</li>
-	<li>Offering to drive more traffic to sites that use the plugin</li>
+	<li>Artificially manipulating search results (e.g. via keyword stuffing, black hat SEO, hidden links)</li>
+	<li>Offering to drive traffic to sites that use the plugin</li>
 	<li>Compensating, misleading, pressuring, extorting, or blackmailing others for reviews or support</li>
+	<li>Compensating other developers to include advertisements for unrelated products</li>
 	<li>Implying users must pay to unlock included features</li>
-	<li>Creating accounts to generate fake reviews or support tickets (i.e. sockpuppeting)</li>
+	<li>Creating accounts to generate fake reviews or support tickets (e.g. sockpuppeting)</li>
 	<li>Taking other developers’ plugins and presenting them as original work</li>
-	<li>Implying that a plugin can create, provide, or guarantee legal compliance</li>
+	<li>Implying or claiming that a plugin can create, provide, or guarantee full legal compliance</li>
 	<li>Utilizing the user’s server or resources without permission, such as part of a botnet or crypto-mining</li>
 	<li>Violations of the <a href="https://make.wordpress.org/community/handbook/wordcamp-organizer/planning-details/code-of-conduct/">WordCamp code of conduct<a></li>
 	<li>Violations of the <a href="https://wordpress.org/support/guidelines/">Forum Guidelines</a></li>

guideline-10.md

@@ -1,3 +1,7 @@
-<h4>10. Plugins may not embed external links or credits on the public site without explicitly asking the user’s permission.</h4>
+<h4>10. Plugins may not embed external links or credits on the public site without explicit permission.</h4>
 
-All "Powered By" or credit displays and links included in the plugin code must be optional and default to <em>not</em> 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 <em>are</em> 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 <em>not</em> show on 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, nor may they require specific actions such as leaving a review in order to have them removed.
+
+Services <em>are</em> permitted to brand their output as they see fit, provided the code is output from the service itself via methods such as oEmbed.

guideline-11.md

@@ -1,9 +1,21 @@
-<h4>11. Plugins should not hijack the admin dashboard.</h4>
+<h4>11. Plugins must 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.
+Preventing users from completing desired tasks via constant alerts, messages, and advertisements is prohibited behavior. When plugins get between users and their work it creates a poor experience. Overwhelming the admin dashboard to the point of where it is no longer usable is detrimental to WordPress as a whole.
 
-Upgrade prompts, notices, alerts, and the like must be limited in scope and used sparingly, be that contextually or only on the plugin’s setting page. Site wide notices or embedded dashboard widgets <em>must</em> 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.
+At the same time, in order to support the plugin ecosystem it is permitted for plugins to display messages as to their functionality, as well as to promote included features. These messages must be done with consideration and care towards usability. All messages must display only for the appropriate users (i.e. people who can action on them).
 
-Advertising within the WordPress dashboard should be avoided, as it is generally ineffective. Users normally only visit settings pages when 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.
+Any messages added by a plugin must be <strong>permanently</strong> dismissible. This may be done either by a user's direct action (clicking a 'dismiss' button) or by self-removal when an issue is resolved. Messages are to be limited in scope to one per page, with an exception granted to a plugin's individual settings page(s).
 
-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.
+Included advertisements for add-ons, upsells, or services must <em>directly</em> relate to the plugin and/or developer. Affiliate links must go directly to the affiliate and not a 3rd party URL shortener.
+
+Examples of violations include (but are not limited to):
+
+<ul>
+    <li>Messages that cannot be dismissed, nor resolved</li>
+    <li>Messages that repeat regularly and cannot be permanently dismissed</li>
+    <li>Multiple messages on any one page, other than a plugin's own setting page(s)</li>
+    <li>Advertisements for unrelated products (such as a favored forms plugin when it has no relationship to the active plugin)</li>
+    <li>Hidden affiliate links to other services (such as hosting, Amazon, etc)</li>
+</ul>
+
+Abuse of the notifications system often result in poor reviews from users. Those reviews will not be removed.

guideline-12.md

@@ -1,9 +1,20 @@
 <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.
+Public facing pages, including readmes and translation files, may not be used to spam or advertise.
 
-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.
+Prohibited behavior includes (but is not limited to):
+<ul>
+    <li>unnecessary affiliate links</li>
+    <li>tags to competitors plugins</li>
+    <li>use of over 12 tags total</li>
+    <li>blackhat SEO practices</li>
+    <li>content spinning</li>
+    <li>advertising services</li>
+    <li>keyword stuffing</li>
+</ul>
 
-Readmes are to be written for people, not bots.
+Links to directly required products, such as themes or other plugins needed for use, are permitted within reason. Affiliate links must be disclosed and must directly link to the affiliate service, not a redirect or cloaked URL. Promoting products and services unrelated to the plugin, such as discounts to hire a company for bespoke work, are not permitted
 
-In all cases, affiliate links must be disclosed and must directly link to the affiliate service, not a redirect or cloaked URL.
+While related products may be used in tags, the use of competitors' tags is not. If a plugin is a WooCommerce extension, it may use the tag 'woocommerce.' However if the plugin is an <em>alternative</em> 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.
+
+We recommend readmes be written to educate and introduce users to a plugins' merits, not as a self-promotional project.

guideline-14.md

@@ -1,5 +1,7 @@
 <h4>14. Frequent commits to a plugin should be avoided.</h4>
 
-The SVN repository is a release repository, not a development one. All commits, code or readme files, will trigger a regeneration of the zip files associated with the plugin, so only code that is ready for deployment (be that a stable release, beta, or RC) should be pushed to SVN. Including a descriptive and informative message with each commit is strongly recommended. Frequent ‘trash’ commit messages like ‘update’ or ‘cleanup’ makes it hard for others to follow changes. Multiple, rapid-fire commits that only tweak minor aspects of the plugin (including the readme) cause undue strain on the system and can be seen as gaming Recently Updated lists.
+The SVN repository is a release repository, not a development one. All commits, code or readme files, will trigger a regeneration of the zip files associated with the plugin, so only code that is ready for deployment (be that a stable release, beta, or RC) should be pushed to SVN.
 
-An exception to this is when readme files are updated solely to indicate support of the latest release of WordPress.
+All commits are required to include a message. It is recommended this be descriptive and informative. Frequent commit messages like ‘update’ or ‘cleanup’ makes it hard for others to follow changes. Multiple, rapid-fire commits that only tweak minor aspects of the plugin (including the readme) cause undue strain on the system and can be seen as gaming Recently Updated lists.
+
+An exception to this is when readme files are updated solely to indicate support of the latest release of WordPress.