What we recommend is to have dedicated time for code reviews every day and you should be notified only during these slots, protecting the rest of your time for deep work sessions. Receiving untimely notifications is a distraction and a mental load that we do not recommend. What matters for a developer is to have dedicated and safe slots to be able to work effectively on his development. If you sometimes feel that you receive too many unorganized notifications, this will be for you. Regarding GitHub Action, Deployments, and notifications concerning the whole repository, Axolo was built to provide granularity and let engineers decide what notifications they want to receive.Ī workflow failed? Did someone cancel your deployment? Receive only your selected notifications concerning your pull request in their specific channel! Pushing notifications at the right time Sending only the notifications that matterĪn important aspect regarding notifications is to be able to subscribe to only the ones that matter to you. Now, everything can be handled from a pull request channel: have the whole context, the conversation, and even accept the pull request with one click. The main objective of the single-purpose ephemeral channel was to be able to centralize every notification in one dedicated workspace and create the right place to talk about the code. the Slack application) saying I could review the pull request again.įor any of these notifications, in order to have the whole context of what my next actions should be, I needed to click on the link and grab some more information directly in GitHub. Meaning: if I asked for changes on a pull request, I would have been notified once for each answer of code review comment and usually the creator pinged me again (in DM vs.
Giving context about the code review statusĪ constant struggle I faced in my past experiences was to receive countless notifications about pull requests I created or I should review without any context. That way, you only receive notifications that directly concern your work. We decided to build Axolo focusing on that one specific complaint and create ephemeral channels where we only invite the pull request creator and its reviewers. They received notifications in a squad channel about pull requests from other teammates or from the GitHub bot that reminded the whole channel about some dangling code reviews. A starting point for Axolo was engineers that complained about unnecessary notifications in Slack. Is your engineering team also divided into squads? If yes (hopefully), most engineers wouldn’t want to be notified by your pull requests if they’re not directly involved. In this article, we will detail how Axolo was built to become the ultimate Slack pull request reminder following the past four principles. In order to use the best tool to organize and remind engineers about code review, the ultimate Slack pull request bot must: notify only the right people (not a whole squad when a specific reviewer is requested), give context about the code review status, not only the last notification, send only the notifications that matter, notify at the right time and understand if engineers are available for review or not. What a Slack pull request reminder bot should provide A great code review should be done within a few hours after a request and be thoroughly processed. Do you want reviewers to handle your pull request faster?ĭo you think that your code development sessions shouldn’t be disturbed by untimely notifications?Īt Axolo, we think two characteristics are most important for handling pull requests: attention and speed.
0 kommentar(er)
