Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Clarifications to Guidelines re Privacy and Advertising. #66

Closed
wants to merge 17 commits into from

Conversation

@Ipstenu
Copy link
Collaborator

commented Apr 4, 2019

Proposal to Modify Plugin Guidelines

This post is a proposal of changes to be made to the Plugin Guidelines. The majority of changes are intended to address significant issues faced by ESL developers. This proposal also contains a significant rewrite to the lamented 11th Guideline (hijacking the admin dashboard).

This proposal will remain open until after WordCamp EU 2019, at which point it will be closed and either re-proposed (if there are significant changes), implemented, or scrapped. The intent is to make a decision by end of June.

The rest of this post will go over an overview of intent, the proposed changes (with summary), and information as to how to contribute. All community members are welcome to participate.

Overview

In working with ESL developers, it was mentioned that a number of confusion points were due to the semantics of translations. With that in mind, we have made a series of grammatical clarifications and sentence tightenings. The initial purpose was not to eliminate loopholes, but to make it more clear to someone who is not a native English speaker that certain things are not okay.

During that work, it came to light that guideline 11 (don’t spam the admin dashboard) was in need of overhaul. The overall intent of the goal was not well understood, and within-guideline changes were being criticized heavily to the detriment of the community at large. To that end, guideline 11 received a significant rewrite.

Our overall goal with the 11th guideline was to balance the needs of users to be able to actually use the admin dashboard while permitting needed notifications. The discord arises when these notifications are split between what is needed and what is wanted. Do users need to know about add-ons? In some cases, yes.

While it would be nice to say "We'll know [spam] when we see it," that is neither helpful to the developer community nor is it maintainable by any number of volunteers at scale. A guideline that cannot be managed is as worthless as no guideline at all.

This necessitated us changing our goal. We now intend to grant developers a limited but reasonable space to notify the appropriate users of needed and related features (including products and add-ons) while allowing all users the freedom and ability to maintain agency over their own website.

Because a site can have many plugins, allowing all plugins to put multiple ads on multiple pages can quickly make the Dashboard look like a Las Vegas roadside. Our understanding is that a cluttered and unmanageable Dashboard upsets users, making it harder for them to do what they want. This behavior, if enacted by all plugins, could cause WordPress irreparable harm.

In order to achieve that, the following changes have been proposed:

  • Admin messages and advertisements must be limited to one per common page.
  • Messages must only be shown to people who can action on them. For example, don’t show ‘install X!’ to a user who can’t install anything.
  • All messages must be permanently dismissible by an action on a page (such as clicking a dismiss button or an X to close). Filters are insufficient, as not all users are capable of implementing them.
  • No repeatable messages. If a user has been asked to “Try this add-on!” and said no, their choice must be respected. (nb. exceptions will be granted for reminders to complete setup.)
  • All ‘advertisement’ type messages have to directly relate to the developer or the plugin. Ads for other things a developer happens to like aren't permitted.

What this proposal will not cover:

  • Injecting into search results. - We already said ads have to be dismissible, so that would be in effect. We are choosing to defer to trac #46763 for the rest but reserve the right to revisit this later.
  • Spamming a plugin's own settings pages. - If a plugin wants to make their own admin pages unusable and spammy, they're permitted to do so. Negative reviews left by users regarding this will not be removed, however.
  • Violations of existing guidelines. - We already said no tracking users and so on, so that doesn’t need to be repeated.
  • Covering every possible loophole in detail. - While that is laudable, it's impossible and would make the guidelines incomprehensible. Also in the past it's led to people playing 'rules lawyer' to get away with behavior.

Summary of proposed changes:

  • Intro: 'are expected to' -> must. You must follow the guidelines.
  • 01: "or later" added for completeness.
  • 02: Removing redundant parenthetical. Remove 'sole' as that is misunderstood in some languages to mean it's their only responsibility, instead of 'its your own responsibility.' Correcting bad grammar.
  • 03: Declaring that not using hosting isn't allowed (i.e. we will close your plugin). Clarify that anyone can dev where they want, but only what we host is what users get.
  • 05: Remove parenthetical in favor of a complete sentence.
  • 06: Due to GDPR we require ToS/Privacy. Remove unneeded reiteration. Clarify that installation via storefronts are also prohibited.
  • 07: Due to GDPR we require ToS/Privacy. Emphasis on prohibited.
  • 08: Formatting fixes and changing 'servers' to 'locations' due to specific actions by a bad actor. Bad grammar and run on sentences.
  • 09: Formatting and grammar. Clarifying compliance.
  • 10: Removing extraneous words. Breaking apart paragraphs for readability.
  • 11: Major Rewrite to limit abuse of WordPress dashboard notifications and messaging.
    1. Break out the list into something more visual, specifically target ads and promotions on the read. Try to be less pejorative overall.
  • 14: Breaking apart sentences and paragraphs for readability. Removing pejorative for 'trash' commits.
  • 16: Removing parenthetical
  • 17: Grammar

