Summary
Add a first-class open-source contribution guide so new contributors can clone the repo, get a working local environment (including a realistic or minimal database), and understand expectations before opening a PR.
Today, onboarding is spread across README.md and CLAUDE.md. There is no CONTRIBUTING.md, and there is no official sample/seed database or documented path to populate data for local UI testing.
Goals
-
CONTRIBUTING.md (or docs/contributing.md + link from README) covering:
- Fork / branch / PR conventions (link to any existing style if applicable).
- How to start the project end-to-end: Bun install,
.env.local, bun run dev, expected URL.
- Database setup: create DB,
bun run db:push (and when to use db:generate), relationship to Drizzle vs SQLKit (high level).
- Environment variables: what is strictly required to boot
bun run dev vs optional (analytics/ClickHouse, Inngest, etc.) — today src/env.ts validates many vars; document minimal viable .env.local or track a follow-up to relax dev defaults.
- Optional services: Meilisearch, WorkOS vs GitHub OAuth, R2/Cloudinary, Pusher/Soketi — what breaks if omitted and acceptable stubs for local-only hacking.
- Quality bar: no automated tests;
bun run play, bun run lint, bun run build as appropriate before PR.
-
Sample database story (pick one or combine; document the chosen approach):
- Option A — Seed script: e.g.
bun run db:seed (or documented play recipe) that inserts minimal users, one published article, tags, etc., with obvious fake emails and handles.
- Option B — SQL fixture: checked-in anonymized dump or
migrations/seed.sql applied after schema push, with clear warnings (never production data).
- Option C — Docker Compose:
postgres (+ optionally meilisearch) with documented DATABASE_URL and one-command up; seed optional.
- Option D — Document “empty DB”: if we stay empty-only, explain how to register/login locally (WorkOS/GitHub) to create first user and content.
-
Cross-links: README “Contributing” section should point to the new guide; mention migrations/create-tables.sql / Drizzle only if it helps (avoid duplication).
Acceptance criteria
Context
- Schema push:
bun run db:push (see README).
- Resource analytics / ClickHouse: optional; see
docs/resource-analytics-plan.md and migrations/clickhouse-schema.sql — not required for core blogging flows.
Labels suggestion
documentation, good first issue (for the writing task), or enhancement for maintainers to scope seed vs docs-only.
Summary
Add a first-class open-source contribution guide so new contributors can clone the repo, get a working local environment (including a realistic or minimal database), and understand expectations before opening a PR.
Today, onboarding is spread across README.md and CLAUDE.md. There is no
CONTRIBUTING.md, and there is no official sample/seed database or documented path to populate data for local UI testing.Goals
CONTRIBUTING.md(ordocs/contributing.md+ link from README) covering:.env.local,bun run dev, expected URL.bun run db:push(and when to usedb:generate), relationship to Drizzle vs SQLKit (high level).bun run devvs optional (analytics/ClickHouse, Inngest, etc.) — todaysrc/env.tsvalidates many vars; document minimal viable.env.localor track a follow-up to relax dev defaults.bun run play,bun run lint,bun run buildas appropriate before PR.Sample database story (pick one or combine; document the chosen approach):
bun run db:seed(or documentedplayrecipe) that inserts minimal users, one published article, tags, etc., with obvious fake emails and handles.migrations/seed.sqlapplied after schema push, with clear warnings (never production data).postgres(+ optionallymeilisearch) with documentedDATABASE_URLand one-command up; seed optional.Cross-links: README “Contributing” section should point to the new guide; mention migrations/create-tables.sql / Drizzle only if it helps (avoid duplication).
Acceptance criteria
.env.exampleif we add one.Context
bun run db:push(see README).docs/resource-analytics-plan.mdandmigrations/clickhouse-schema.sql— not required for core blogging flows.Labels suggestion
documentation,good first issue(for the writing task), orenhancementfor maintainers to scope seed vs docs-only.