vane 0.9.2

A flow-based reverse proxy with multi-layer routing and programmable pipelines.
---
title: Review Process
description: Documentation review and approval process
icon: GitPullRequestDraft
---

import { Steps, Step } from 'fumadocs-ui/components/steps';
import { Callout } from 'fumadocs-ui/components/callout';

Every Pull Request (PR) goes through a review process to ensure quality, accuracy, and consistency.

<Callout title="Contribution Scope" type="idea">
	We encourage direct PRs for small fixes (typos, bug patches) and documentation improvements.
	However, for significant changes (new features, architectural refactors), please **open an Issue
	first** to discuss your proposal before starting work.
</Callout>

## The Lifecycle of a PR

<Steps>
<Step>
### Automated Checks (CI)

When you open a PR, GitHub Actions will run automated checks depending on the file types:

- **Code Changes**: Runs `cargo clippy` (linting) and `cargo fmt --check` (formatting).
- **Documentation**: Runs markdown linting and formatting checks.
- **Build**: Verifies that the documentation site compiles without errors.

<Callout title="Note on CI Status">
	Currently, the automated CI pipeline for Vane is still under development. You may temporarily skip
	this check, but once implemented, all PRs must pass CI before review.
</Callout>

**Action**: If CI fails (once active), please fix the errors and set your PR to **Draft** status until it passes. Maintainers will usually not review PRs with failing CI.

</Step>

<Step>
### Maintainer Review

A core maintainer will review your changes based on the type of contribution:

- **Code Changes**: You must provide a brief description of the change. This includes the reasoning (e.g., which Issue it fixes, what Feature it adds, or why the modification is necessary).
- **Documentation Changes**: Maintainers will check if the content is factual, accurate (Fact Check), and logically reasonable. They will also verify that it follows the [Markdown Style](./markdown-style) and is easy to understand.

</Step>

<Step>
### Feedback & Iteration

The reviewer may leave comments requesting changes.

- **Discuss**: If you disagree, politely explain your reasoning.
- **Update**: Push new commits to the same branch. **Please squash your commits locally** before pushing if possible to keep the history clean during review iteration.

</Step>

<Step>
### Merge

Once approved, a maintainer will merge your PR.

- **Merge into Main**: Your changes will be merged into the `main` branch.
- **Cleanup**: Related issues will be automatically closed if linked properly.
- **Deploy**: The documentation site is automatically redeployed after merging.

</Step>
</Steps>

## Reviewer Expectations

If you are reviewing a PR (as a maintainer or community member):

- **Be Constructive**: Focus on the content, not the person.
- **Be Specific**: "This sentence is confusing" is less helpful than "Consider rephrasing this to...".
- **Verify Facts**: Don't assume code snippets are correct; test them if possible.