Contributing

Everyone is welcome and encouraged to comment on this proposal. You may comment on the make.wordpress.org/plugins post, reply on the Github Pull Request, or create a new issue as you see fit.

We ask that if you choose to partake in this process, that you behave with kindness to all involved. This is doubtless a hotly contested topic and tempers will flare. Abusive comments, personal attacks, or accusations of impropriety will be moderated.

  1. Assume good intentions.
  2. Don't attack the idea or the person.
  3. Be mindful of everyone's concerns.
  4. Treat others how you would like to be treated.

NB: There's a lot of conversation that stemmed from the ORIGINAL pull request. Please feel free to ignore anything prior to May 2019.

Ipstenu added 2 commits Sep 18, 2018
Update clarifications on advertising
* 2: Removing redundant parenthetical
* 3: Declaring that not using hosting isn't allowed (i.e. we will close 
your plugin)
* 6: Due to GDPR we require ToS/Privacy
* 7: Due to GDPR we require ToS/Privacy
* 8: Formatting fixes.
* 11: Simplify the explanations regarding advertising.
@digitalchild

This comment has been minimized.

Copy link

commented on 1aab57a Apr 4, 2019

I disagree with guideline-11 updates you are opening the floodgates to advertising within plugins. It's bad enough with themes, now you're allowing advertising 'within reason', what does that even mean?

This comment has been minimized.

Copy link

replied Apr 4, 2019

So, where is the discussion about the change in guideline-11?
Who decided it should be changed?

If WordPress is community based, shouldn't the community be involved about changing this?

And what's with the change in guideline-03? Changing may result in a plugin being removed. to is not permitted. looks like a weaker statement. What if a plugin dev decides to host somewhere else, what are the consequences, now that a plugin clearly cannot be removed based on this..

This comment has been minimized.

Copy link

replied Apr 4, 2019

Any time I've been presented with a contract that included the phrase 'within reason' I made sure it was rewritten to have clear limits. 'Within reason' is far too subjective. What one person considers 'within reason' will vary wildly from what another person considers 'within reason'. Whose reason?

This comment has been minimized.

Copy link

replied Apr 4, 2019

What does directly related to the developer mean? Can I use one of my plugins to advertise a different, completely unrelated plugin just because I'm the developer of both?

Can I advertise my consulting services of Laravel because the advertisement directly relates to me, the developer?

Can I advertise my etsy shop, as that also directly relates to me, the developer?

This comment has been minimized.

Copy link

replied Apr 4, 2019

permitted within reason

This is not something that should be included in a guideline because it's very subjective.

This comment has been minimized.

Copy link
Collaborator Author

replied Apr 4, 2019

I just don’t see what you see.

When you say that, regardless of your intent, you ARE being dismissive.

It’s hurtful to the greater WordPress community to see you propose these specific out-of-context recommendations to the guidelines, without a link to an issue or ticket or discussion.

They're not a proposal of ANYTHING yet!

How many times do I have to say it? This branch was a WORK IN PROGRESS. I made a PR so someone who doesn't GitHub could see it better, and there was NO PROPOSAL AT ALL being made.

What have I ever done to make you think I would do that unilaterally?

I've NEVER made a change without proposing it to, at the very least, the plugins team itself. EVERY single change I've made, since I rewrote these two years ago, has been public and explained. In fact, historically you can see that I PROPOSED changes in 2017 in public to address concerns following the PUBLIC rewrite.

Again. There is NO proposal. IF I get this to a place where I feel it's ready, I'll remake a pull request, pitch it as a proposal to plugins, and then to everyone via the make blog.

This comment has been minimized.

Copy link

replied Apr 4, 2019

I'm sorry for the harm I caused :(. I know you're under an immense amount of pressure already, and I do appreciate all that you do.

To explain (not excuse), the way I work with others is that a PR is an indication that the author deemed the changeset ready to be merged in / discussed / reviewed, unless specifically indicated otherwise (either by WIP in the title, or a WIP tag). For me the questions stemmed from that.

