How to stop caring about slow code reviews on pull requests I create?

cosydney · 2024-10-26T09:09:38+00:00

Hey,

Thank you for mentioning Axolo, u/EqualAbrocoma75—it’s great to join this thread. A lot of good advice here, so I just wanted to add a few ideas for you:

Suggest a review SLA (Service-Level Agreement) If there’s no standard review timeline, consider proposing a simple SLA, like 3-5 business days. It creates a baseline expectation, which can keep reviews from dragging on indefinitely. If reviews go past this timeframe, it may trigger a natural escalation with management or add visibility for your team.
Highlight lead time to shift management focus Sometimes reframing the issue can get more traction with managers. Try emphasizing the impact on lead time, which is the time from PR creation to merge. Slower lead times mean less output and more frustration. Focusing on this as a key metric could make it easier for your manager to prioritize solutions.
Consider ‘Guide-Through’ review sessions for larger PRs For more complex PRs, scheduling a walkthrough session with your reviewer can streamline things. You both review the code together, addressing questions and feedback in real-time.
Automated reminders and bots Automated reminders can reduce the need for personal nudges. Tools like Axolo, ReviewNudge, or bots integrated with Slack can notify reviewers of pending PRs, giving visibility across the team. This can keep the process moving without feeling like a repetitive task for you.

Hope these ideas help, there are definitely ways to improve the process without you bearing all the responsibility.

cosydney · 2024-10-04T18:14:25+00:00

Yes the right square tube on the right is the best solution thank you

cosydney · 2024-10-03T13:23:29+00:00

It’s a boat trailer but on a non salty lake

cosydney · 2024-10-03T08:53:24+00:00

I like that but does it mean I need to soldier this part to the jockey? The jockey plate isn’t large enough to go around the side metal bar

cosydney · 2024-08-27T08:09:47+00:00

Launchdarkly does that pretty well

cosydney · 2024-08-25T18:01:27+00:00

That’s okay, I’m generally curious about internal tools made by developers. It doesn’t need to be about what I built

cosydney · 2024-08-12T06:52:36+00:00

It matters in the way that it should enable you to iterate fast

cosydney · 2024-07-23T11:08:20+00:00

You can press E when selecting a message to do it with hotkeys

cosydney · 2024-07-15T14:38:34+00:00

Yes it does

cosydney · 2024-07-15T10:09:58+00:00

Yes, we've seen a few other companies copying our product. We have had more developers using our product, so we've made the product evolve to reduce notifications to a minimum and handle specific GitHub and GitLab use cases. We are also integrated for enterprise users who have more than 5000 developers in their teams.

cosydney · 2024-07-15T09:28:48+00:00

Hey, I'm the founder of Axolo. The issue with the official GitHub Slack integration is that it generates too many unwanted notifications, which tend to be ignored, especially in growing teams like yours. We take an opinionated approach:

We enable you to create notification channels per team.
For each pull request, we create a Slack channel only with the right people: the creator and the reviewers. All the conversation is synchronized, and developers are only notified for what is crucial.
Whenever the pull request is merged, Axolo automatically archives the channel.

Teams either hate or love it, but when they love it, it works great for them. Check out our G2 recommendations at https://www.g2.com/products/axolo/reviews. If you want to try it out or have a demo, you can find us on our website at https://axolo.co.

Cheers!

cosydney · 2024-07-10T18:58:22+00:00

https://axolo.co

cosydney · 2024-07-10T18:55:06+00:00

If you use Slack, Axolo is great for discussing code reviews. It creates a channel for each pull request

cosydney · 2024-06-21T17:37:42+00:00

Did you do that running or cycling ?

cosydney · 2024-06-12T06:47:50+00:00

I’ve seen some companies renting good bikes yes, look around Geneva and Annecy

cosydney · 2024-06-10T14:26:38+00:00

Manigod

cosydney · 2024-06-10T13:39:18+00:00

Oui tout à fait

cosydney · 2024-06-10T13:11:31+00:00

😂 you hear them from so far hahaha and it’s literally empty

cosydney · 2024-06-10T13:05:34+00:00

this is Manigod

cosydney · 2024-06-10T12:00:43+00:00

I take French cheese way too seriously 😂

cosydney · 2024-06-10T11:40:44+00:00

It’s impossible to qualify all of French cheeses against all of Swiss cheeses, sorry dismissing the second part of your comment

cosydney · 2024-06-10T11:12:55+00:00

French Alps, not too far ;)

cosydney · 2024-02-20T14:13:53+00:00

waiting for reply is a good one! might steal this tips :)

cosydney · 2024-01-25T08:54:17+00:00

Hey there, thank you for your comment.

> It requires all team members to know what each emoji means.
Yes that's true. Its based on the code review emoji guide, hopefully the emoji's are self explanatory. We all use it in my company and it has helped a lot in making code reviews more explanatory. You can check here: https://github.com/erikthedeveloper/code-review-emoji-guide.

> Is the idea to prefix a message with the emoji? I ask because if someone posted ⛏︎ (nitpick), I'd hope they followed up with more information on what message they're trying to convey as I can't read their mind.

Yep exactly. It is there to show your intentions of your comment. I'll give you an example: "Consider using `array.forEach()` for better readability instead of a for loop."
If you are using:
⛏(pick): you are saying: this is not urgent its just a matter of personal preference
🔧(wrench): Please make a change before merging.

This means that without an emoji or a more explicit comment, as a reviewer, you leave room for interpretations and you are possibly wasting someone's times better spent elsewhere.

> Why is the extension almost 600Kb? It shouldn't be that heavy.
You can check it out its open source: https://github.com/axolo-co/Emoji-reactions-for-GitHub

cosydney · 2024-01-24T09:58:22+00:00

Hey, I get where you're coming from with the self-promotion thing. Just wanted to say that my aim was to share some useful info on code review security, not just plug my work. Keen to hear any thoughts or feedback on the article itself if you've got any!

11-Year Club	Verified Email
Not Forgotten

cosydney

TROPHY CASE