[wp-trac] [WordPress Trac] #61175: Integrate PHPStan into the core development workflow

[WordPress Trac]

#61175: Integrate PHPStan into the core development workflow
--------------------------------------+-------------------------
 Reporter:  westonruter               |       Owner:  justlevine
     Type:  enhancement               |      Status:  assigned
 Priority:  normal                    |   Milestone:  6.9
Component:  General                   |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------

Comment (by dmsnell):

 > It's a shame that GitHub doesn't provide a good developer experience for
 checks that are passing with warnings.

 Agree with you on this, @johnbillion, and that’s part of why I think the
 burden should fall on us before we proactively reject work. I’ve seen some
 very good integrations that rely on interaction via comments, both on the
 PR front-roll and via line-level comments.

 > we'd still need a way for a committer to ensure nothing gets missed when
 they come to commit the change

 I wonder how far we could go simply listing these issues. Supposedly we
 are all already reviewing code, and if there are errors noted on the PR
 then it would fall within the review obligations to make sure they aren’t
 overlooked. This feels no different than if you came to one of my PRs and
 pointed out a subtle type-casting bug in my use of `in_array()`. Maybe I
 respond with some explanation of why it looks wrong but isn’t, or maybe I
 say thanks for catching my mistake before I push it to the world.

 Having that interaction to me is part of embracing the humanity of code
 review. If there’s no way to discuss it then it’s just a gate-keeper.
 Maybe people prefer this, and I won’t stand in their way; just wanted to
 share since the technologies and automations we build have real impacts on
 the people who have no choice but to appease them or find workarounds.

 I’m still a bit worried that if we provide only an approve/reject mode
 without discussion, then people will try to find awkward workarounds
 before the underlying issues can be identified, and then it becomes that
 much harder to find and deal with them later.

 ----

 Has anyone collected data on which changes //would// have been rejected
 had we been employing this for the past year or so? It’d be informative to
 know the breakdown of //caught errors that were missed in review// against
 //rejected valid work//.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61175#comment:39>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform