I totally agree with you but I see some advantages to use Pull Requests:
I share my knowledge with all the team (not only my coworker who accepts to do a "live" code review)
I share the responsibility with all the team. If someone see in my code a reason to not make it live (put it on master) because of his own code, he can provide missing informations before the merge.
I ask for the knowledge of all the team. Everyone has his own skills and often it's not the same as the skills of his coworkers. I want to enjoy diversity.
I keep a reference on the review work and could read it again later even after margin the branch.
I can define hook and CI pipeline based on the pull request (to simplify reviewer job, sanitize the code and many other boring tasks)
I don't tell we shouldn't do IRL code review, peer and mob but do pull request review in addition of the other forms of code review.
Sharing knowledge is important indeed. Instead of github-prs I'd put it one a wiki, or post it on our internal (slack) forum, depending on what kind of knowledge it is. In my experience, comments in prs get lost at some point.
Verbal, direct communication shouldn't be avoided for the sake of keeping a track-record. Writing something down can help structure your thoughts and is of course a bit more permanent.
I can't imagine developing software without a CI pipeline. I am glad that's common-place now. Our CI includes compiling, unit-tests, integration-tests, build&deploy and complete end-to-end-tests.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I totally agree with you but I see some advantages to use Pull Requests:
master) because of his own code, he can provide missing informations before the merge.I don't tell we shouldn't do IRL code review, peer and mob but do pull request review in addition of the other forms of code review.