This comment has been minimized.

Copy link
Collaborator Author

replied Apr 4, 2019

To explain (not excuse), the way I work with others is that a PR is an indication that the author deemed the changeset ready to be merged in / discussed / reviewed, unless specifically indicated otherwise (either by WIP in the title, or a WIP tag)

I understand, which is why I pulled the PR. Not to stifle discussion, but to express that it was a draft. That was my bad, and I acknowledged it.

This comment has been minimized.

Copy link

replied Apr 4, 2019

When you say that, regardless of your intent, you ARE being dismissive.

No, I’m not. I literally considered that the comments here might be people attacking you, and they aren’t. Everyone gave you feedback on a public pull request with comments open.

If they were confused, or giving you feedback you didn’t want, that isn’t their fault.

Deep dives into someone’s personal internet drama are not prerequisites for commenting on their professional pull requests.

(And if I had dug into Twitter, which I did now thanks to you bringing it up, and had I linked to things you said, then I’d be witch-hunting, so how does that solve anything?)

I don’t care what other people are saying anywhere else but here, because here is what matters. I only care here about what I see here.

What have I ever done to make you think I would do that unilaterally?

I don’t keep a scorecard of offenses. No one is beyond reproach. You proved that earlier by scolding me for things I didn’t say. My previous contributions didn’t change your reaction to me.

There is NO proposal

I get it. But that’s what pull requests are, though.

I get that you feel people are against you, and maybe they are somewhere. I’m not.

Sorry again, again.

This comment has been minimized.

Copy link

replied Apr 4, 2019

I don't think this is a good direction for the software.

Ipstenu added 3 commits Apr 4, 2019
11. Major change
* Yes, ads are allowed.
* All ads must be PERMANENTLY dismissable
* ONE ad per non-setting page.

7: Typo fix, props @JPry
Intro: Attempting to compensate for multiple languages.
3: Clarify what 'here' is
6: Complete sentances are gooder
@jarretc

This comment has been minimized.

Copy link

commented Apr 4, 2019

A related tangent here. My personal goal with these guidelines is to create something lasting. One day, I won't be in charge of plugins, and whomever replaces me needs to have something solid to back them up when they are tasked to handle situations like a plugin with a million users accidentally pushing bad code that tracks users. Should they close that plugin? How much harm will it cause if they do? How much trust can and should be given to individuals and companies? How does anyone earn that trust? etc etc.

Yes, the plugin should be closed if deemed harmful to the users. If somebody murders another person, they are prosecuted and punished accordingly. If you have 10,000 people all of a sudden kill another person, those people should be prosecuted as well even if it means a sudden impact on the court system having to handle the influx of data to process. Just because a plugin is large and popular should not exclude it from the same restrictions that a smaller plugin has to follow.

The plugin team is in charge of adding/removing/moderating plugins. The plugin team should not be concerned that a plugin's support team will be inundated with issues just because the plugin broke rules/violations/guidelines.

  1. Yes ads are permitted (they always have been)
  2. Outside a plugin's own settings page(s), they must limit themselves to ONE dashboard notification per page
  3. All notifications must be permanently dismissible
  4. Repeat advertisements are not permitted
  5. All other guidelines (i.e. no tracking) still apply

In regards to 2, what is defined as a dashboard notification? If the "notification" refers to something like "Hey, we have this other plugin, make sure to check it out." That is an ad

If that is the case, allowing that notification to exist to only one notification per page is in conflict with 4 as every page load would expose the user to the same notification as in repeat exposure

@Ipstenu

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 4, 2019

In regards to 2, what is defined as a dashboard notification? If the "notification" refers to something like "Hey, we have this other plugin, make sure to check it out." That is an ad

That would be an ad, yes. A notification would be "Hey this plugin needs you to turn on Pretty Permalinks." or "You haven't finished configuring me. Come back!" or even "Thanks for using me for a month. Could you please review me?"

The plugin team should not be concerned that a plugin's support team will be inundated with issues just because the plugin broke rules/violations/guidelines.

I meant the volunteer forums, not the individual plugin, but I do disagree here. The plugins team should be concerned with the impact made by closing a plugin. Mind you, I think that everyone who does anything with WordPress should ask themselves this: "Could this be considered harmful to the entire WordPress ecosystem?"

It's a subset of ethical development, asking yourself what's the WORST thing someone can do with your code.

