[wp-meta] [Making WordPress.org] #4309: Displaying PHP Compatibility results from Tide on wp.org

[Making WordPress.org]

#4309: Displaying PHP Compatibility results from Tide on wp.org
------------------------------+------------------------
 Reporter:  JoshuaWold        |       Owner:  (none)
     Type:  enhancement       |      Status:  reviewing
 Priority:  normal            |   Milestone:
Component:  Plugin Directory  |  Resolution:
 Keywords:                    |
------------------------------+------------------------

Comment (by dd32):

 Replying to [comment:22 JeffPaul]:
 > I'm curious if you, or the folks you spoke with at WCUS, see a benefit
 to providing this information privately to the plugin authors so they can
 work to update/resolve issues on their end and thus improve the accuracy
 of self-reported data?

 Speaking personally - I've always held the opinion that clear steps
 authors can take to run tests on their own is a benefit to the greater
 community, unfortunately getting most of those things up and running is
 way too complicated for most users (WPCS is impossible to use for some for
 example), which is one thing that may have ultimately lead to Tide being a
 thing.
 This doesn't invalidate the need or intentions of Tide, only that Plugin
 and Theme authors shouldn't have to rely upon WordPress.org or a service
 to be able to get that data.

 > Also curious if you think this approach should be totally abandoned in
 favor of helping the Plugin and/or Theme Review teams automate some of
 their review processes with Tide?

 Yes, I think both of those teams need more automation, but I personally
 question if Tides current model can easily apply to that though.
 The Plugins and Theme teams currently most need instantaneous checks,
 things that can run in a few seconds and validate no major issues,
 potentially then followed up with a more detailed set of checks being run.
 Both already have tools setup for this, but both need iteration and far
 more checks being added but lack of resources in doing that.
 The Tide Output *may* fill some of the secondary-check requirements, but I
 have no idea, I've never compared what those teams look for (And in the
 case of the Plugins team, some checks are private due to the nature of
 malicious actors) to what Tide outputs (I've only ever seen a tide report
 second-hand, and that was a long time ago)

 > Essentially, I'm reading your comment as a major roadblock in continuing
 with our current approach/plan for Tide and wanting to see what you'd
 recommend we pivot and focus on instead.

 I don't want to act as a roadblock here, but acknowledge that I am given
 the above.
 I'd love if the current and original plans for Tide could be completed,
 but I think automated scanning with coderule sets is only going to go so
 far, it can't be reliable for many hard yes or no situations, only be
 pushed into more general "code quality scores". It's a question of "Does
 this provide certainty? Or does it provide recommendations and potential
 red flags someone needs to review manually?"

 If you look at the way the Theme Check rules have worked, they've outlawed
 certain things in a blanket rule that has lead to authors misusing other
 things - for example `file_get_contents()` in favour of `WP_HTTP` and
 `WP_Filesystem` has resulted in many legitimate uses of the function to be
 done in hoop-jumping ways where it should've only ever been done as a "RED
 Flag! Is this being used to request a URL? Bad! WP_HTTP!  Are you trying
 to Write to theme files? Uh.. probably shouldn't be doing that.. but
 WP_Filesystem exists for interactive requests and you probably want to use
 that" (This is just an example).

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