# FlexReview

{% hint style="success" %}
Read our launch post about why we built FlexReview: <https://www.aviator.co/blog/flexreview-a-flexible-code-review-framework/>
{% endhint %}

## What is FlexReview

FlexReview is a modern code review platform focused on on collaborative teams. It acts as a drop-in replacement for GitHub `CODEOWNERS` . FlexReview uses domain expertise and recursive ownership to avoid rigid boundaries of GitHub `CODEOWNERS`.

<figure><img src="https://273246003-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOAPqUQVbLbsfI5YESl32%2Fuploads%2FmwzHgE7ZlnyYqtd5rY5a%2FScreenshot%202025-03-16%20at%207.55.30%E2%80%AFPM.png?alt=media&#x26;token=60dadd23-a6e5-4088-9bde-f3c231f21f72" alt=""><figcaption></figcaption></figure>

## Components

There are two main components of FlexReview:

* [Reviewer assignment](https://docs.aviator.co/flexreview/concepts/reviewer-suggestion-and-assignment) - Automatically assign code reviewers for selective (or all) pull requests based on the configured preferences.
* [Review Validation](https://docs.aviator.co/flexreview/concepts/validation-in-flexreview) - Ensure that appropriate approvals have been granted before a pull request is considered mergeable.

## Concepts

There are a few core concepts that differentiates FlexReview from a rigid GitHub `CODEOWNERS` framework.

* [Domain expertise](https://docs.aviator.co/flexreview/reference/expert-scoring-algorithms)
  * A score calculated based on past history of authorship and reviewership. This is calculated for each file and each user to ensure FlexReview can assign the right reviewers.
* [Recursive ownership](https://docs.aviator.co/flexreview/concepts/recursive-ownership)
  * True representation of the actual shape of code ownership to avoid rigidness of GitHub `CODEOWNERS`.
  * Simplified ownership definition using distributed YAML files
* [Reviewers minimization](https://docs.aviator.co/flexreview/concepts/reviewer-suggestion-and-assignment)
  * When a PR spans multiple teams, it finds a common parent owner and minimizes number of reviewers. One or more reviewers are assigned depending on the code complexity.
  * All reviewer assignments are predictable and governed by rules, so you can stay compliant.
* [Team automations](https://docs.aviator.co/flexreview/how-to-guides/set-up-team-rules)
  * Each team can choose an assignment strategy from domain expertise, review load, or oncall rotations.
  * Slack notification can be sent to team's channel when there's new PR for your team.
  * Reviewer can be auto-reassigned when there's no reply.
* [Team dashboard and SLO goals](https://docs.aviator.co/flexreview/concepts/slo-management)
  * Team members can see the PRs that are assigned to them, or their entire team.
  * Teams can define the expected size of the PRs and review turnaround time.
  * Dashboard shows how many PRs are within the review-time SLO.
* [Selective Dismissal](https://docs.aviator.co/flexreview/concepts/validation-in-flexreview)
  * A validation system to ensure that appropriate approvals have been granted before a pull request is considered mergeable.
  * Reviewers are responsible for approving on behalf of the files they own.
  * Reviewers can be selectively dismissed when new code changes are pushed tied to their ownership.
  * Includes a [break-glass](https://docs.aviator.co/concepts/validation-in-flexreview#breakglass-scenarios) override for emergency approvals.

## Basic ownership config

Since FlexReview automatically tracks domain expertise for each, you can simply define a top level ownership such that the code is collectively owned by all of engineering, and FlexReview will automatically assign the right reviewers.

```
* @engineering
```

However, most teams would want to define a bit more fine-grained ownership, where recursive ownership helps provide that flexibility.