diff options
Diffstat (limited to 'ROADMAP.md')
| -rw-r--r-- | ROADMAP.md | 95 |
1 files changed, 19 insertions, 76 deletions
@@ -1,23 +1,5 @@ # Hutch Roadmap -## Positioning - -Hutch is already beyond a minimal v1. The core SourceHut surfaces are present: - -- Authentication with PAT flow -- Git repositories -- Mercurial repositories -- Trackers and tickets -- Builds -- Sharing -- Core settings and app metadata - -The main risk now is not lack of scope. The main risk is shipping too late with -an increasingly broad surface area and not enough polish. - -This roadmap treats the current app as a real 1.0 candidate and shifts the -focus from feature expansion to launch readiness. - ## Version 1.0 Goal Ship a stable SourceHut mobile client with strong support for the most active @@ -26,10 +8,12 @@ day-to-day workflows: - Browse and manage repositories - Browse and manage tickets - Browse and manage builds -- Support both git and hg repositories +- Support both Git and Mercurial repositories - Provide dependable sharing and navigation -Version 1.0 does not need to cover every sr.ht service. +Version 1.0 does not need to cover every SourceHut service. + +--- ## Release Strategy @@ -50,25 +34,25 @@ Focus on quality, not new surface area. - Build submission - Verify build retry and edit/resubmit flows - Verify repository sharing links for: - - repository - - commit - - file + - Repository + - Commit + - File - Verify sharing links for: - - build - - tracker - - ticket - - profile + - Build + - Tracker + - Ticket + - Profile - Review empty/loading/error states across all main tabs - Remove any leftover temporary debug logging - Audit device-only issues: - Xcode attach quirks - - on-device auth/cache behavior + - On-device auth/cache behavior - WebView rendering performance #### UI/UX polish checklist - Tighten wording and error messages across create/edit flows -- Confirm summary tabs feel consistent across git and hg +- Confirm summary tabs feel consistent across Git and Mercurial - Confirm toolbar actions are visible and non-duplicated - Confirm README rendering is smooth on large repositories - Confirm forms behave well on iPhone-sized screens @@ -82,6 +66,8 @@ Focus on quality, not new surface area. - Finalize support URL / project URL - Decide whether TestFlight comes before public launch +--- + ### Phase 2: Version 1.1 Add one compact new service surface after launch. @@ -99,6 +85,8 @@ Add one compact new service surface after launch. - paste.sr.ht is relatively self-contained - lists.sr.ht is valuable, but broader in UI and data model scope +--- + ### Phase 3: Version 1.2+ Expand only after the v1 core is stable in the wild. @@ -106,50 +94,5 @@ Expand only after the v1 core is stable in the wild. - lists.sr.ht tab - paste.sr.ht creation/editing polish - pages.sr.ht management -- broader deep-link/share coverage -- workflow refinements for builds and tickets - -## What Counts As “Done Enough” For 1.0 - -Hutch is ready for 1.0 when: - -- The main flows work reliably on real devices -- Errors are understandable -- The app does not feel inconsistent across git/hg/builds/tickets -- The missing services feel like roadmap items, not broken gaps - -That means `lists.sr.ht`, `paste.sr.ht`, and `pages.sr.ht` are not blockers for -the first release. - -## Non-Blockers For 1.0 - -These should not delay launch: - -- Donation page / IAP -- Broad service parity across all SourceHut products -- Public repo discovery equivalent to `sr.ht/projects` -- Advanced creation workflows beyond what the public APIs cleanly support - -## Open Product Questions - -These are worth deciding before or shortly after launch: - -- Should the app be positioned as “SourceHut client” or “SourceHut for git/hg, - tickets, and builds” in App Store messaging? -- Should exact repository lookup live in Repositories search, a dedicated sheet, - or both? -- Should `paste.sr.ht` or `lists.sr.ht` be the first new post-launch tab? -- Is TestFlight feedback needed before calling the first public build 1.0? - -## Recommended Next Step - -Do not add another major service right away. - -Instead: - -1. Run a release-focused polish pass -2. Build a strict 1.0 checklist from the current app -3. Ship to TestFlight or release publicly -4. Use `ROADMAP.md` and `TODO.md` separately: - - `ROADMAP.md` for release strategy - - `TODO.md` for concrete implementation backlog +- Broader deep-link/share coverage +- Workflow refinements for builds and tickets |