X-post: Postponed to WP 6.2: Escaping Table and Field names with wpdb::prepare()

X-comment from +make.wordpress.org/core: Comment on Postponed to WP 6.2: Escaping Table and Field names with wpdb::prepare()

Reminder about Final Notices

tl;dr? If you get a final notice from the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party team, please take it seriously. That really is you reaching your final chance with us.

There has been some confusion about what a ‘final notice’ means with regards to plugins or what it means to be banned.

The Plugin Team does not capriciously ban anyone. Actually we hate banning people. It’s a lot of work, it’s frustrating, it comes with anger no matter how we do it, and people always get hurt, especially users. That’s why we’ve established a warning system and do our best to ensure all developers are aware of infractions and allowed to course-correct.

What is a final warning?

A final warning, like it sounds, is an email with a rather stern content telling you that you’re on your very last chance.

The plugin directory emails out final warnings to developers/companies/groups who have either demonstrated a repeatable, constant, habit of violating guidelines, or who have committed an incredibly egregious violation. Those emails contain a reminder (usually in the form of a list of all existing problems) and a notice that if the plugins team has to contact them for any reason other than security related, the developer/company will be banned and all plugins closed.

If you keep making the same mistakes, and you keep violating forum, plugin, theme, WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more., or any other official guideline of WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, we will cease to host your plugins here anymore. You would have repeatedly proven that you aren’t able (or willing) to follow the guidelines, and we feel it’s unfair to put the burden of monitoring you on the volunteers, as well as subject your users to that kind of behavior.

What happens after a final warning?

In general, people are quite responsive to those emails. They recognize the issue, modify their behavior, and it doesn’t come up ever again.

The warnings are a wake-up call as to the risks involved, as well as our expectations, and while they can scare people, it’s somewhat of a needed scare. By the time someone gets to that point, we have usually sent multiple warnings about various issues (be they fake reviews, asking for admin access, spamming users, or sharing developer accounts) prior to the final-notice, in the hopes that people will change their behavior before we have to get to the final notice.

Sadly, there are always people who don’t take those emails seriously, or think that if enough time has passed, the finality has faded and it’s okay to make the same mistakes and we will forget about it and forgive everything.

Why do people get banned after a final warning?

Given the size and scale of WordPress, it’s impractical to have to keep reminding people over and over that they actually do have to comply with the guidelines they agreed to, and it takes away time from frankly more important matters, like security.

Do people get warned first?

Most of the time, yes. The rare exception is if something is so terrible, we have to pull the plug right away. Usually that means someone snuck back in after being banned, or made a death threat.

But the majority of users get an email with the subject [WordPress.org Plugin Directory] Notice: (your plugin name) and that contains a warning of a specific behavior.

I got a warning about something. Is that a final warning?

Unless the email said “This is your final warning” then no.

We regularly warn people about issues, from trademark abuse to fake reviews. Those are just warnings. As long as they don’t repeat, we don’t have any issues. People make mistakes and it’s okay, as long as you learn from them and stop making them.

I’ve been mod-watched in the forums. Is that a warning?

No, not a plugin one. That just means the forum moderation are concerned about your actions and want to keep tabs on you. That could be anything from asking to admin access to swearing or jumping on other people’s topics all the times.

That said, if the forum team flags you like that, and you keep making the same mistakes, they may come to the plugin team for backup.

What kind of events cause a final warning?

Usually it’s not a single event, but a demonstrable pattern of violations. By that we mean the person(s) involved have broken many guidelines, over and over, for a sustained period of time.

Just for an example, let’s think about asking someone for admin access. That is prohibited in the forum guidelines for safety. Asking once is a mistake, and we know mistakes happens, so the person will get a warning from the forum mods. If they happen to ignore (or miss) the warning and do it again, their account gets put into a ‘moderated’ status, and all posts have to be approved by a moderator. That moderation flag is not a punishment. It’s there to make sure the mistakes stop, and to help protect the developer from harming themselves. After that, though, if it keeps happening, the plugin team is asked to step in and issue a warning.

But even so, our first warning is not a final notice! It’s a first warning.

From them on, if the person keeps violating the guideline, that is when that they will get that dreaded ‘final warning’ from plugins.

Why did I get a final warning without previous notifications?

That means you did something really bad, but not quite ban-worthy yet.

Sometimes it happens when someone gets a warning (like ‘don’t ask for admin access’) and replies “I cannot be held responsible for what my staff does.” That gets a final warning right away and a reminder that you absolutely will be held responsible for the people who represent you and your product. If you cannot trust your people, don’t let them represent you.

