Contributing

PRs and issues are welcome.

Casual Office is solo work, but it's open by intention — file an issue, send a patch, or fork freely. Each project has its own contribution guide; the rest of this page summarises the shared rules.

Per-project guides

The repo-level guides override anything here when they conflict.

Shared rules

  1. Native formats are the source of truth. Round-trip fidelity is sacred — never silently drop OOXML structures, never shape an export-only model. If a feature can't survive a round-trip, gate it behind an opt-in flag and document the gap.
  2. Stateless backends. The real-time service holds in- memory Y.Doc state for live sessions only; no DB, no on-disk update log. Persistence is delegated to a pluggable host.
  3. OSS dependencies, no Pro pinning. Casual Sheets is built on Univer OSS — we never reach for Univer's commercial layer for charts / pivots / print. Build on OSS or defer.
  4. Tests gate every push. Casual Sheets ships with 357 Playwright e2e tests; Casual Editor runs a per-tag round-trip audit + a three-way fidelity harness vs LibreOffice and OnlyOffice. PRs add the test that locks the new behaviour.
  5. Polished UX from the first commit. "We'll polish it later" is not how shipping works here. Match Excel / Word interaction conventions for every feature.
  6. Conventional commit messages. feat(scope): …, fix(scope): …, docs(scope): …, etc. The body explains the why, not the what.

Filing a good issue

The shape that gets fixed fastest:

  • The exact version (Docker tag or main commit SHA).
  • A minimal reproduction — a small file, a numbered click sequence, the observed vs expected result.
  • Browser + OS, if it's UI-shaped.
  • Console + network logs if relevant.
Touching co-edit, fidelity, or formula behaviour? Open a discussion first — the surface area is large and the design decisions are load-bearing. Most other contributions can go straight to a PR.