Contribute to Superset
Take the user from "I want to fix/build X in Superset" to a merge-ready PR that follows the repo's rules. If the checked-out repo has CONTRIBUTING.md / DEVELOPMENT.md / AGENTS.md, those files are authoritative — read them and prefer them over this summary.
1. Scope first
- Bug fixes, docs, small improvements → straight to a PR, no issue needed
- New features or larger changes → open an issue first at https://github.com/superset-sh/superset/issues/new/choose to agree on the approach before building
- Questions → Superset Discord, not an issue
2. Set up
gh auth status, then fork and clone:gh repo fork superset-sh/superset --clone(or add a fork remote to an existing clone)- Best experience: add the clone as a project in the Superset app and create a workspace per change — contributions develop inside managed worktrees
- In the new workspace/worktree, run
./.superset/setup.local.shonce (configures per-workspace ports, app identity, local services, and a seeded dev account — no external credentials needed), thenbun run dev - Bun only — never npm/yarn/pnpm. Read the root
AGENTS.mdand follow it.
3. Make it merge-ready
- Branch from
main; one change per PR — unrelated finds become a second PR - Before pushing:
bun run lint:fix, then verifybun run lintexits clean (CI fails on warnings too),bun run typecheck,bun run test - PR title must be a conventional commit (
feat(desktop): ...,fix(web): ...) — PRs are squash-merged with the title as the commit subject - Include proof it works: screenshots or recordings for anything user-visible, before/after for fixes. The dev desktop app exposes CDP for clean captures — see "Capturing screenshots via CDP" in CONTRIBUTING.md
- Check "Allow edits from maintainers" and link the issue for non-trivial changes
4. Open it
gh pr create against superset-sh/superset main, fill in the PR template honestly (what you ran, what you clicked, what's covered by tests), and report the PR URL back to the user.