## Rules of Documentation

- We document everything that we know.
- We don't do anything unless there's a documented process for it.
- Never repeat the same thing in multiple docs.
- Try to put the documents close to the source.
  تا حد امکان مستندات رو در نزدیک‌ترین جا به منبع بنویسید. مثلا توضیحات کد رو بهتره به صورت کامنت کنار کد بنویسید تا توی مستندات پروژه. یا مستندات پروژه رو در همون پروژه بنویسید نه توی پروژه‌های جامع‌تر

## Documentation Tools

- [Confluence](./confluence): General and Business Docs
- [Retype](./retype): Project-specific Technical Docs
- [Swagger](./swagger): API Docs

---

## Technical Decisions [!badge variant="primary" text="ADR"]

We use [MADR (markdown architecture decision records)](https://adr.github.io/madr/) to document our technical decisions.

!!!
MADR is a structured template and not a tool. These docs are included in the technical docs of each project (Retype)
!!!

[!button variant="primary" icon="info" text="How to use MADR"](/documentation/madr)

---

## Comments [!badge variant="primary" text="Doc comments"]

Almost all programming languages have a convention for writing docs in comments.

[!button variant="primary" icon="code" text="How to write comments"](/conventions/comments)

---

## Commit message [!badge variant="primary" text="Conventional commits"]

We use [Conventional commits](https://www.conventionalcommits.org/) ([Why conventional commits?](/ADR/use-conventional-commits-as-convention-for-commit-messages)) as convention for our commit messages.

[!button variant="primary" icon="git-commit" text="How to write commit messages"](/conventions/git-commit-conventions)
