Hi HN!<p>We’re Arthur and Sydney (cosydney). We’re building Axolo (<a href="https://axolo.co" rel="nofollow">https://axolo.co</a>) a bidirectional Github-Slack integration to help tech teams reduce pull request time and improve code review’s feedback.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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 (<a href="https://youtu.be/aoOZNGdBKlY" rel="nofollow">https://youtu.be/aoOZNGdBKlY</a>) of how it works, if you want to take a glance at our main features.<p>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).<p>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!
I'm in agreement that there is a lot of room for improvement in the processes around Code Reviews and so I'm very optimistic about your ability to deliver real value in this area... that said, I'm struggling to square this solution. My experience is that the challenge is the lack of time allocated to Code Reviews and _not_ a lack of visibility: GitHub and GitLab support assigning reviewers and notifications, and there are lots of reminder apps around.<p>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?"<p>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.
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.<p>Then your first point is:<p>> No more context-switching<p>> 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.<p>But the video next to it shows... constant context-switching/jumping between Slack and GitHub.<p>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?<p>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?
Congrats! I’ll be curious to see if you tackle how to continue developing on top of a PR in review, a la stacked diffs. One of the biggest frustrations I have with GitHub workflows is that stacking PRs can be painful but often required if teammates take longer to review PRs.
It’d be nice if there was a painless way to have stacked diffs but in the Git framework. That way I can build off of PRs up for review with having to deal without nasty rebases once the first PR is merged into master.
Neat tool.<p>My recurring observation is that PR approvals take on the form of "voting rings" and other sabotage.<p>Pernicious.<p>When commits are a primary PKI, devs can subtly sabotage co-belligerents, camping on hostile PRs while fast tracking their own.<p>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".
I think this is neat. You may need to make this customizable for users. As a tech lead / manager, I used to have 5-15 in-flight PRs at a time. Some of them took a week to review. I can see having them all in slack possibly becoming tiring. The bottleneck is not my attention span, but my schedule.<p>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?
I love solutions that are working in this area. Reminds me a bit of Codestream.<p>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.<p>So many ways and innovative companies like Axolo which are finding ways to remove barriers to better information sharing and context.
As a team of a dozen of devs, we've been using Axolo for several weeks now. We previously relied on a slack channel where everyone would be notified for every comment on every PR: it's a relief not to be so much annoyed anymore.<p>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
I've been using Mattermost Incidents [0] with a Pull Request playbook like this for awhile, but its nice to see something else in this space. Wish it were open source.<p>[0]: <a href="https://docs.mattermost.com/administration/devops-command-center.html" rel="nofollow">https://docs.mattermost.com/administration/devops-command-ce...</a>
just because you create slack channel for something.. or everything :D, doesn't mean that the reviewer will have more spare time to look at your PR. ;)
I started recommending this to people advertising as a "slack" company, but... I would start supporting MS Teams too. It's starting to eat slack's customer base.
Your website mentions Pull Request analytics which to me is more interesting than the Slack integration but it's light on the details.<p>Could you share a demo or screenshot of what kind of analytics a team gets from Axolo?
I thought CodeStream would solve this. It’s integrated in VSCode, even less context switching. It didn’t work. The review experience is not good enough.