Getting Started
Make the best of Axolo

Make the best of Axolo

Here is a list of recommandations to make the best of Axolo. We recommend you to share this with your team so that everyone is on the same page. Here is a summary of them all:

RecommendationReason
Set up your notificationsTo focus while working
CodeownersTo automatically add reviewers in PR channels
Slack sectionsTo find your PR channels easily
Axolo timeslotsTo only get notified when you want to
Auto-leave when a reviewer approvesClear out your channel inbox with this option
Set up team channelsHave a high-level view of your team
Configure Slack to show media filesSee those screenshots directly in your channels

Set up your notifications

  1. turn off email notifications from GitHub or GitLab (disable the Global notification level),

  2. set up Slack notifications for Direct messages, mentions & keywords or Nothing. Being notified for every message disturbs your work.

Set up Slack notif

How to use Slack sections

As Slack does not provide any way to handle sections in its API, Axolo can't manage your channels in sections, but we have a solution!

We recommend to clean the default Channels section from any non-Axolo channels. That way, all your Axolo channels will automatically be created in this default section and won't be mixed up with the rest of your environment.

Axolo channel management

Codeowners for GitHub

Code owners are a good way to automatically invite reviewers on pull requests in your Slack channel.

Install code owners to automate review requests

You can find the complete documentation about code owners on GitHub.

Quick start:

  1. Add a CODEOWNER file in the root, docs/, or .github/ directory of the repository,
  2. Go on your code review team settings page,
Automatic review request with GitHub Codeowners
  1. Set up the settings following the instructions in Automatically add a whole team as reviewers PR channels or Automatically add a specific individual reviewers PR channels sections.

Automatically add a whole team as reviewers in PR channels

If you wish to add a whole team to each PR channel, you should make sure that:

  • Only notify requested team members is off,
  • Enable auto assignment is on,
  • When assigning team members, remove the review request for the team, is off.
  • your Axolo settings for Set the maximum number of reviewers to invite in PR channels when you request a team as reviewer is set to a number higher than your team size (ex: if you want to add 3 reviewers in each PR, set it as >= 3) - you can find this setting in your General page on app.axolo.co (opens in a new tab).

Automatically add a specific individual reviewers in PR channels

If you wish to add specific individuals only in PR channels, you should make sure that:

  • Only notify requested team members is on,
  • Enable auto assignment is on,
  • Set up the number of automatic assignments to your preference,
  • When assigning team members, remove the review request for the team, that is on.
  • your Axolo settings for Set the maximum number of reviewers to invite in PR channels when you request a team as reviewer is set to a low number (less than your team specified in the code owners file) - you can find this setting in your General page app.axolo.co (opens in a new tab).

Troubleshooting: reviewers are not invited to PR channels

Is the PR ready for review?

If the PR is not ready for review (still in draft), reviewers won't be invited to the PR channel. You should see the moon icon in the PR reviewer section.

PR draft

Codeowners for GitLab

GitLab does not have a built-in feature to automatically assign reviewers. However, you can set up code owners to receive suggestions when opening a merge request. If you want to set up code owners to receive suggestions in GitLab, please follow the instructions in our dedicated article (opens in a new tab).

Organize stand-ups with your team around Axolo PR summary

Set up Axolo to send daily PR recap to specific channels to organize your stand-ups from app.axolo.co (opens in a new tab).

Axolo PR summary for stand-ups

How to use Axolo timeslots

Axolo's timeslots are meant to preserve developers' focus. By creating timeslots from the Axolo home in Slack, each time someone request a review from you, you will only be invited right away if the time is within one of your timeslot, or at the beginning or the next timeframe.

Invite later notification
Axolo timeslots for code review

Auto-leave when a reviewer approves

If your admin enables the auto-leave feature, you will automatically leave a pull request channel 20 seconds after approving it (only available on GitHub for now).

Automatic leave code review channels

Set up team-specific channels

If your engineering team is divided in squads and you're interested in using the Axolo general channel feature, we recommend to enable team-specific channels for each of your squad. That way, new PR/MR will create a notification only in their corresponding squads without notifying people that should not.

Configure Slack to show media files

By default, Slack does not show file larger than 2MB. You can change this setting in your parameters.

Slack file setting

Do you think we're missing something that you implemented in your team? Please tell us in the chat!

Understanding Axolo pull request status

Axolo team notifications

There are 6 different status for a pull request in Axolo and each status has a dedicated emoji reaction inside team channels:

Pull Request StatusDefault Emoji
Draft✏️
WIP (Work-in-progress)🔧
Reviewable🙏
Mergeable🟢
Closed🛑
Merged

Draft

On GitHub, a pull request is considered a draft when it has a draft status. On GitLab, a merge request is considered draft when its title starts with 'draft:' or 'wip:'.

Axolo will create a channel and invite the author (and its reviewers if the author assigned them). On GitHub, it will not invite reviewers that are automatically assigned by a code owner file as GiHub does not 'request a review' until the pull request is ready for review.

The notification inside team channels is not created yet, it will be sent only when the pull request is ready for review.

Ready for review

When a pull request is ready for review, it means that it is ready to be reviewed.

Work-in-progress

When a pull request is in work-in-progress, it means that it was ready for ready and something changed this status. This change may be caused by:

  • on GitHub, someone requested changes on the pull request,
  • on GitLab, someone unapproved the merge request,
  • the CI/CD has revealed some error that prevent the pull request to be merged,
  • Axolo thinks there is a conflict with the base/target branch.

Mergeable

When a pull request is mergeable, it means that it is ready to be merged. To be mergeable, a pull request needs to:

  • receive the minimum amount of approvals,
  • have no conflict with the base/target branch,
  • pass all the required CI/CD checks.

Merged/Closed

When a pull request is merged or closed, it means that it is no longer open.