Other times, it’s a mistake so large, and so fraught with danger or concern, we feel that the only proper recourse is to jump directly to the final notice. Those are incredibly rare, and I’ll explain a little more about that later in this post.

How do I avoid a final warning?

Besides ‘never violate the guidelines,’ the easiest way would be to acknowledge and rectify any issue that a moderator or plugin rep brings up. If someone tells you not to ask for admin access? Stop asking for admin access. If they tell you not to call users vulgar names? Stop calling people names.

Basically listen to the warnings, take them all seriously, learn from them, and change your behavior as needed.

We know that everyone makes mistakes, and we will forgive a lot. But at the same time, that kind of forgiveness requires you to make changes. If you apologize and just do it again, we’re not going to be able to trust you, and that’s how you end up with a final warning.

I keep getting warnings because of my support staff, what do I do?

If that happens, it means you’ve somehow failed to impart on your support staff the reality that they have to follow the guidelines too. They are your responsibility, and if you cannot ensure they follow the guidelines, we simply won’t allow them to use the forums at all anymore, and you will be told why.

As for how to fix it? You need to address the issue on your end. Why are you staff not aware they have to follow the guidelines? Why are they not listening to the warnings issued? Why are they continuing to have this kind of problem?

Make sure everyone who represents you (in the forums, on social media, wherever) knows that their actions reflect on your whole company, and they have to follow the guidelines too. After all, if your intern violates Twitter’s guidelines using the company account, it’s your company account that gets suspended.

Other people are making the same mistake I am! Why aren’t they getting banned/warned?

They probably are, actually.

We respect everyone’s privacy and we don’t blast anyone on socials, so all conversations are in confidence as much as can be. After all, if you make mistakes and change your ways, you wouldn’t want the whole world knowing how much you messed up, right? It would be terrible embarrassing! Instead, we treat you like an adult, take you to the side, and talk to you privately.

Most people actually listen to the first warnings. If a forum mod tells them to please stop doing a thing, they apologize and stop. The plugins team never gets involved, and honestly that’s the best way.

I made similar mistakes. Why did I never get warned?

Luck? Or maybe we saw you made it once, and never again.

Mistakes happen. Most mistakes, as long as they aren’t repeated, are recoverable. Don’t panic if you made one mistake. As long as you keep learning, adjust as needed, and don’t do it again, you’re going to be fine.

Why did I get a second final notice?

Most of the time, that means we changed the guidelines since the first one, and felt it would be inhumane to not warn you about them. We will do this even if your violations are unrelated to the changes to the guidelines.

The other time would be if we think you really did change enough since the last notice, but you’re running down another wrong path. Basically? We think you are capable of change based on your historical behavior, and we want to give you another chance.

Why did I get banned without a final warning?

Normally we warn but yes, in some specific cases, we won’t. They include, but are not limited to:

  • physical altercatoions at official WordPress events
  • banned users attempting to circumvent their ban
  • intentional security violations (ex. making a backdoor in your plugin on purpose)
  • cyberstalking/harassing anyone from wordpress.org
  • doxxing anyone
  • all plugins/themes are non-credited forks or wholesale copies
  • outright vulgarity/hostility/threats towards any member of the community

In those cases, we will always email and tell you exactly why you were banned.

The people who get those insta-bans are often ones who got a plugin review and replied with vulgarities or suggestions of sexual activities involving a cactus. Not a joke. It was in response to being told to not include their own jQuery, to boot. We do get that people have bad days, and we try to help them get back from it, but that kind of abuse is untenable. If you’re willing to talk to us like that, we shudder to think how you’d behave to users!

What can I do after I got banned after a final warning?

Honestly? Not a whole lot. It’s incredibly hard to make anyone trust you after you reached that point.

If you got the final warning and kept violating guidelines, then you just squandered your last chance. The whole reason you got that warning, and not an instant ban, was that we were trying really hard to get you to correct your behavior. When you don’t listen to those warnings, we believe you are who you act like, and we ban you.

Now of course there are always exceptions. They are incredibly rare, and come with a lot of provisions and caveats. If you really think you should be given a second final-chance, reply to the email and explain why. Just be aware that the odds are against you, since you have already demonstrated you cannot (or will not) follow guidelines.

Why don’t you publicly declare why someone was banned?

Historically because we don’t want to keep hurting them.

Angry people lash out see, and while we’re ‘fine’ with taking it on the chin when people lash at us because we don’t explain the details about a ban (except in very rare cases), if we made things public that mob would go after the banned dev.

