Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Axolo (YC W21) – Faster pull requests and code reviews
97 points by arthurcoudouy on June 15, 2021 | hide | past | favorite | 56 comments
Hi HN!

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!




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.

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.


Today, what we provide is a way to handle code review without context-switching between Github and Slack/calls. 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.

> 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.


Thank you for the 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! :-)


Thanks for this topic! As we're only working on Github for now, I can't speak for Gitlab. The shift for a code management tool to become a collaboration tool is a giant step. Embedding the only information regarding interactions around code reviews in Slack was a small step to centralize everything in one place.

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!


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?


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!


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.


We've also encountered that problem in some cases. Stacked PR are difficult to manage. We could potentially have multiple PR into a single channel to make communication easier abroad stacked PR.

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.


Can you explain why you don’t think stacked PRs should exist? What repo sizes, team sizes, and CI practices does your recommendation apply to?

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.


My app doesn’t always allow me to edit comments, I meant “without having to deal with nasty rebases”


Neat tool.

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".


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.

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?


Thanks. We are rolling out more settings to make it customizable for each teams.

2. Nothing stops them, we plan on moving fast listening to our users. For now bigger companies are asking for specifics analytics


what about if someone else did your reviews for you?


Hello,

Can you explain that in more detail? Do you mean reviews in general or with a specific focus?

Please let me know. Ronald.


What if someone else, with all the context necessary and whose sole focus was on doing code reviews, did them for you?


How would they get the necessary context? What if that context is rooted in business requirements?


What do you mean exactly? If someone else reviews unstead of the person who has been asked ?


What if someone else, with all the context necessary and whose sole focus was on doing code reviews, did them for you?


I love solutions that are working in this area. Reminds me a bit of Codestream.

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.


Agreed. I pursue the idea that we should be able to talk in an easy way about the code we produce.

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.


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.

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


Thank you for taking the time! Axolo is still in beta, sorry for the fews bugs you might encounter. Reach out when you find some, we'll always be in alert mode :)


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.

[0]: https://docs.mattermost.com/administration/devops-command-ce...


Thank you for sharing mattermost, didn't know that. it's interesting to see Pull Requests as an 'incident' that needs to be resolved by different party. It didn't made sense to make Axolo Open source at the beginning but we are considering it today.


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. ;)


Right, I think Axolo makes it possible for your reviewer to respond quickly to something he sees and also makes it easy to be the next priority for your reviewer.


Do you think having dozens of channels pinging at you all day is a solution? I’d just snooze the channel if it barks too much at me.


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


> "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.


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.


> 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!


> 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-...).

> 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.


Yes, one should only receive relevant notifications.


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.


Yes it makes sense, especially since Microsoft also owns Github ! will give it more thought thank you.


Yeah we're Teams/ AWS CodeCommit


I am disappointed that there is not a cute little axolotl mascot.


That's not working (you can't save it) anymore but you can create your own here..! https://app.axolo.co/register/axolo-co/createyourown


Your website mentions Pull Request analytics which to me is more interesting than the Slack integration but it's light on the details.

Could you share a demo or screenshot of what kind of analytics a team gets from Axolo?


You can find the first version of analytics here : https://app.axolo.co/leaderboard/axolo-co

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.


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.


Also, they save reviewed snippets and remarks. It's not great for private projects.


Habits are hard to break !


Sounds promising. I'd look forward to trying this out if and when you launch a Bitbucket integration.


Thanks! We're still working on developing a great experience on Github, we'll look into more integrations in a few months. Our issue will be to decide on Gitlab vs. Bitbucket first.


Are you hiring? I have built slack apps previously


Hey, happy to discuss we might be hiring soon ! shoot us an email on hey @ getchaos.app


what permissions are required on the repo and slack orgs ?.


Most importantly we don't require to share the code from gitbhub. Github: Reads permissions repository, issues, teams, pull requests. Write: Pull Requests (so that we can write the conversations that happen in slack) Slack: read and write Members, channels and private message to the bot


Forgive me, because I still am unsure: can a bot in Slack be given permission to create channels, read from, and delete only the channels it creates?

Or must one give the Axolo bot permissions to all public channels in a slack workspace?


Unfortunately, Slack does not have that level of granularity yet, so the permissions are given to all public channels. But we only interact with Slack saving the ID of the specific channel we create, we do not store any information from other channels.


What happen if that PR will be merged? The channel will be deleted?


It can be automatically archived, and all of the conversations is being posted into github to keep the documentation.


Do you have an example of what that looks like? The video posted above doesn't have any conversation happening in the slack channel and doesn't close the PR.


True that, I've made a quick loom so you can check it out: https://www.loom.com/share/42a7b62cbbf24eb39d7eac0a57ffb5f8




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: