I agree on all the points, as experienced this myself.
1: Keep Pull Requests Small
Communicating in some cases is also a very important part. It could also be included in the description of a comment/ticket/whatever you use to communicate.
This is quite interesting how some see "small" like:
The PR has only moved a component to another one place, updated 400 files because of path updates.
Nothing more. Honestly.
OK, the description is bad, but that helps a lot to speed up the process (with trusting the developer) rather than wast time checking all 400 files. In combination with #6: The pipeline will do a check if the path is fine, so no need to look into more than needed.
Great callout! I love leaving little annotations on my own PRs to help my reviewers navigate the PR. Things like an updated file path or formatting changes are great to highlight so reviewers know which pieces are important to look at and which aren't (assuming they trust the code author!).
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 agree on all the points, as experienced this myself.
Communicating in some cases is also a very important part. It could also be included in the description of a comment/ticket/whatever you use to communicate.
This is quite interesting how some see "small" like:
OK, the description is bad, but that helps a lot to speed up the process (with trusting the developer) rather than wast time checking all 400 files. In combination with #6: The pipeline will do a check if the path is fine, so no need to look into more than needed.
Great callout! I love leaving little annotations on my own PRs to help my reviewers navigate the PR. Things like an updated file path or formatting changes are great to highlight so reviewers know which pieces are important to look at and which aren't (assuming they trust the code author!).