Files
openidea/CONTRIBUTING.md
T
l0ng-ai 812d27e8cf feat(plugins): list community plugins from a registry in the marketplace
The marketplace index can now carry plugins of other publishers, published
from their authors' repositories through the l0ng-ai/openidea-plugins
registry.

- `openidea-plugin index` with a key replaces only that publisher's plugins
  (it used to drop every other entry); without a key it indexes each package
  against the publishers the index already lists, checking the key and the
  id prefix instead of only the signature itself.
- `openidea-plugin merge` takes another index's publishers, plugins and
  revocations in place of every publisher but `--keep`; the other index can't
  list or revoke the kept publishers' plugins.
- `openidea-plugin check` accepts a `.oiplugin` file.
- Releases merge the registry's index into plugins-index.json and attach the
  Linux x64 tool; plugins-index.yml refreshes the community plugins in the
  latest release hourly or when the registry signals a change.
- plugins/README.md and CONTRIBUTING.md describe official and community
  plugins.
2026-11-04 17:46:51 +08:00

2.0 KiB

Contributing to OpenIDEA

These rules apply to everyone, and to any coding agent working on their behalf. Project layout, coding rules, commands and checks are in AGENTS.md.

Issues

  • One problem or request per issue. Use the issue forms.
  • Bugs: steps that reproduce the problem from a fresh start. A minimal sample project is the fastest way to get a fix.
  • Features: state the problem and the acceptance criteria. A feature is ready to build once a maintainer labels it planned.
  • Labels track status: needs-info waits on the reporter, needs-decision waits on a maintainer, planned is accepted, needs-acceptance has a fix waiting to be checked.

Pull requests

  • One issue per PR, linked with Closes #123. Feature PRs need a planned issue. Docs, CI and pure refactors may skip the issue.
  • Reproduce the problem first, or write a test that fails before the fix.
  • Fix the cause, and check whether the same cause breaks anything nearby.
  • Keep the diff focused. Unrelated refactors go in their own PR.
  • Title: Conventional Commits, 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.
  • How it was verified is required: the commands you ran and their results, and what else the change could affect. UI changes need before/after screenshots; multi-step interactions need a recording.
  • If a change needs a product decision you can't make, ask in the issue and stop rather than guessing.

Plugins: pull requests here add or change official plugins (plugins/official/) and the plugin API. Community plugins live in their authors' repositories and are listed through l0ng-ai/openidea-plugins; see plugins/README.md § 8.1.

A check on each PR adds needs-info when the issue link or the verification section is missing, and removes it once they're filled in.