Welcome to the official blog for the PluginPluginA 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 Review Team.
The review team acts as gate-keepers and fresh eyes on newly submitted plugins, as well as reviewing any reported security or guideline violations.
We can be reached by email at pluginsļ¼ wordpress.orgWordPress.orgThe 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/, or via the #pluginreview channel on Slack.
We are currently adding new team members as invite only. Please stay tuned!
All members of the pluginPluginA 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 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 is that team members is trust and the ability to balance security and open information.
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. Those guidelines must be enforced as consistently and fairly as possible, so it is required that a reviewer know them in and out.
More than almost any other team, save perhaps WordCamps, 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.
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 and spoken harshly to each other, but at the end of the day, we are fully respectful of everyone, and will happily have a beer and laugh.
Communicating with people who are coding but may not speak English is 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 blunt and 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.
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 chaff 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 job. 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.