4 ms·

I really appreciate how this reduces notifications for engineers not involved in the review.

cosydney 5y ago
Yes, one should only receive relevant notifications.
csmpltn 5y ago
> "I really appreciate how this reduces notifications for engineers not involved in the review." But it definitely increases notifications for people involved in the review. "A war room for each pull request" you'll exhaust your reviewers very quickly with this mindset. What about cases where any one random reviewer (or several) is needed from a larger group of people? Does everyone get paged in? Or cases where a single reviewer is assigned to multiple different reviews? This becomes a DDOS attack on the human attention span and has the potential to create disorientation more than anything.
- jrowley 5y ago
  I like how much you are focusing on developer focus here! I guess you need to compare this against something else for it to better. At my workplace, we were originally really small, just 3 or 4 engineers, so have a code-review specific channel where all members of the channel get notifications from github for ALL pull requests. As the size of the team increases (closer to 10 engineers now), I think the value from this channel is kind of decreasing, since there are fewer conversions happening in it. So this tool helps solve that problem.
- arthurcoudouy 5y ago
  > What about cases where any one random reviewer (or several) is needed from a larger group of people? Does everyone get paged in? If you select several reviewers and only one is needed, that'll ping the group of reviewers. That's not something we recommend, we think that one should use a random algorithm to select a specific reviewer if you prefer to select a group of people (https://docs.github.com/en/organizations/organizing-members-into-teams/managing-code-review-assignment-for-your-team#configuring-code-review-assignment https://docs.github.com/en/organizations/organizing-members-...). > Or cases where a single reviewer is assigned to multiple different reviews? This becomes a DDOS attack on the human attention span and has the potential to create disorientation more than anything. Instead of having notifications from Github, emails & Slack, we believed that it's easier to manage notifications when they come from only one place. When you're working on something, notifications should be muted. Axolo in Slack works as an "inbox zero", you should focus on your code and come see where your review is needed in a dedicated time.
- gitgud 5y ago
  > This becomes a DDOS attack on the human attention span and has the potential to create disorientation more than anything. I love this phrase, it's applicable to all user facing applications!

Yes, one should only receive relevant notifications.

> "I really appreciate how this reduces notifications for engineers not involved in the review." But it definitely increases notifications for people involved in the review. "A war room for each pull request" you'll exhaust your reviewers very quickly with this mindset. What about cases where any one random reviewer (or several) is needed from a larger group of people? Does everyone get paged in? Or cases where a single reviewer is assigned to multiple different reviews? This becomes a DDOS attack on the human attention span and has the potential to create disorientation more than anything.

jrowley 5y ago
I like how much you are focusing on developer focus here! I guess you need to compare this against something else for it to better. At my workplace, we were originally really small, just 3 or 4 engineers, so have a code-review specific channel where all members of the channel get notifications from github for ALL pull requests. As the size of the team increases (closer to 10 engineers now), I think the value from this channel is kind of decreasing, since there are fewer conversions happening in it. So this tool helps solve that problem.
arthurcoudouy 5y ago
> What about cases where any one random reviewer (or several) is needed from a larger group of people? Does everyone get paged in? If you select several reviewers and only one is needed, that'll ping the group of reviewers. That's not something we recommend, we think that one should use a random algorithm to select a specific reviewer if you prefer to select a group of people (https://docs.github.com/en/organizations/organizing-members-into-teams/managing-code-review-assignment-for-your-team#configuring-code-review-assignment https://docs.github.com/en/organizations/organizing-members-...). > Or cases where a single reviewer is assigned to multiple different reviews? This becomes a DDOS attack on the human attention span and has the potential to create disorientation more than anything. Instead of having notifications from Github, emails & Slack, we believed that it's easier to manage notifications when they come from only one place. When you're working on something, notifications should be muted. Axolo in Slack works as an "inbox zero", you should focus on your code and come see where your review is needed in a dedicated time.
gitgud 5y ago
> This becomes a DDOS attack on the human attention span and has the potential to create disorientation more than anything. I love this phrase, it's applicable to all user facing applications!