Skip to main content
These rules come from CONTRIBUTING.md and apply to everyone, including coding agents working on someone’s behalf. Coding rules, commands and checks are in AGENTS.md.

​
Issues

  • One problem or request per issue. Use the issue forms (Bug report or Feature request); blank issues are disabled.
  • Bugs: steps that reproduce the problem from a fresh start, on the latest release. A minimal sample project is the fastest way to a fix.
  • Features: the problem and the acceptance criteria. A feature is ready to build once a maintainer labels it planned.
Labels track status:

​
Pull requests

1

Pick one problem

One problem per PR. If it resolves an issue, link it with Closes #123. Unrelated refactors go in their own PR.
2

Reproduce first

Reproduce the problem, or write a test that fails before the fix.
3

Fix the cause

Fix the root cause, then check whether the same cause breaks anything nearby. Keep the diff focused.
4

Run the checks

Run what CI runs for the parts you touched (below), and verify UI or runtime changes in the running app.
5

Open the PR

Title in Conventional Commits form, e.g. fix(editor): keep the caret visible after folding. Fill in the template.
Keep the description short and in plain words. If it doesn’t fit in a few sentences, the PR is probably too big.

​
The template

.github/pull_request_template.md has three sections:

​
How it was verified

This section is required. Include:
  • the commands you actually ran and their results (tests, clippy, pnpm e2e, a smoke test…);
  • what else the change could affect, and how you checked it;
  • visible UI changes: before/after screenshots; multi-step interactions: a recording;
  • backend changes: logs or command output.
Screenshots are not needed for UI that goes away with a removed feature, copy-only changes or non-visual changes; say what you checked instead. A workflow (.github/workflows/pr-check.yml) reads each PR’s description when it is opened or edited. If How it was verified is missing or empty, it comments and adds needs-info; once you fill it in, it removes its comment and the label. It only reads the title and description, never your code.

​
Checks to run

See Unit and E2E tests for details.

​
What CI runs

.github/workflows/ci.yml first classifies the changed files, so a docs-only or frontend-only PR skips the jobs it can’t affect:
  • Rust on macOS, Ubuntu 22.04 and Windows: cargo fmt --check (Linux), clippy with -D warnings, cargo nextest run --workspace, and a check that src/bindings.ts is up to date.
  • Remote server: a static Linux (musl) build of openidea-server.
  • Plugins: format, clippy (host and wasm32-wasip2) and tests of the SDK, the official plugins and the test fixtures; plugin web pages typechecked and tested; plugins/build.sh --check.
  • Cargo deny: cargo deny check (licences, advisories, sources).
  • Frontend: typecheck, lint, format check, knip, tests, build.
  • E2E: pnpm e2e in the Playwright container.
.github/workflows/language-smoke.yml runs the language smoke tests when crates, languages/, fixtures/, the run/debugger features, src/platform/ or smoke/ change.

​
Product decisions

If a change needs a product decision you can’t make (behaviour users would notice, a trade-off between options, scope), ask in the issue and stop rather than guessing. The issue gets needs-decision until a maintainer answers.

​
Plugins

PRs to this repository add or change the official plugins (plugins/official/) and the plugin API. Community plugins live in their authors’ repositories and are listed through l0ng-ai/openidea-plugins. See Publishing.

​
Review and merge

Maintainers review the PR against the rules above: one problem, root cause fixed, focused diff, verification that covers what the change affects. Expect requests to split a PR that does several things. On main, a merged PR’s commit carries its Conventional Commits title and number, e.g. fix(maven): recognize POMs with non-UTF-8 declared encodings (#2495), so write the title as the commit message you want in the history.