Skip to content

TODO.md

Latest commit

 

History

History
93 lines (74 loc) · 4.91 KB

TODO.md

File metadata and controls

93 lines (74 loc) · 4.91 KB

TODO

Working backlog of things the project needs to reach baseline open-source completeness. Grouped by how much work each item is — pick whatever is in front of you.

Quick fills (minutes each)

These are placeholder TODOs embedded in existing files. Do a repo-wide search for the TODO markers to find them.

  • CODE_OF_CONDUCT.md — replace <TODO: insert contact email> with a real address (e.g. info@datasketch.co or a dedicated conduct@... mailbox that someone actually monitors).
  • PROJECT_CHARTER.md — fill in the "Community and governance" section with the current maintainers (GitHub handles or names) and a short note on how decisions are made today.
  • PROJECT_CHARTER.md — revisit the trademark section if/when mtchat gets enough traction for it to matter; until then, leaving the TODO is fine.

Project documentation

  • TESTING.md — a short formal test plan at the repo root covering:
    • Strategy (what we test and why)
    • Layout (where tests live, glob patterns, naming)
    • Sample test cases table with a "done" column — use the same format as the "Sample test cases" section of mtchat's phased roadmap
    • Data structures under test (the shapes from lib/store.ts and lib/retrieval.ts)
    • How to run tests locally
    • Pull request workflow — links to CONTRIBUTING.md
    • Coverage target (start at 15%, raise over time)
  • .github/PULL_REQUEST_TEMPLATE.md — short template with sections: What this changes, Type of change (bug / feature / docs / refactor / test), How to verify, Checklist (fmt, lint, test, updated docs).
  • .github/ISSUE_TEMPLATE/bug_report.md and feature_request.md — standard GitHub templates. Copy from any well-run OSS repo.

Tests (Phase 0 coverage)

  • tests/retrieval.test.ts — cover match() edge cases: empty query, no entries, exact question match (score 1.0), partial match above threshold, partial match below threshold (returns suggestions instead), all stop-words query, query with punctuation, topN limit respected.
  • tests/store.test.ts — CRUD round-trip on InMemoryQAStore: create → list → get → update → delete → get returns null. Plus: replaceAll preserves insertion order, ulid generation is unique.
  • Aim for ≥ 15% line coverage out of the gate. With only lib/* and routes/api/* in scope, the two tests above should comfortably hit that floor.

Continuous integration

  • .github/workflows/ci.yml — GitHub Actions workflow that runs on push + PR to main:
    • deno fmt --check
    • deno lint
    • deno task test (all tests)
    • Optionally: deno test --coverage=coverage + upload the coverage/ dir as a workflow artifact
    • Cancel in-progress runs on new pushes to the same branch (standard concurrency block)
  • CI badge in README.md — ![CI](https://github.com/datasketch/mtchat/actions/workflows/ci.yml/badge.svg) at the top of the file next to the license.
  • Code coverage threshold — once the tests land, either (a) add a deno test --coverage step that fails if coverage drops below 15%, or (b) use a lightweight post-processing script that parses the coverage output and exits non-zero on miss. The Deno coverage CLI doesn't enforce thresholds natively, so a small wrapper script is fine.

GitHub repository settings

  • Enable Issues under Settings → Features → Issues. File a handful of seed issues for the ⚠️ TODO items in TESTING.md and the upcoming roadmap phases so the backlog is visible.
  • Enable Discussions (optional but recommended for OSS projects — low-cost way to triage vague questions before they become issues).
  • Branch protection on main: require PRs, require CI to pass, disallow force pushes. Don't require reviews yet while the project is still single-maintainer.

Documentation site

  • Decide how to present docs:

    • Option A: treat the repo itself as the docs site — README + ROADMAP + CONTRIBUTING + TESTING are enough for now. Cheapest and most honest for an early-stage project. This is fine for v0.1.
    • Option B: GitHub Pages serving the existing markdown files — zero-code, auto-generates a site from docs/ or the repo root. Free, no build step.
    • Option C: MkDocs / Docusaurus / Astro Starlight — real docs site, nicer browsing, requires a build pipeline. Worth it once the doc surface grows beyond what fits in a single README.

    Recommendation: pick Option A for now and revisit when there are more than 3–4 separate docs to navigate.

When all of the above is done

  • Fill in the Q1/Q2 compliance checklist with the actual repo links.
  • Drop this TODO.md once everything is checked off, or convert the remaining items into GitHub Issues and delete the file.

Last updated 2026-04-08