While forcing merge requests might be annoying for you - I would question why?
The act of raising a review isn't problematic at all, and the act of logging in, reading and pressing a green button isn't problematic either. So what annoys you about it?
Speed (colleagues not being available) is fine, sometimes we should slow down.
If you experience merge conflicts, that tells me that you didn't pull the latest main into your branch before raising the PR. That's a quality concern all of it's own, you're not contributing to the HEAD of main.
Having fruitless discussions is a culture issue - our choice is that PRs exist (but are optional in some cases), and they should be merged if the code is functional. If there's a debate to be had, open a new tech debt ticket and we can talk about it in there.
If you think that tests will catch all bugs, and therefore tests should replace reviews - oh man, I have a bridge to sell you...
Ugency, is one point where we agree - a critical hotfix, Production on fire - should not go via a PR. There are other ways to review those.
I don't see how a PR breaks flow - as a developer, you raise the PR and move on to your next task. I bunch up PRs for reviews and do them while I'm drinking coffee in a morning (again, we should take the time to slow down, IMO).
My version history looks rather simple, with our optional PRs. Most work goes via PR, some does not. I guess the secret there, is in the commit messages.
I guess I just experienced the pain of our recent enterprise-wide policy of creating branches for each tiny bug/feature associated with MRs/reviews. It simply adds beraucratic burden and leads to all the outlined problems. The conflicts are also not there initially, they occur due to delayed reviews. Aslo, sometimes, you must wait until something is merged before you can "build upon it". It just slows down everything and feels unnecessary most of the time. Like I said, for complex stuff or unfamiliar stuff, MRs and reviews definitely make sense and should be done. On the other hand, blindly enforcing for each tiny detail is IMHO just an unnecessary burden. Due to all the merging happening accross the board, the version history is also a lot less linear, and if someone merged it wrongly, more difficult to fix.
I manage a small team, and we look after almost 60 different components.
All of your problems can be solved, if there's a wider desire in the company to change those situations.
For what it's worth - I probably agree with you - we do a hybrid approach of "whatever makes the most sense for the situation we're in" - sometimes that's a PR, sometimes it's a hotfix, sometimes I'll just hop directly into the Production system to tweak something.
I suggest you speak with your development management, and with your PMO, along the lines of "hey, this recent policy feels like it will hurt delivery timelines, has X, Y and Z been considered already?"
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.
While forcing merge requests might be annoying for you - I would question why?
The act of raising a review isn't problematic at all, and the act of logging in, reading and pressing a green button isn't problematic either. So what annoys you about it?
Speed (colleagues not being available) is fine, sometimes we should slow down.
If you experience merge conflicts, that tells me that you didn't pull the latest main into your branch before raising the PR. That's a quality concern all of it's own, you're not contributing to the HEAD of main.
Having fruitless discussions is a culture issue - our choice is that PRs exist (but are optional in some cases), and they should be merged if the code is functional. If there's a debate to be had, open a new tech debt ticket and we can talk about it in there.
If you think that tests will catch all bugs, and therefore tests should replace reviews - oh man, I have a bridge to sell you...
Ugency, is one point where we agree - a critical hotfix, Production on fire - should not go via a PR. There are other ways to review those.
I don't see how a PR breaks flow - as a developer, you raise the PR and move on to your next task. I bunch up PRs for reviews and do them while I'm drinking coffee in a morning (again, we should take the time to slow down, IMO).
My version history looks rather simple, with our optional PRs. Most work goes via PR, some does not. I guess the secret there, is in the commit messages.
I guess I just experienced the pain of our recent enterprise-wide policy of creating branches for each tiny bug/feature associated with MRs/reviews. It simply adds beraucratic burden and leads to all the outlined problems. The conflicts are also not there initially, they occur due to delayed reviews. Aslo, sometimes, you must wait until something is merged before you can "build upon it". It just slows down everything and feels unnecessary most of the time. Like I said, for complex stuff or unfamiliar stuff, MRs and reviews definitely make sense and should be done. On the other hand, blindly enforcing for each tiny detail is IMHO just an unnecessary burden. Due to all the merging happening accross the board, the version history is also a lot less linear, and if someone merged it wrongly, more difficult to fix.
I manage a small team, and we look after almost 60 different components.
All of your problems can be solved, if there's a wider desire in the company to change those situations.
For what it's worth - I probably agree with you - we do a hybrid approach of "whatever makes the most sense for the situation we're in" - sometimes that's a PR, sometimes it's a hotfix, sometimes I'll just hop directly into the Production system to tweak something.
I suggest you speak with your development management, and with your PMO, along the lines of "hey, this recent policy feels like it will hurt delivery timelines, has X, Y and Z been considered already?"