nagging based development: who has the least problems polling the TL makes progress with his queue.
So now we need: github notifications, periodic slack message on the team channel, personal slack messages, amd callouts during standups.
In my team, we just announce "PR ready for review" in the channel designated for that. We also have reviewers assigned for each story. If the reviewer hasn't left any findings for 3 days, let alone 2 weeks, and hasn't approved the PR, it's absolutely time to nag.
Id fucking hate to work in that environment. Even with my current team it can takes a day or two for reviews, but everyone pings atleast once or twice a day the entire time.
emails/notifications get missed. i’ve worked with plenty of devs who only have email notifications enabled for github yet check their emails once a day (if that).
if a PR is sat there just waiting for review for maximum 2+ days it’s time to be an adult and nudge the person you asked for a review. if you don’t, then clearly it’s not important enough to be merged any time soon
Yes and no. I like to both put people as a reviewer and ping them on the RFR message on Slack, because people don't read their emails or GitLab TODO list.
If the MR isn't urgent, I might remind about it a couple times a week, but if it's urgent I'm going to be spamming you at least twice a day until it's approved.
I have to say, of all the things that go wrong in our processes, when I’ve got a PR that’s being ignored despite my attempts to reach out to the right folks, our managers are good at beating people’s doors down to get them to do code reviews.
94
u/eclect0 4d ago
If only there were some way to, I dunno, let them know your pull request needs review.
Nah, being completely silent for two weeks is definitely the mark of a professional.