See, if everyone knew that a person or even a company was banned after we argued with them every few months for three years about not asking people for admin access on the forums, or not tracking users in their plugins, they would have a very different view of the developers.

If everyone knew a company was banned for telling the plugin team they could perform sexual acts on their parents (wish I was joking), then what? Making that public in a place where they cannot refute means they have no ability to make amends. And yes, sometimes people do come back and apologize sincerely for that behavior.

We don’t disclose because of a kindness, and a desire not to destroy someone’s reputation (or livelihood). Perhaps we’re now at the point where that policy needs to change, in order to minimize the false narratives running around, but I’m really divided about that one, personally.

Someone says they were banned. Should I stop using their plugins?

I can’t answer that for you.

Personally, I would take their explanations with a grain of salt. Everyone (and this includes the Plugin Team) tends to tell a story to paint themselves in a better light. If someone is arguing they did no wrong and were banned, they’re probably leaving some information out. Then again, there are developers who tell people they messed up and got banned and deserved it.

Questions?

I know this is a lot to think about, and some of it sounds incredibly petty.

No one on the plugin team wants to close plugins, especially the well-known ones. It’s harmful to the community as well as the developers. At the same time, there is a practical limit as to how much the volunteers on WordPress.org are willing to put up with someone’s misbehavior. That’s why we have taken to formally warning people that they are on their last chance.

It’s our fervent hope that with the information in the final warning, people will correct their behavior and stop violating guidelines.

#final-notice, #reminder

Reminder: We will check your website

tl;dr: If you put a website as the official developer or pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org and it does not exist (or is under construction), your review will be pended.

We know that sounds really weird, but yes, we’re saying if you tell us that your domain is XYZ and that domain doesn’t exist, or isn’t public, your review is going to be paused until you finish the site.

The primary reason for that is because those URLs will be seen by all your users, and if a user sees a great looking plugin with an incomplete website, they will not trust you. That’s actually something that scammers do on the regular, and you’ve made yourself look like that.

So to protect you from an undeserved bad-rep, we check your domains.

The secondary reason is, if you’re a service, we really do need that live so we can review the website and ensure it and the plugin are compatible with our guidelines.

Can I just remove the URL from the code?

Most of the time, yes.

However if you’re a service and the service runs through that website, then not only will you be required to make the site public, but you will also need to include a terms of use and/or privacy page on your site.

I made a typo! What do I do?

Reply to the email with “Ooops, I typoed, the real URL is …” We’ll ask you to update the code and your account, so your users don’t get confused, and all will be well.

What if the site isn’t mine, it’s the service owner’s?

Then you used the wrong account to submit the plugin. Remember ALL official plugins have to be owned by the official company. If you were hired to make a plugin for BoogieDownBlues (a fake company) and the domain is boogiedownblues.com then the account that submits the plugin has to use that domain for their email.

That protects you and them from any legal action later on.

My site is nearly done, can I have a pass?

No. Again, we’re trying to protect you from being seen as an untrustworthy developer. Also we want to make sure your site isn’t violating rules.

What if I need to have the plugin before I can have the site?

This generally happens with service plugins, and if that’s the case, we will tell you no. The site has to exist so we can validate the service.

Do I need an about page and all that?

You do not, but we do recommend it. People prefer to know there are real humans behind things.

Can I make a simple, placeholder?

Maybe. It depends on what you put on the placeholder page and (again) if you’re a service. If the placeholder says ‘Coming soon!’ then no.

What about Lorem Ipsum pages?

If your domain is filled with placeholder, we consider it to be incomplete and will point out the problem. Same goes for clearly fake addresses and those about pages that all have the same face.

Why does it matter if my personal site exists?

Because you told us (and by extension all your users) “this is who I am!” If your personal site is ‘coming soon’ or has a placeholder, no one can make a judgement on you save to say you’re a dev who can’t make a website. And yes, that is patently unfair, we know, but that’s what people will think. Heck, they complain to us every time we miss it. We would rather you not start in a bad place.

Why was I told not to use trademarks in my URL?

Because using a trademark in the domain name violates trademark law.

Using a company’s trademark in a URL as a domain name in whole (or in part like wordpress-example.com) may constitute a violation of the company’s trademark rights.  See Brookfield Communications, Inc. v. West Coast Entertainment Corp., 174 F.3d 1036 (9th Cir. 1999). 

What you can do instead is have example.com/trademark/ — that is generally allowed.

