How to contribute

This section covers how to actually do work in this repo — the dev loop, testing, conventions, and tooling. The user-facing contributing rules (code of conduct, PR etiquette) live in CONTRIBUTING.md and DEVELOPERS.md at the repo root; the pages here focus on what you need while writing code.

What to read first

If you want to...	Read
Start a branch and ship a change	Development workflow
Run or write a test	Testing
Match the existing coding style	Patterns and conventions
Understand lint / build / CI	Tooling

Branch rules

Studio uses a {type}/{branch_name} convention (type ∈ chore | fix | feature). The PR title becomes the merge commit title; conventional-commit prefixes (feat:, fix:, chore:, docs:) are used heavily across the repo, see git log for examples.

Reviews

• PRs against apps/studio automatically tag the frontend team.
• The team reviews PRs in submission order; competing/duplicate PRs are common because there is no formal "issue assignment" process — communicate early on the issue thread.
• For external contributors, no special access is needed; CI runs against forks for read-only checks but writes (publishing, deploys) require maintainer involvement.

Definition of done

• pnpm lint, pnpm typecheck, and the relevant pnpm test:* all green for the apps you touched.
• New eslint warnings should not increase ratchet counts — pnpm --filter studio lint:ratchet will fail otherwise (see Tooling).
• Prettier passes (pnpm test:prettier).
• For Studio: pnpm e2e:setup:cli + pnpm e2e if your change touches user-visible flows.
• For docs / www: visual check on the dev server.

Getting unstuck

• DEVELOPERS.md has the canonical setup notes.
• Studio's contributing checklists live at apps/studio/contributing/contributing-checklists.md.
• Real-time chat: the public Discord (discord.supabase.com).