Ipstenu added 2 commits Apr 5, 2019
11. Elaboration on purpose
An attempt to adjust the wording to highlight the need for this 
guideline. tl;dr we're trying to prevent the dashboard from being blinky 
spammy billboards. It makes it HARDER for people to find anything if you 
keep getting in their way.
Tightening Language
One thing here, it's better to not specific a number for a guideline if 
we don't have to, so if we renumber them, we don't go insane fixing it.

Intro: 'are expected to' -> MUST. You MUST follow the guidelines.
01. "or later" added becuase that's literally what it is. Removing 
duplicate sentance.
02. Remove 'sole' as that is misundertood in some languages to mean it's 
their ONLY responsibility, instead of 'its your own responsibility.' 
Correcting bad grammar.
03. Clarify that you can dev where you want, but only what we host is 
what user's get.
05. Remove parenthetical in favor of a complete sentance.
06. Remove unneeded reitteration. We already said 'things that aren't a 
service' so leave the dead horse alone.
07. Emphasis on PROHIBITED
08. Bad grammar and run on sentances.
09. Formatting and grammar. Clarifying compliance.
10. Removing extranous words.
11. Prioritizing the WHY of the gudeline before devling into the 
details. It may be better to list what kinds of ads are not allowed, but 
that would be a complicated list to curate. Attempting to explain with 
an example ...
14. Breaking apart sentances and paragraphs for readability. Removing 
pejorative for 'trash' commits.
17. Grammar
guideline-11.md Outdated Show resolved Hide resolved
Ipstenu added 3 commits Apr 9, 2019
Grammar Stuff
11. Language - props @afragen. Also trying to make a stronger first 
paragraphs. Spelling error.
2. Previous -> Previously
There's a Tom Lehrer song about the LY that seems rather appropriate 
here...
Avoid contractions
Cleaning up some confusing English for 17.
@afragen

This comment has been minimized.

Copy link

commented on guideline-11.md in 7e2a57e Apr 9, 2019

While this behavior creates a very poor user experience, do we want prohibit or strongly discourage. I think a differentiation should be made to the plugin’s setting page and other places in the dashboard.

I have this issue the time. People may poor choices and they suffer the consequences. In this case poor reviews, etc.

This comment has been minimized.

Copy link
Collaborator Author

replied Apr 10, 2019

do we want prohibit or strongly discourage

Strongly discourage. I'm aware we're setting people up for a lousy experience if a specific plugin spams the HELL out of their admin screen (Woo comes to mind) but at the same time, if someone WANTS to make their plugin unusable, then fine. Hurt yourself.

I explained this in the description of the pull:

A concern people will have is that yes, this does allow for people to put a million ads on their own plugins settings pages. Yes, that means some plugins may become frustrating and unusable for the masses. We have chosen to permit this because it's simply impossible to micro-manage everyone and a guideline we cannot enforce properly is useless. We also feel a far better way to 'manage' this kind of abuse is to let it out itself. People can be very vocal about what they like and dislike, and they are encouraged to express distaste via 1-star reviews.

This comment has been minimized.

Copy link

replied Apr 10, 2019

Thanks Mika. My comment re:prohibit or discourage was because I see the new language uses the words prohibited behavior.

I might be misreading it.

@afragen

This comment has been minimized.

Copy link

commented on guideline-11.md in 7e2a57e Apr 9, 2019

I really want core to be able to provide this.

@afragen
Copy link

left a comment

On the whole I like how this is progressing. Great work.

Fixes:
07 - Make the language match 6.
09 - Remove 'you'
10 - Better phrasing and removing real examples
17 - Consistency in name of fake plugin example
guideline-09.md Outdated Show resolved Hide resolved
Ipstenu added 2 commits May 1, 2019
Grammar Cleanup
11.
Wrong Word: economy -> ecosystem
Stop runaway run-on sentances
Remove redundancy.
Clarification of last two sentances.

12. Structure and layout. Lists seem to help people visualize the bad.
@DavidAnderson684

This comment has been minimized.

Copy link

commented May 14, 2019

I think that "permanently dismissible" is too extreme. Plugins in wordpress.org are all free, often with free support too, and some of them are "set-it-and-forget-it" (i.e. the user will never again visit the settings page). Showing, say, an annual "Hi, thanks for using plugin X, would you consider looking at our other stuff? (link) or (dismiss)" notice is a pretty small thing in return for a year's plugin use.