Keep in mind, some organizations (like WordPress) will allow the ‘short’ versions so wpexample.com would be fine. Others (like WooCommerce) have more restrictions, and actually prohibit wooexample.com

Always check the trademark guidelines first!

#reminder

X-post: WordCamp US Contributor Day 2022 Recap

X-comment from +make.wordpress.org/updates: Comment on WordCamp US Contributor Day 2022 Recap

Heroku Free Tier Being Retired

tl;dr: Heroku’s free plan is going away. Please update your services and make sure all your 3rd party libraries are up to date.

From their recent post:

Starting October 26, 2022, we will begin deleting inactive accounts and associated storage for accounts that have been inactive for over a year. Starting November 28, 2022, we plan to stop offering free product plans and plan to start shutting down free dynos and data services. We will be sending out a series of email communications to affected users.

Roughly 300 plugins use heroku services, many for free. If you are one of those free users, please make sure you make arrangements to either pay for the plan or replace your service. As of December 2022, if people report your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party breaks because of that shut-down, we will close your plugin until it’s corrected.

There’s always the probability you’re not going to want to (or be able to) migrate services. That’s okay too. If you want to close your plugin, you can do that yourself! I would recommend pushing a final version that warns people on day X this will stop working, if that’s your choice.

The one thing that’s really going to trip people up are those libraries though. A lot of 3rd party libraries make use of Heroku, and not all are going to update.

We’re going to do a sweep and let as many people know as we can, but we wanted this to be public since a lot of people miss emails and also if your plugin isn’t impacted but one you coordinate with is, well… you should know too 🙂

#heroku

Top reasons not to use setlocale() for character encoding conversion

Many WordPress plugins use the setlocale() function.

While it’s generally safe to use setlocale() to get various information about a specific locale, it’s essential to understand that using setlocale() to perform string manipulations has significant disadvantages.

The goal of this article is to raise awareness about those disadvantages.

Disadvantages

So, what are they?

  1. Firstly, setlocale() is not thread-safe. If you run WordPress on shared hosting, you may experience sudden changes in locale settings, as though your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party never called setlocale().
  2. String functions that rely on setlocale() to detect the current locale don’t process some characters correctly, even if the correct locale is set with setlocale().

Take a look at this 3vl4.org example.

The expected output of the script is Ž, but the actual output is Ů.

Recommendations

These are some recommendations on using setlocale() that could make using it safer:

  1. Don’t use setlocale() to process strings in different encodings unless absolutely unavoidable.
  2. Don’t use setlocale() with LC_ALL. Instead, specify the exact categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. of functions you need (e.g., LC_MONETARY, LC_NUMERIC).
  3. If you need to change the current locale, you must change it back to the previous value in order to preserve thread-sanity. At this time, C should be used as the default locale setting.

#best-practices, #security

X-post: Contributor Teams: Submit WCUS 2022 Table Leads Signup Form by July 29

X-comment from +make.wordpress.org/community: Comment on Contributor Teams: Submit WCUS 2022 Table Leads Signup Form by July 29

Proposal for a WordPress plugin checker

For a long time, WordPress has had the theme check plugin, a tool which statically analyzes a given WordPress theme to determine if it follows certain theme development requirements and best practices.

This post proposes defining and implementing a similar tool for WordPress plugins that analyzes a given WordPress pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and flags any violations of plugin development requirements and best practices with errors or warnings. It should cover various aspects of plugin development, from basic requirements like correct usage of internationalization functions to accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), performance, and security best practices.

This post is based on an earlier proposal document that has been reviewed and discussed by the performance working group over the last several weeks (see original Slack message sharing the proposal).

Goal and use cases

The goal of the plugin checker would be largely equivalent to that of the existing theme checker, fulfilling similar purposes for plugins. Specifically, the primary goals would be to:

  • Provide plugin developers with feedback on requirements and best practices during development.
  • Provide the wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ plugin review team with an additional automated tool to identify certain problems or weaknesses in a plugin ahead of a manual review.
  • Provide technical site owners with a tool to assess plugins based on those requirements and best practices.

The plugin checker should be implemented as a plugin itself, allowing it to be used by similar environments to the theme checker. However, the scope of the plugin checker should preferably be slightly expanded so that it can better adapt to different environments to satisfy the following use cases:

  • It should support checking a plugin both from a WP Admin UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. and from the command line (using WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/), so that it can be conveniently run during local development or for Continuous Integration, e.g. a GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ action.
  • It should include checks that go beyond static code analysisStatic code analysis "...the analysis of computer software that is performed without actually executing programs, in contrast with dynamic analysis, which is analysis performed on programs while they are executing." - Wikipedia, such as runtime checks in which code from the plugin is actually executed, to allow for additional best practices to be covered.
  • It should allow for customization of which checks are run for a plugin, including allowing optional or experimental best practices checks to be opted in to, or excluding certain checks for more of a baseline audit.

