How to contribute

Active contributors: Kirill, Dmitriy Novozhilov, Dmitrii Gridin

This section explains how the Kotlin team works in this repository — the workflow, where issues live, how reviews are run, and what a "definition of done" looks like.

Issue tracker and ticket references

All public Kotlin work is tracked in YouTrack at https://youtrack.jetbrains.com/issues/KT. Issues are referenced as KT-XXXXX. Commit messages reference them in the subject or body, and using ^KT-XXXXX Fixed in a commit body auto-closes the corresponding issue.

The docs/contributing.md and docs/code_authoring_and_core_review.md files are the canonical onboarding documents. They cover commit message style, code review expectations, and the structure of merge requests / pull requests.

Where contributions land

The Kotlin team uses a mix of GitHub PRs (for external contributors) and JetBrains Space MRs (internally). Both flow through the same CI on TeamCity (https://teamcity.jetbrains.com/project.html?projectId=Kotlin). Code ownership is enforced via .space/CODEOWNERS (Space syntax), not .github/CODEOWNERS.

The cycle

1. Pick up an issue from YouTrack (KT-XXXXX) or open a new one for design discussion.
2. Branch and implement. See development-workflow.md.
3. Write or update tests before the production fix when fixing a bug — the convention is that diagnostic-difference commits make reviews easier. (See compiler/AGENTS.md: "When fixing an issue and adding a test, commit the test data as a separate commit before the fix.")
4. Run targeted tests for the affected area. See testing.md.
5. Submit a PR/MR. CI runs the full TeamCity pipeline.
6. Address review feedback. Code owners are pulled in based on .space/CODEOWNERS.
7. Squash/merge once green and approved.

Definition of done

• Tests pass locally and on CI.
• Test data added or updated where applicable; :generateTests re-run if new testData/*.kt files were added.
• Commit message has the right shape: imperative, ≤72-char subject, KT-XXXXX reference where applicable, FIR-prefixed if the change is mostly in compiler/fir/.
• For non-functional changes (refactors, reformats), the change is in its own commit.
• Public API changes are reflected in .api dump files (e.g., libraries/tools/kotlin-gradle-plugin/api/all/kotlin-gradle-plugin.api) — these files are committed.
• For dependency changes, gradle/verification-metadata.xml is regenerated (./scripts/update-verification-metadata.sh).

Commit message rules

From docs/code_authoring_and_core_review.md and compiler/AGENTS.md:

• Imperative mood, ≤ 72-char subject line.
• Subject explains what the change is; body explains why and how.
• Use FIR: prefix when the change is primarily in compiler/fir/.
• Reference YouTrack issues with KT-XXXXX.
• Use ^KT-XXXXX Fixed to auto-close.
• Keep tests with their corresponding code changes in the same commit (except the test-before-fix exception above).
• Refactors and reformats live in their own commits.

Per-area conventions

Several subsystems have their own AGENTS.md files. Read the area-specific docs before working on it:

Area	Docs
Analysis API	analysis/AGENTS.md
Compiler (frontend, IR, backends)	compiler/AGENTS.md
Build Tools API	compiler/build-tools/AGENTS.md
FIR analysis tests	compiler/fir/analysis-tests/AGENTS.md
KGP	libraries/tools/kotlin-gradle-plugin/AGENTS.md
KGP API	libraries/tools/kotlin-gradle-plugin-api/AGENTS.md
KGP integration tests	libraries/tools/kotlin-gradle-plugin-integration-tests/AGENTS.md
Native	native/AGENTS.md
PSI	compiler/psi/AGENTS.md

Releasing

Public releases are cut by the Kotlin Release team (SPACE_OWNER: "Kotlin Release"). -dev snapshots are published continuously to https://redirector.kotlinlang.org/maven/bootstrap. The bootstrap snapshot (the compiler used to compile this repo) is itself rolled forward periodically — search the commit log for "[Bootstrap]" entries.

Running the project locally for development

See getting-started.md for build, test, and run instructions; development-workflow.md for branch-and-iterate guidance; debugging.md for common error patterns.