[HN Gopher] Launch HN: Axolo (YC W21) - Faster pull requests and...
___________________________________________________________________
Launch HN: Axolo (YC W21) - Faster pull requests and code reviews
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!
Author : arthurcoudouy
Score : 76 points
Date : 2021-06-15 13:46 UTC (9 hours ago)
| kovacs_x wrote:
| 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. ;)
| cosydney wrote:
| 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.
| asderz wrote:
| What happen if that PR will be merged? The channel will be
| deleted?
| cosydney wrote:
| It can be automatically archived, and all of the conversations
| is being posted into github to keep the documentation.
| satya71 wrote:
| 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.
| cosydney wrote:
| Habits are hard to break !
| polskibus wrote:
| Also, they save reviewed snippets and remarks. It's not great
| for private projects.
| shadeslayer_ wrote:
| Sounds promising. I'd look forward to trying this out if and when
| you launch a Bitbucket integration.
| arthurcoudouy wrote:
| 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.
| fsociety wrote:
| 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.
| cosydney wrote:
| 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.
| fsociety wrote:
| My app doesn't always allow me to edit comments, I meant
| "without having to deal with nasty rebases"
| yogibhai wrote:
| Are you hiring? I have built slack apps previously
| cosydney wrote:
| Hey, happy to discuss we might be hiring soon ! shoot us an
| email on hey @ getchaos.app
| pulledrequest wrote:
| 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.
| arthurcoudouy wrote:
| 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.
| pulledrequest wrote:
| 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! :-)
| arthurcoudouy wrote:
| 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!
| egypturnash wrote:
| I am disappointed that there is not a cute little axolotl mascot.
| arthurcoudouy wrote:
| 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
| jrowley wrote:
| I really appreciate how this reduces notifications for engineers
| not involved in the review.
| csmpltn wrote:
| > "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.
| arthurcoudouy wrote:
| > 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.
| jrowley wrote:
| 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.
| cosydney wrote:
| Yes, one should only receive relevant notifications.
| TylerJewell wrote:
| 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.
| cosydney wrote:
| 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.
| duuck215 wrote:
| 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
| arthurcoudouy wrote:
| 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 :)
| aparsons wrote:
| 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?
| cosydney wrote:
| 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
| iovrthoughtthis wrote:
| what about if someone else did your reviews for you?
| cosydney wrote:
| What do you mean exactly? If someone else reviews unstead of
| the person who has been asked ?
| rhacker wrote:
| 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.
| cosydney wrote:
| Yes it makes sense, especially since Microsoft also owns Github
| ! will give it more thought thank you.
| thecrumb wrote:
| Yeah we're Teams/ AWS CodeCommit
| css wrote:
| 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...
| cosydney wrote:
| 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.
___________________________________________________________________
(page generated 2021-06-15 23:00 UTC)