There are interests to be balanced - but one notice shown "for life" on the site is a too-strong move against developers. Various Automattic plugins are eternally visible whenever you visit "Plugins -> Add New -> Featured" or "Plugins -> Add New -> Recommended". This change tips too strongly against other developers. It ought to be "dismissible for at least X" - I suggest 3 months.

guideline-03.md Outdated Show resolved Hide resolved
@DavidAnderson684

This comment has been minimized.

Copy link

commented May 14, 2019

The changes in 11. also raise a meta question for me. Of course, there's always a big grey area between these two things, but, is the point of the guidelines to a) protect the user from clear harm and hostile actions from would-be plugin developers or b) to enforce a set of centralised preferences?

As I say, the difference between those is often not clear cut, and the plugin team has the hard work of working out in particular cases where the boundary lines. But I am concerned about the change in 11 being a move towards the plugin directory as (in effect, if not in intention) a curated directory where a centralised set of preferences are enforced. I'd prefer, in areas where it's "don't do dumb things that annoy your users (even if not things that harm them)" to leave it to the market. If a plugin wants to spam and annoy users and ruin its own reputation by doing, and drive its users to a competitor, then let it. Let the guidelines aim to be things that prevent illegality and direct harm, rather than enforcing opinions and being "nanny" via being overly presciptive.

guideline-06.md Outdated Show resolved Hide resolved
Update guideline-03.md
Remove extraneous 'be' - props @DrewAPicture

Co-Authored-By: Drew Jaynes <DrewAPicture@users.noreply.github.com>
@Ipstenu

This comment has been minimized.

Copy link
Collaborator Author

commented May 14, 2019

@DavidAnderson684

Showing, say, an annual "Hi, thanks for using plugin X, would you consider looking at our other stuff? (link) or (dismiss)" notice is a pretty small thing in return for a year's plugin use.

Turn that around though. If you have 20 plugins (not an unreasonable amount) and all plugins do that every year, it's going to interfere with what you're doing. The other main issue here is that if we say "Once a year is fine" then the plugin review team is now on the hook for giving a promise to users that we cannot possibly keep. It's not fair to the users in that case. You're right, it's a hard line, but given how much it's been abused, we're at the point where we can say "Do whatever" or "This is the line" and make it easier to find and enforce.

The changes in 11. also raise a meta question for me. Of course, there's always a big grey area between these two things, but, is the point of the guidelines to a) protect the user from clear harm and hostile actions from would-be plugin developers or b) to enforce a set of centralised preferences?

Mostly A.

I'd prefer, in areas where it's "don't do dumb things that annoy your users (even if not things that harm them)" to leave it to the market.

The reality is that common sense isn't common (thank you Voltaire). And because what's clearly 'dumb' to you or I isn't clear to someone else, we have to have these guidelines. Enough bad things have happened, where the plugin team is expected to take action, that we are now being forced to do so.

@DavidAnderson684

This comment has been minimized.

Copy link

commented May 14, 2019

The (correct, true) points that power can be abused, and that humans do dumb things, is, to my mind, a reason for not moving the plugin guidelines from the current balance. It is not the case that all people with power concerning plugin guidelines/the directory from now until eternity will automatically use that power wisely and rightly; rather, they'll be human beings like everyone else. "Citizens of the WP community do bad things, therefore more power must be concentrated centrally" is a conclusion I'd disfavour.

"If you have 20 plugins (not an unreasonable amount) and all plugins do that every year"

I'd say:

a) If you go for 20 different free plugins that have 20 different hard-working authors behind them, all of whom want to speak a word to you once a year then that's still reasonable (even though it's statistically unlikely).

b) If it's unbearable, then someone can instead go for either i) paid plugins or ii) free alternatives that don't. The review mechanism is there for you (if you feel this way) to 1-star misguided authors who feel that a mention once a year is reasonable. I've had people do that to me. They're an almost vanishingly tiny number (which is part of why the proposal feels like overkill).

c) You can also deploy (or develop) a plugin to automatically hide those notices. In a GPL universe, that's also possible (and such plugins are in the directory already, though apparently not very popular). If there's demand, people will build and search for it.

@Ipstenu

This comment has been minimized.

Copy link
Collaborator Author

commented May 14, 2019

I have a lot of thoughts running around. This being possibly overkill is absolutely one of them. It's a pendulum swing from where we've been at using the current 'within reason' guideline, which no one clearly understands, to something that I hope CAN be understood.

You may only see a couple 1-star reviews, but that really is a testament to you doing things properly. Which you do :) A number of other plugin developers have rage-quit in the last 18 months because we won't delete those reviews. Or they sock puppet and spam the other way to balance it out. Neither is great for the community.

