In my experience, I don't typically do WIP pull requests. To me, branches/in-flight work should be kept very small so that a complete/non-breaking PR is opened every day ideally. That said, breaking work down into those small chunks is not trivial, nor is "non-breaking".
I believe opening PR's for WIP could be beneficial if ad-hoc code reviews with teammates is not an option. I would prefer one on one code reviews for that type of WIP work. The reason for that is because of scale, as you mention a larger team with multiple WIP PR's is likely going to become unmanageable.
I like your point about trying to keep PRs very small. Even though breaking work down into chunks may be difficult, I feel the time spent is worthwhile. It provides a nice way to further understand the work you'll be doing vs. starting to add commits wildly to the PR as you go along.
Would you say you practice trunk based development then? We don't follow it exactly as prescribed, but it's sooo much easier to reason about code when the changes are small.
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.
In my experience, I don't typically do WIP pull requests. To me, branches/in-flight work should be kept very small so that a complete/non-breaking PR is opened every day ideally. That said, breaking work down into those small chunks is not trivial, nor is "non-breaking".
I believe opening PR's for WIP could be beneficial if ad-hoc code reviews with teammates is not an option. I would prefer one on one code reviews for that type of WIP work. The reason for that is because of scale, as you mention a larger team with multiple WIP PR's is likely going to become unmanageable.
I like your point about trying to keep PRs very small. Even though breaking work down into chunks may be difficult, I feel the time spent is worthwhile. It provides a nice way to further understand the work you'll be doing vs. starting to add commits wildly to the PR as you go along.
Would you say you practice trunk based development then? We don't follow it exactly as prescribed, but it's sooo much easier to reason about code when the changes are small.