Strategic Finding
Type: adoption-blocker (measurement)
Horizon: near-term
Dakota is in public alpha with real user feedback arriving daily (audio, LUKS keyboard layout, WiFi regdb, GVFS playback — 20 open issues, most user-filed). The feedback loop (ujust report/confirm/verify) is the product's core differentiator. But the project currently has no way to measure the Dakota install base: the weekly countme client (PR #807) has sat in 4-review as a draft since 2026-07-01 (37 days), currently dirty, with four requested reviewers.
Rationale
Without even a weekly count ping, the project cannot answer basic adoption questions that drive prioritization:
- Is the Dakota alpha install base growing, flat, or churning?
- Did the ISO download convert to installs?
- Which stream (
:stable vs :next/:btw) has users?
This matters more for Dakota than for a mature product: alpha positioning decisions (how much to invest in the feedback loop vs. install path hardening vs. aarch64) are being made right now, blind. The privacy-preserving design (weekly-salted HMAC of machine-id, DynamicUser, no persistent identifier) is already done — the blocker is review bandwidth, not engineering.
Proposed Next Step
Ask one of the four requested reviewers (or a maintainer) to prioritize the #807 review this week; if the draft state is the blocker, identify the remaining work item in the PR so an agent can pick it up. Interim fallback: publish ISO download counts from the CDN as a stopgap metric.
Status 2026-08-08 (strategist re-verify)
- common#807 still draft, 0 review activity since hanthor's CHANGES_REQUESTED on 2026-07-31 (8 days ago). 44 days total in review.
- Dakota stable cadence has now slipped to 8 days (
stable-20260731 newest) with Publish Smoke + Boot Test aarch64 + Execute Release all failing on testing today — so even the existing adoption proxy (stable cadence) is degrading while the telemetry that would measure adoption remains unmerged.
Filed by strategist agent (ACMM L5 — hold-gated mode)
Strategic Finding
Type: adoption-blocker (measurement)
Horizon: near-term
Dakota is in public alpha with real user feedback arriving daily (audio, LUKS keyboard layout, WiFi regdb, GVFS playback — 20 open issues, most user-filed). The feedback loop (
ujust report/confirm/verify) is the product's core differentiator. But the project currently has no way to measure the Dakota install base: the weekly countme client (PR #807) has sat in4-reviewas a draft since 2026-07-01 (37 days), currentlydirty, with four requested reviewers.Rationale
Without even a weekly count ping, the project cannot answer basic adoption questions that drive prioritization:
:stablevs:next/:btw) has users?This matters more for Dakota than for a mature product: alpha positioning decisions (how much to invest in the feedback loop vs. install path hardening vs. aarch64) are being made right now, blind. The privacy-preserving design (weekly-salted HMAC of machine-id, DynamicUser, no persistent identifier) is already done — the blocker is review bandwidth, not engineering.
Proposed Next Step
Ask one of the four requested reviewers (or a maintainer) to prioritize the #807 review this week; if the draft state is the blocker, identify the remaining work item in the PR so an agent can pick it up. Interim fallback: publish ISO download counts from the CDN as a stopgap metric.
Status 2026-08-08 (strategist re-verify)
stable-20260731newest) with Publish Smoke + Boot Test aarch64 + Execute Release all failing ontestingtoday — so even the existing adoption proxy (stable cadence) is degrading while the telemetry that would measure adoption remains unmerged.Filed by strategist agent (ACMM L5 — hold-gated mode)