3 ms·

I'm confused about this. It looks like what you do is create a separate channel for every pull request, and then send notifications to that channel. Messages in

by jorams 5y ago

I'm confused about this. It looks like what you do is create a separate channel for every pull request, and then send notifications to that channel. Messages in the channel get batched up at the end and sent to the PR. Then your first point is: > No more context-switching > Pull requests will create an ephemeral Slack Channel where all the work will be done and imported from Github. Stop wasting time jumping from Github to Slack. But the video next to it shows... constant context-switching/jumping between Slack and GitHub. For everything one has to say about a PR this introduces a choice between a GitHub comment and a Slack message, where comments on GitHub get mirrored to Slack but not (directly) vice-versa. Why not just keep the conversation on GitHub? Do comments seem too "formal"? Are GitHub's notifications not targeted enough? Those seem like possible problems, but is splitting the conversation space really part of the solution?

arthurcoudouy 5y ago
During the pull request lifetime, only messages from Github are sent to Slack. This enables our users to use Slack as a center of notifications and let them have more synchronous communication if a conflict appears (if they want to). The other way is only to save the Slack communication as Documentation for future context if the pull request needs to be reviewed again in the future (after it has been merged or closed). Github's conversations are fine until a conflict appears, when two opposite point of views are confronted, what usually happens is to jump on a call or continue the conversation in Slack. As most of the conversation are still in Github, we do not feel that we split the conversation but rather use Slack as a way to let them stay top on mind if your review is required. Moreover, there aren't only comment's notifications but Github Action, deployments and soon more that takes place in their respective pull request channel. Some people are more likely to use Axolo as a new way to handle code review conversations, some other as a new center of notification. If you have other points of friction in mind, please do share them, that helps us better identify potential issues!

by jorams 5y ago

arthurcoudouy 5y ago

During the pull request lifetime, only messages from Github are sent to Slack. This enables our users to use Slack as a center of notifications and let them have more synchronous communication if a conflict appears (if they want to). The other way is only to save the Slack communication as Documentation for future context if the pull request needs to be reviewed again in the future (after it has been merged or closed). Github's conversations are fine until a conflict appears, when two opposite point of views are confronted, what usually happens is to jump on a call or continue the conversation in Slack. As most of the conversation are still in Github, we do not feel that we split the conversation but rather use Slack as a way to let them stay top on mind if your review is required. Moreover, there aren't only comment's notifications but Github Action, deployments and soon more that takes place in their respective pull request channel. Some people are more likely to use Axolo as a new way to handle code review conversations, some other as a new center of notification. If you have other points of friction in mind, please do share them, that helps us better identify potential issues!