@hyperpress

This comment has been minimized.

Copy link

commented May 20, 2019

I don't disagree with a single recommendation, especially 11. We're a company that inspects and optimizes hundreds of sites (1,138) last year. I think we've got a pretty good understanding on what competing ad, hijacking admin real estate, and un-dismissible
annoying premium addon looks like for a significant cross section of use cases. And it's a top complaint among site owners. I hope you stay strong on this. There's a way to solicit for premium products and services without undermining the dashboard.

@JJJ
Copy link

left a comment

The word “prohibit” irks me because it starts with “pro” but actually means something else. To me, it always reads like it IS allowed because “pro” typically means “good” (produce, protect, professional, prosper, etc…)

While not specific to this exact set of recommendations, perhaps specific to ESL concerns (and my own dyslexia, I guess) I wonder if this might be a good time to also swap out “prohibit” for “not allowed” to match other “not/allowed” usages in this same document?

guideline-07.md Outdated Show resolved Hide resolved
guideline-08.md Outdated Show resolved Hide resolved
guideline-10.md Show resolved Hide resolved
@JJJ

This comment has been minimized.

Copy link

commented May 20, 2019

I like that there is added emphasis on many of the yes/no wordings.

Is this a good time to recommend sweeping through this document and adding the same emphasis in other places to be consistent? For example, some words and phrases like “must” and “must not” do not have emphasis like similar “not allowed” usages.

guideline-08.md Show resolved Hide resolved
guideline-09.md Show resolved Hide resolved

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.

This comment has been minimized.

Copy link
@JJJ

JJJ May 21, 2019

I love when real-world context accompanies the rules. It provides much-needed clarification as to what the intent of the rule is. I’d love to see this entire document include more snippets like this.

I wonder if there is some way to add styling to these kinds of additions. They read somewhat more casual, but really are useful.

This comment has been minimized.

Copy link
@Ipstenu

Ipstenu May 21, 2019

Author Collaborator

Some guidelines need more context than others. "No Non-GPL code" doesn't but "Your responsible for your code" does (Guideline 2 is next on my hitlist). I'm always worried about making things too long :(

guideline-12.md Outdated Show resolved Hide resolved
guideline-11.md Outdated Show resolved Hide resolved
guideline-14.md Outdated Show resolved Hide resolved
guideline-16.md Show resolved Hide resolved
guideline-17.md Outdated Show resolved Hide resolved
introduction.md Outdated Show resolved Hide resolved
Ipstenu added 2 commits May 21, 2019
* Removing prohibit
* 06 - making the examples match the rest of everything
* 11 - change 'often' to 'may'
* 12 - Black Hat is two words, fix paren spacing, restoring "readmes are 
for peoples" - boop beep, sorry robots. 
* 17 - Break apart paragraphs for readability.
@@ -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 only download the completed product from the WordPress.org directory.

This comment has been minimized.

Copy link
@elindydotcom

elindydotcom May 22, 2019

Does this mean that authors can't even offer the plugin as a direct download from a location their own website and has to ALWAYS link back to wordpress.org?

This comment has been minimized.

Copy link
@Ipstenu

Ipstenu May 22, 2019

Author Collaborator

No. It means that you can't use the plugin hosted here to install from anywhere outside of WordPress.org. Though I would seriously question the developer who wants to go through the drama and work of uploading the zip in two places when WordPress.org handles the updates etc for them.


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.

This comment has been minimized.

Copy link
@elindydotcom

elindydotcom May 22, 2019

Does this mean they can't offer a newer version as a download from their own site? For example, authors might want to do a slow release via their own site before opening the floodgates when its uploaded to wordpress.org

This comment has been minimized.

Copy link
@Ipstenu

Ipstenu May 22, 2019

Author Collaborator

As long as you're planning to keep the code updated here, that's fine. We're talking about people who put a known-bad version on .org and then the GOOD version up on their site, with no intention to update here. They just want the SEO juice.

@Ipstenu

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 3, 2019

Per https://make.wordpress.org/plugins/2019/07/03/the-proposed-new-guidelines-must-be-revised/

Basically I got some work to do, pulling a lot more changes in. I'm going to close this and I'll come back with a NEW pull request again.

Everyone, you did awesome :) Thank you so much for your help!

@Ipstenu Ipstenu closed this Jul 3, 2019

@Ipstenu Ipstenu added rejected and removed work in progress labels Jul 3, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.