Title: Expectations Author: Ipstenu (Mika Epstein) Published: November 1, 2016 Last modified: January 24, 2024 --- # Expectations ## In this article * [Introduction](https://make.wordpress.org/plugins/handbook/expectations/?output_format=md#introduction) * [Education](https://make.wordpress.org/plugins/handbook/expectations/?output_format=md#education) * [Privileged Information](https://make.wordpress.org/plugins/handbook/expectations/?output_format=md#privileged-information) * [Respect](https://make.wordpress.org/plugins/handbook/expectations/?output_format=md#respect) * [Communication](https://make.wordpress.org/plugins/handbook/expectations/?output_format=md#communication) * [On Saying No](https://make.wordpress.org/plugins/handbook/expectations/?output_format=md#on-saying-no) [↑ Back to top](https://make.wordpress.org/plugins/handbook/expectations/?output_format=md#wp--skip-link--target) ## 󠀁[Introduction](https://make.wordpress.org/plugins/handbook/expectations/?output_format=md#introduction)󠁿 All members of 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/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party. team are held to an exceptionally high standard, not just in their ability to process code for security, but also in the way they handle security issues, ethical/behavioral situations, and privileged information. While everyone makes mistakes, the strength of the plugin team comes from not just our appearance of fairness and honesty, but the actuality of those things. We must be consistent. The biggest challenge we will face as team members is trust and the ability to balance security and open information. ## 󠀁[Education](https://make.wordpress.org/plugins/handbook/expectations/?output_format=md#education)󠁿 No one on the review team is expected to be an expert in all things. Everyone is expected to be familiar with the [Detailed Plugin Guidelines](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/). Those guidelines must be enforced as consistently and fairly as possible, so it is required that a reviewer know them inside and out. ## 󠀁[Privileged Information](https://make.wordpress.org/plugins/handbook/expectations/?output_format=md#privileged-information)󠁿 More than almost any other team, except perhaps 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](https://central.wordcamp.org/about/)., we deal with a high volume of privacy concerns. In order to evaluate people’s plugins, we need to know more than just what they submitted, we need to know who they are. It may surprise you to know a number of developers intentionally hide who they are. In addition, we work with people that threaten legal action, or those who need to be made aware of possible ones regarding their own work. This means that anyone who is on the team must be able to keep things secret. It’s not just that we can’t share out email addresses and IPs, but we also have to keep“ in house” discussions of people and situations. We cannot tell anyone other than the plugin owner(s) why a plugin was closed. We do not publicize privileged information. Just as an example, the exchange of the Google Analytics plugin by Yoast to Monster SEO was something we were aware of weeks before it happened. Under no circumstances would that be mentioned outside the group. ## 󠀁[Respect](https://make.wordpress.org/plugins/handbook/expectations/?output_format=md#respect)󠁿 This is true of all teams, of course. Emotions for plugins tend to run rather high. Being respectful of people, even when you’re telling them ‘no’ to a coding or security error, or enforcing a behavioral issue, is a must. We are always cognizant of the human behind the code. Thankfully we’re also a team, and recognizing the reality that there are some people we, as individuals, cannot work with or communicate clearly with, is highly important. We can, and do, hand off situations to others, however sometimes there will be a point where you must deal with someone who makes you irate. You have to remain respectful no matter what. Inside the team, we have to be able to challenge each other when we discuss our guidelines. We don’t all agree with decisions we’ve made, but we know we all come from a place of deep caring for the community and the quality of the directory. We’ve all argued with each other, but at the end of the day, we are fully respectful of everyone, and will happily have a beverage and laugh. ## 󠀁[Communication](https://make.wordpress.org/plugins/handbook/expectations/?output_format=md#communication)󠁿 Communicating with people who write code but may not speak English can be quite complicated. We don’t offer training in how to code, but at the same time we try to guide people to information and allow them to self-educate. While we often make use of pre-defined replies, we have to customize them and tailor them to the people having issues. In-team, we can be rather direct when talking about plugins and developers. This is, again, what we consider privileged information. As a closed group, we have the opportunity to talk plainly about people who have all their plugins removed because we must have the freedom to say these things. While it’s no secret some people have been kicked out of the repository for behavior – such as name-calling, constant SEO abuse, or flagrant disrespect – we do not publicize the reasons. ## 󠀁[On Saying No](https://make.wordpress.org/plugins/handbook/expectations/?output_format=md#on-saying-no)󠁿 The hardest thing for people to accept is that no means no. When a plugin is told“ you may not include your own copy of jquery” we get roughly the same amount of grief as we do when we tell someone they’ve been banned. Surprising? Maybe. But being firm and telling people “no” – and not bending – is part of the role. There will always be exceptions (like the “Use Google’s jQuery” plugin which has the sole purpose of using Google’s jQuery), but that one makes logical sense. This extends to handling situations where you make an unfavorable decision, like banning someone or deleting reviews. There’s absolutely no way to do this without hurting someone’s feelings. First published November 1, 2016 Last updated January 24, 2024 Edit article [ Improve it on GitHub: [article_title] ](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fplugins%2Fhandbook%2Fexpectations%2F&locale=en_US) Changelog [ See list of changes: [article_title] ](https://make.wordpress.org/plugins/handbook/expectations/?output_format=md#) [ Previous: The Team](https://make.wordpress.org/plugins/handbook/the-team/) [ Next: Get Involved](https://make.wordpress.org/plugins/handbook/get-involved/)