alt Hacker NewsThis is why I said "repeatedly" i.e. a pattern has already emerged.
And in most companies I've worked at you are the one being held responsible for a PR/feature not being merged or finished on time - at least in my experience. You're often working on a different team from the people doing reviews, so in a large enough company they are just a faceless/nameless person from the perspective of your PM.
Replies
> And in most companies I've worked at you are the one being held responsible for a PR/feature not being merged or finished on time - at least in my experience. L
You are responsible for delivering tasks, but if you are blocked by the process then it's not you who is preventing the task from being delivered. Whether it's the scrum master or sdm or project manager, someone else is responsible for keeping the tasks moving. Once you mark a task as pending review, you are blocked. From that point onward all you have to do is raise awareness of reviewers to the task pending review, and raise visibility with stakeholders that your deliverable is being blocked by the review. As long as you don't slack in raising awareness, it's not your problem anymore.
you are describing a work cultural issue - putting merges on the person that is writing, as a personal failing of people focusing on getting their own code merged, and probably having similar difficulty with that.
why are you working on teams where you are always touching somebody else's code without also making friends with them?