[wp-meta] [Making WordPress.org] #3845: Linting for Plugin Submissions + Filters for Plugin Directory Searching

[Making WordPress.org]

#3845: Linting for Plugin Submissions + Filters for Plugin Directory Searching
-------------------------------------------------+-------------------------
 Reporter:  s3w47m88                             |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Improved
                                                 |  Search
Component:  Plugin Directory                     |  Resolution:
 Keywords:  2nd-opinion ui-feedback ux-feedback  |
-------------------------------------------------+-------------------------
Description changed by dd32:

Old description:

> I was asked to repost this here and told I could link to the original
> Ticket: https://core.trac.wordpress.org/ticket/45005

New description:

 I was asked to repost this here and told I could link to the original
 Ticket: https://core.trac.wordpress.org/ticket/45005

 ----

 This is apart of a bigger project for my staff and I, you can find the
 context here https://www.theportlandcompany.com/2017/09/10/proposed-
 improvements-to-the-wordpress-ui/.

 Although this particular, and final, ticket, is slightly off-topic from
 that post but was born from wanting to preserve "The WordPress Way" and
 modern UI design principles.

 Currently, when installing Plugins, you:

 1. Search for a Plugin to fill a need.
 2. Narrow it down to X Plugins you want to test.
 3. Install them all.
 4. Activate one.
 5. Deactivate, activate another and compare.
 6. Repeat until you've tested them all.
 7. Choose the one you want and move on.

 **The Problem**

 9 out of 10 times we're just checking to see if the Plugin isn't absolute
 garbage. Reviews are helpful sometimes, but how many reviews does one have
 to sift through to answer X questions? Often times reviews never even
 answer basic questions like:

 - Does this Plugin register alerts properly?
 - Can those alerts be dismissed?
 - Does this Plugin add things across the admin or does it keep itself
 contained to it's admin pages?
 - Does this Plugin properly register all of it's scripts?
 - Does this Plugin register scripts on the front end? Back end? Both?
 Neither?

 And we can imagine many other questions like these.

 But to have to install a Plugin, and in some cases use it extensively,
 just to answer these kinds of technical but essential, questions is very
 time consuming. Leaving a review for every bad Plugin out there becomes a
 part-time job and often doesn't result in an improvement to the Plugin in
 the end anyway.

 With tools like linters or unit testing, we wonder why are we manually
 testing things like this *if* it could be automated to some degree? Why
 don't these things affect the score / rank of Plugins in the directory
 when searching so well-built Plugins are ranked higher than poorly built
 ones?



 **The Conceptual Solution**

 So, we propose the following. But we realize this is a large undertaking
 that affects a lot of things. It's probably something that needs to be
 introduced incrementally and probably not exactly as we propose.


 - On each Plugin's page in the Directory would be a sidebar that lists an
 icon.
 - Hovering over the icon would display the question. Ex. "Does this Plugin
 register all of it's scripts properly?"
 - If the answer is yes, it's green. If the answer is no, it's red. If it's
 not applicable either the icon could be gray or just not appear.
 - The answers to these questions could be answered automatically when a
 Plugin is submitted to the repository. Run through a linter of some kind
 which generates a JSON file, or values in a database that the Plugin
 Directory Page users.
 - There could be two columns of these icons. One for the system to
 automatically evaluate, the other for the developer to give an answer.
 Since algorithms aren't always perfect it ensures developers have a voice
 (like the ability to reply to a bad review) and for us to improve the
 system based on those use cases.
 - Then, we introduce Filters to the Plugin Directory Search and Filter
 utility, both in the WordPress Plugins page in WordPress itself, and on
 WordPress.org. This would allow users, like us, to say "Only show me
 Plugins that meet these standards."

 Once initially implemented, like Advanced Custom Fields Plugin, this could
 be scaled quiet easily. Could also become contextual and expand way beyond
 basic Plugin standards.

 For us, we **hate** Plugins that don't register scripts correctly,
 introduce their own color scheme to things where they're not allowed to
 (ex. menu icons, settings pages). We also **hate** that every Plugin seems
 to introduce their own types of metaboxes and placement of them on their
 pages. Even if they look and work great it's not "The WordPress Way" and
 is disorienting.


 **Our Effort**

 We're happy to create some designs to show what this all would look like,
 and a flow chart to show how things connect if this is something the
 leadership want to entertain. And if it gets far enough along, certainly
 contributing code level solutions.

--

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/3845#comment:2>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org