Project breakdown

The idea is that this plugin checker plugin would be developed in a GitHub repository and eventually be published either as a plugin in the wordpress.org plugin repository, as a Composer package on Packagist, or both. An additional means of distribution could be to also publish it as a configurable GitHub action. From there, both developers and site owners would have access to it and could use it as they prefer.

Once the plugin is more established, opportunities for this new tool to be integrated into the wordpress.org plugin submission infrastructure should be explored in order to automate parts of the largely manual plugin review process and potentially catch additional problems. The customization of which checks to run is critical particularly for this purpose, as there is a good chance that the plugin repository would run a different set of checks than the default configuration, emphasizing the more foundational requirements for all plugins.

While the initial purpose of the plugin checker will be for plugin developers and site owners to use the plugin checker, all of the above use cases need to be considered during all stages of development of the tool.

Proposed approach

As outlined above, the plugin checker should be implemented as a plugin itself, primarily so that it is easy to install and usable within WP Admin UI for site owners or developers. In addition, it should provide a WP-CLI command so that plugin checks can also be conducted from the command line.

The tool’s static code analysis checks should rely on an internalized version of PHP_CodeSniffer, providing more flexibility and simplifying maintenance, as this is an established tool. There are already existing WordPress tools for automated plugin analysis, and several of them also use PHP_CodeSniffer, which would mean that the new tool could use some already established checks. In addition, usage of PHP_CodeSniffer would allow even environments that are not WordPress to run at least the static analysis checks.

While many plugin requirements can be checked through static code analysis, this method has its limitations, especially when it comes to certain accessibility and performance best practices. That is where having dynamic runtime checks available in addition to static code analysis will be critical. Dynamic runtime checks are different in that they actually run the plugin and thus can detect additional issues such as uncached or slow database queries. They can also more reliably identify problems around excessive scripts and stylesheets being enqueued.

One of the main complexities around plugins compared to themes is that plugins essentially have an almost unlimited feature set – they can do anything. This makes it impossible to predict their expected behavior. It also complicates defining a reliable set of rules and guidelines to check for. However, there are certain ways to at least to detect what a plugin does, for example when using certain WordPress APIs, such as to register post types or blocks. Such detection mechanisms would benefit from runtime checks as well; for example a plugin may not affect the homepage of the website in any way, but it could cause several issues just in posts of a certain post type. Dynamic checks allow for such problems to be identified.

In addition to static analysis and server-side runtime checks, it could also be beneficial to include client-side checks. Again, there are certain accessibility and performance best practices that could only be reliably detected through such checks. One complexity of client-side checks, though, is that they would only work in a browser environment, so it would be challenging to run them from the command line except in an environment where a headless browser is configured. This makes running such checks infeasible in certain environments. For this reason, the proposed approach for the plugin checker would be to start with a focus on static analysis checks and server-side runtime checks, but build the infrastructure in a way that client-side checks could potentially be added in the future.

For some additional context on the different types of checks, see the earlier proposal document.

Next steps

At this point, the performance team would like to gather feedback on this proposal from the wider community, especially from plugin developers, the plugin review team, and the metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. team. Please share your thoughts, questions, or concerns in the comments.

Once there is consensus on a path forward, the next step would be to design the infrastructure for the plugin checker plugin and start implementing it in a new WordPress GitHub repository. The performance team would be excited to take the lead on this project, but it is vital that additional contributors from other teams help with its development, especially when it comes to defining and implementing the different checks.

This is certainly an ambitious project, and it is not the first time that a plugin checker has come up. It also needs to be clarified that it will likely take a few months at least to get to a first version. However, we are optimistic that with a solid foundation and collaboration from the start, we can create a tool that will meet the requirements for reliable automated plugin checks.

Props to @shetheliving, @mehulkaklotar, @manuilov, and @ipstenu for review and proofreading.

#performance, #plugin-check, #proposal

X-post: Learn WordPress Development: Creating a Public Roadmap for Content Creation

X-post from +make.wordpress.org/training: Learn WordPress Development: Creating a Public Roadmap for Content Creation

X-post: Rollback Feature: Testing Call to Action

X-comment from +make.wordpress.org/core: Comment on Rollback Feature: Testing Call to Action