docs/roadmap.org

Everything in the original plan is built, tested end-to-end against real git/ssh/sshd/gpg, and running in production at gitbay.org: the SSH control plane (usable from bare OpenSSH, enforced by test), git over SSH/HTTPS/git://, signature verification with six states and epoch caching, protected branches and require_signed_commits (push-time and merge-time), issues, merge requests with four merge strategies, orgs with membership-derived access, rename/transfer, repo import, invite and open registration with SMTP verification, ACME TLS, the read-only and accounts web modes, the JSON API fronting the whole command registry, signed webhooks with retries and dead-lettering, restore-tested backups, the gitbay CLI, and docs. The instance hosts 65 repositories including this one, and its own development already runs through its issues and merge requests.

What it is today: an excellent forge for its author and for CLI-native individuals. What it is not yet: a forge a GitHub-habituated team would stay on, or a project outsiders can easily run themselves.

Goal: a second contributor works here for a week and misses nothing they would act on. These compound: statuses gate merges, notifications close the feedback loop, inline comments make review real.

• #22 deploy keys — smallest item, unblocks CI checkout; the scope already exists in the policy layer
• #1 commit statuses API and MR check display
• #3 email notifications for issue/MR activity
• #2 inline review comments on MR diffs
• #19 required approvals and CODEOWNERS (builds on #1 and #2)

Goal: the site looks and reads like something you would recommend. Mostly web-layer; descriptions and profiles already landed as the first step.

• #10 design revamp (umbrella: tokens, typography, identity, mobile)
• #6 cross-references (#N) and @mentions
• #23 archived repos and topics
• #24 blame view
• #7 search (repo-name filter first; code search later)
• #20 milestones and issue templates

Goal: someone who is not the author runs an instance and moves their work to it.

• #26 release engineering: versioned builds, go-install vanity imports, Homebrew/deb — the adoption gate for everything below
• #27 repository maintenance (admin gc/stats, scheduled repack)
• #8 releases (notes + assets; also hosts gitbay's own binaries)
• #17 issue/PR history import from GitHub
• #18 push/pull mirroring for gradual migration
• #14 audit logging and multi-user hardening
• #9 web signup for open/invite instances

Bigger bets, each valuable independently; order by appetite.

• #13 CI/CD via external runners (after #1; the forge never executes repository content)
• #16 Git LFS
• #15 static page hosting (needs the separate-origin decision)
• #11 iOS app (hutch-based) and #12 Android
• #21 teams within orgs
• #25 wikis

Recorded so their absence reads as a decision, not an oversight:

• container/package registry — scope creep away from "forge"; external registries integrate via CI
• email patch flow — revisit only if sourcehut-style demand appears
• federation (ForgeFed) and Postgres — no current need at this scale

• gitbay.org will eventually be open to all. (Decided 2026-08-24.) Sequencing consequence: before flipping registration = "open", the instance needs #14 (audit log, rate limiting, quotas), #9 (web signup), an SMTP relay configured for verification mail, and enough of Phase 1 that new users get a credible product. Interim step: invite mode for early collaborators as soon as [mail] is configured.
• Versioning: semver, starting at v0.1.0 on the current state. 0.x signals moving surfaces; protocol_version increments only on breaking envelope/command changes and is otherwise decoupled from release numbers. v1.0.0 when Phase 1 and #26 land. Tags are annotated and signed.
• Second contributors: invite mode is the on-ramp (their keys and verified emails make signed-main enforceable for them too). A CONTRIBUTING file states the workflow: fork on gitbay.org, MR with signed commits, go test ./... green, review required once #19 exists. No CLA — 0BSD needs none; sign-off optional.