Contributing

How to report a bug, improve the documentation or send a change to OpenFrame, with the checks every change runs and the rules for AI-assisted work.

OpenFrame is built in the open at gAlexander77/openframe, and issues and pull requests there are the way in. This page summarizes the repository's CONTRIBUTING.md; when they differ, that file wins.

Ways to help

  • Report a bug you can reproduce, with the app revision, your OS, desktop or browser, the steps, what you expected and what happened. Open an issue.
  • Describe a usability problem in terms of the editing task you were doing; a small screenshot or sample project helps.
  • Improve documentation, accessibility, keyboard workflows, format support, tests or existing features. Read the roadmap before a large change.

Use media you can share. Remove credentials, MCP tokens, private footage and local paths from reports. For security-sensitive reports, contact the owner privately while a public reporting channel is being prepared.

Before changing code

Read AGENTS.md, CLAUDE.md, the conventions, the architecture and the handoff; the documentation index links every decision and research note. Look at git status, recent history and existing worktrees, and coordinate with work already under way.

Features land on desktop first. Keep platform differences behind src/platform/, and do not add a server or an upload step as an incidental choice: OpenFrame runs on the user's hardware.

Develop and check

The editor is in openframe-application/ and the site in openframe-website/; docs/ at the root serves both. Run every command below in openframe-application/.

Run the desktop app
npm ci
npm run tauri dev

Before proposing a change, run the checks (just check runs them all). CI runs the same gates when the maintainer starts it, so run them yourself:

The checks
npm run build
npm test
cargo fmt --check --manifest-path src-tauri/Cargo.toml
cargo clippy --manifest-path src-tauri/Cargo.toml --all-targets -- -D warnings
cargo test --manifest-path src-tauri/Cargo.toml

Then try the change in the running product, not only in tests. Desktop changes need desktop checks: a browser drive does not prove native dialogs, paths, FFmpeg or the release security policy. Driving the app explains how agents and scripts drive it.

Send a change

Keep it focused, and explain the problem, the result, the tradeoffs and how you checked it. Update the feature docs for shipped behavior, the roadmap for plans, an architecture decision record for a non-obvious choice, and the history for lessons the next contributor should not have to learn again.

AI-assisted contributions

Claude Code and Codex were the first development tools, and other tools are welcome. Say when AI helped substantially, and keep the useful reasoning and evidence in the docs, not private prompts or raw session logs. You are responsible for understanding the change and for real evidence: never report an unrun test or a guessed result as a pass.

License

Contributions are offered under GPL-3.0-only, the project's license. Submit only work you are entitled to contribute, keep existing notices, and explain a new dependency's purpose and license before adding it.