Launch HN: Axolo (YC W21) – Faster pull requests and code reviews
We’re Arthur and Sydney (cosydney). We’re building Axolo (https://axolo.co) a bidirectional Github-Slack integration to help tech teams reduce pull request time and improve code review’s feedback.
Sydney and I met in 42, a software engineering school in Paris, and started working together on different tech projects last year. While working on our last business, a SaaS management platform for SMEs, we were in a squad of 4 to 5 people and often found ourselves writing direct messages in Slack about pull requests. We were telling each other things like ‘Hey Arthur, I’ve updated my last pull request feature/zoom_integration, do you have time to check it out soon?’ or “it’s been two days, do you have time to review feature/user_settings today, here is the link: github/axolo-co/api.axolo.co/pull/381?”. It was messy, took time and mental load to contextualize each pull request to each other.
We talked to over 100 companies about how they ship code. Here is the most common pattern: An engineer creates a pull request and asks someone or a dedicated team to review it. Notifications are poorly handled and people often ping again directly. Then, comments are made on Github and if a disagreement appears, the conversation goes on a voice call or in Slack.
This approach has two major problems. (1) Dangling pull requests are waste of time and a source of frustration for developers. They cause the code development process to slow down and prevent developers from focusing on a new task ahead. It’s difficult to dive back into a pull request you submitted two days ago. (2) Feedback on code is hard to convey between one developer to another. It can be misinterpreted or even worse: not given at all.
The ideal solution doesn’t need a new tool in our daily routine. Having in mind that most of the friction was in context-switching between Github and Slack, we decided to build a bridge between those two.
So we developed Axolo as a bi-directional Github-Slack integration. Each pull request creates a temporary Slack channel where Github notifications are sent (comments, reviews, actions & deployments). The creator, reviewers, and assignees are invited to that channel. Then when the pull request is either closed or merged, we save the conversation as documentation in the Github pull request and archive the channel.
We're not only a code review notification center. We consider each pull request as a small independent project where all people that take a part in it will be invited. Here’s a demo video (https://youtu.be/aoOZNGdBKlY) of how it works, if you want to take a glance at our main features.
Our public beta started three weeks ago. To sign up on Axolo, you need to install our Github app on your organization (we do not have access to your code) and our Slack app. Most of our features are free for everyone, but if you’re looking for specific settings & analytics, the professional plan is 8$/ engineer / month that you can try (you don't have to enter a credit card upfront).
We know the Hacker News community is full of many engineers with deep experiences in code reviewing (and code shipping!) and we look forward to receiving your feedback on our work. Thank you!
56 comments
[ 3.3 ms ] story [ 111 ms ] threadBut 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.
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-...).
> 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.
I love this phrase, it's applicable to all user facing applications!
Why make the pull request such a formality? The process of writing the code, developers can have active discussions with other key members of the team from within their IDE. Those conversations are then captured as essential context to facilitate the PR review itself.
So many ways and innovative companies like Axolo which are finding ways to remove barriers to better information sharing and context.
We bumped on Codestream with one of the person who works at Axolo, we had this idea in mind but after talking to many developers we realized that no one mentionned creating PR with their IDE or having direct conversations from there. We want Axolo to fit in well in developers habits => Using slack for messaging and code editors to code.
[0]: https://docs.mattermost.com/administration/devops-command-ce...
Where do you see the difference in a private message to someone that says "hey, can you check out this Pull Request?" and a Slack channel that automatically says "hey, can you check out this Pull Request?"
I don't mean to be cynical because I do believe there is a problem to be addressed but I am struggling to see how a bunch of auto-updating Slack channels are going to address it. That said, I haven't worked in a team where it's normal to jump on a call to discuss a Pull Request and so maybe that's the fundamental difference that makes it not right for my workflow but does make it meaningful for others.
> Where do you see the difference in a private message to someone that says "hey, can you check out this Pull Request?" and a Slack channel that automatically says "hey, can you check out this Pull Request?"
In case 1, you need to write in dm to your reviewers and ping them again if you did not receive any news. In the other case, Axolo will do it automatically and remind them about it. We believe it's easier to have specific channels because if you're requesting a review at the same time as your reviewer might, different conversations will happen in the same dm channel. And that's only regarding someone asking someone else for a review, there are other informations that have importance in your worklfow regarding pull requests (Github actions, comments & reviews)
Referring to the lack of time, we think that might be addressed in motivating engineers do more code reviews. We try to foster better practices with our "leaderboard" but we're still iterating to find the best answer.
> Axolo helps to unstuck dangling pull requests in centralizing notifications in one place and let them be top of mind as a "to-do list" in your Slack.
That's an interesting perspective: Slack as the preferred workspace for developers, vs. the platform they use for code management. I wonder how that squares with GitHub and GitLab's shift towards owning the full lifecycle of code -- "DevOps platform", "a single application for unparalleled collaboration, visibility, and development velocity".
Personally, I'd rather spend less time in Slack and more time in GitHub and so it sounds like that's where the mismatch lies for me and my team. That said, good luck, as a solution for people who want to stay in Slack it seems great and I'm sure there's a lot of people like that! :-)
And one thing we're sure is that our current users are Slack lovers - if you're trying to spend less time in Slack, I'm 100% convinced that Axolo is not right for you!
To this date we don't have access to the code and it's easier for companies to try us this way. So not sure we will go too much into details on this topic.
Stacked PR shouldn't exist, or at least rarely. We plan to introduce analytics and we think that too many stacked PR should be a warning that something is not right.
I have seen them used in a few ways:
- To enable the creation of PRs that change just one thing. This makes them easier to review, revert or cherry pick.
- Allow you to continue to work while a more intensive CI or review process is under way.
With a good stacked change system, like in Phabricator or Gerrit, I have seen some of the most productive ever devs always using stacked changes.
There is of course room for improvement (some bugs, latency compared to github integration, very few options) but the gain is definitely here already :) Thanks for this great tool
Secondly, and this is an easily debunked point but I want to ask it nevertheless - what stops Github from building a bot to do this? How to you plan to create additional value beyond the notifications?
2. Nothing stops them, we plan on moving fast listening to our users. For now bigger companies are asking for specifics analytics
Can you explain that in more detail? Do you mean reviews in general or with a specific focus?
Please let me know. Ronald.
Or must one give the Axolo bot permissions to all public channels in a slack workspace?
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?
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!
Could you share a demo or screenshot of what kind of analytics a team gets from Axolo?
This is a work in progress. We iterate with our beta cohort to build the panel they want. In addition to the information you can see there, we let you know if we detected potential risks in your code development process (pull requests merged without any review for example).
If you're interested in knowing more about our roadmap concerning the analytics, we might build a separate app for analytics only.
My recurring observation is that PR approvals take on the form of "voting rings" and other sabotage.
Pernicious.
When commits are a primary PKI, devs can subtly sabotage co-belligerents, camping on hostile PRs while fast tracking their own.
Example from my last gig: Senior dev is fire hose of code. Frequent large dumps "Oh, something I did over the weekend. Just approve it. It needs to go into production today." Same dev then obsesses over every PR, repeatedly requests rework, insists "large" PRs be "broken up" because "I need to understand this better".