## User Feedback Analysis — 2026-04-29 (based on 2026-04-26 to 2026-04-28 inputs) ### Data coverage notes - Primary sources included: Discord daily summaries (Apr 26–28) + one cross-repo engineering status summary (Apr 28). - No direct GitHub issue comment threads for Apr 29 were provided; GitHub signals are inferred from the “overall project summary” (not end-user prose feedback). --- ## 1) Pain Point Categorization (top recurring 5–7) ### 1) Documentation — “Status / roadmap clarity” and update cadence (high frequency, high severity) **What users experienced** - Repeated requests for “where are we at?” style updates: v3 timeline, Milady status, degenAI updates. - On Apr 28, **2 of 3** direct community questions were left unanswered in-channel that day: - “What is milady news?” (unanswered) - “Can we expect some update for $degenai this month?” (unanswered) - Community explicitly flagged the need for **PR planning + business strategy materials** (zadayos, cryptologos_00014), not just code progress. **Most affected users** - Newcomers and token-adjacent community members trying to understand what’s shipping, when, and what’s real vs speculative. --- ### 2) Community — Token-price dominated discussion crowds out product support (high frequency, medium/high severity) **What users experienced** - Apr 27 was “dominated by token price complaints,” including calls for market-making/VC partnerships and posts about losses. - Core devs reported intentionally working in “quieter servers” to avoid price chatter (Apr 28), which reduces visibility for users who only follow the main Discord. **Most affected users** - Builders and support seekers who cannot reliably use the main channel for technical help. - Mods/community ops who must constantly steer conversation + handle scam attempts. --- ### 3) Technical Functionality — Build/install pipeline is “critically blocked” (medium frequency, very high severity) **What users experienced (engineering signal, but user impact is real)** - Dependency modernization (Node 24 / TS6 / Bun 1.3.13 / React 19) is **stalled** due to a missing transitive dependency causing `bun install` failures. - Blocker called out explicitly: **PR elizaos/eliza#7146 must merge** before the dependency update stack can proceed. - Downstream impact: CI/CD in **elizaos/cloud** and **elizaos-plugins/registry** failing to run `bun install` and `tsc`, meaning regressions can slip through. **Most affected users** - Contributors (can’t bootstrap reliably), plugin authors (registry + CI instability), and teams attempting upgrades. --- ### 4) Integration — Broken external resource link (low frequency, medium severity) **What users experienced** - Apr 26: “Milady Play Store link from the GitHub repository is non-functional.” - This is a “dead end” failure during onboarding/validation. **Most affected users** - Mobile-focused users evaluating Milady distribution or attempting installation. --- ### 5) UX/UI — Payment/token utility creates fear of friction; users want “pay with anything” (medium frequency, medium severity) **What users experienced** - Apr 26 discussion highlights a core UX risk: forcing token utility may add friction. Team stated preference: accept any payment, then buy back tokens. - Apr 28 introduced a conflicting perception: **$ELIZA is default payment in x402 for elizaOS/Milady services**. That triggered clarification questions (“Does this mean we can bill x402 services with $ELIZA?”) which needed explicit confirmation. **Most affected users** - Paying customers and integrators who need predictable billing flows and minimal wallet/token steps. --- ### 6) Community/Security — Scammers in Discord; moderation load (recurring, high severity when it happens) **What users experienced** - Apr 27 & Apr 28: scammer identified and removed/banned by odilitime (repeat occurrence across days). - Indicates ongoing risk to users, especially those drawn in via token discussions. **Most affected users** - Newcomers and traders; moderators handling repetitive enforcement. --- ## 2) Usage Pattern Analysis (actual vs intended) ### Observed “actual usage” 1. **Infra + monetization-first building**: Users are gravitating to *x402 pay-per-call services* and “agent commerce” patterns (token utility, paid routes, marketplace-like proposals). 2. **Production workflow builders joining the community**: e.g., Kevin111s seeking a US-based partner to handle client communication while he builds “production-ready AI workflows and backend architecture.” 3. **Automation/orchestration is becoming mainstream**: Engineering work highlights n8n plugin expansion (TriggerContext, RuntimeContextProvider), conversation routing propagation, and workflow generation UX. This suggests users increasingly treat elizaOS as an automation runtime, not “just a chat agent.” ### Mismatches vs intended usage - The main Discord appears to function as a *market sentiment channel* as much as (or more than) a *builder support channel*, undermining onboarding and technical adoption. ### Emerging / unexpected use cases to support - **Agent-to-agent commerce + paid API calls** (x402) as a default pattern. - **Client-facing “AI workflow agency”** model (builders needing sales/PM counterparts). - **Mobile distribution / consumer app adoption** (Milady Play Store link issue signals real user attempts). ### Feature requests that align with usage patterns - Clearer, user-facing explanation of **x402 billing with $ELIZA** and non-token payment alternatives. - More structured “what shipped / what’s next” updates (v3, Milady, degenAI). --- ## 3) Implementation Opportunities (solutions per major pain point) ### Pain Point A: Status/roadmap clarity + update cadence (Documentation) **High impact / low-medium difficulty** 1. **Weekly “Shipping Update” post with a fixed template** (Discord + GitHub Discussions): - Sections: “Shipped last week”, “In progress”, “Blocked”, “Next up (7 days)”, “FAQs answered”. - Include explicit answers to recurring questions (Milady news, degenAI timeline). - *Comparable approach:* Kubernetes weekly community updates + release burndown notes; Home Assistant “Release Notes + What’s Next”. 2. **Single “Source of Truth” status page** (even a Markdown page in docs): - v3 status, Milady status, degenAI status, Cloud availability, known issues (e.g., build blocker). - *Comparable approach:* Next.js “Release status” notes and RFC tracking; Rust’s public tracking issues. 3. **Auto-capture unanswered Discord questions into a triage list** - Bot tags questions + if no staff reply in 24h, create an “Unanswered FAQ” entry. - *Comparable approach:* Discord helpers + GitHub issue forms used by many OSS projects (e.g., Vite, Supabase) to channel support questions. --- ### Pain Point B: Token-price chatter drowning product discussion (Community) **High impact / low difficulty** 1. **Split channels with enforced routing** - “#market-talk” (token price) vs “#builders-help” (strictly technical) with mod enforcement. - Add an auto-reply in technical channels when messages contain price keywords, redirecting users. 2. **Pinned “How to talk about token utility without blocking UX” explainer** - Summarize: accept multiple payment methods vs default token in x402; what is required vs optional. 3. **Office hours in the main server** - 30 minutes 2×/week for roadmap Q&A; reduces repeated “any updates?” churn. - *Comparable approach:* OpenAI Cookbook community hours; LangChain community calls. --- ### Pain Point C: Bun install / dependency modernization blocker (Technical Functionality) **Very high impact / medium-high difficulty (but urgent)** 1. **Unblock-first policy + visible “Stop-the-line” label** - Treat PR #7146 (or equivalent) as a release-blocker with priority routing. - Require merging unblockers before stacking modernization PRs. - *Comparable approach:* Chromium “sheriff” model; many monorepos use “buildcop” rotations. 2. **Add a “known-good toolchain” lock + fast failure messaging** - Publish a minimal bootstrap matrix: OS × Node × Bun versions that are guaranteed today. - If `bun install` fails due to known missing transitive deps, print a targeted message with a link to the tracking issue. 3. **CI gating across dependent repos** - If elizaos/eliza is blocked, prevent silent green merges elsewhere by adding a “shared install sanity” workflow (or a required status check) used by cloud + registry. - *Comparable approach:* Bazel/Rust workspace-wide presubmit checks. --- ### Pain Point D: Broken Milady Play Store link (Integration) **Medium impact / very low difficulty** 1. **Fix the link + add a link checker in docs CI** - Run nightly link validation for docs + key README links. - *Comparable approach:* Docusaurus/Mintlify link-check pipelines. 2. **Add a “Distribution” section in Milady docs** - Include Play Store, direct APK (if applicable), versioning, and troubleshooting. --- ### Pain Point E: Payment UX ambiguity (UX/UI + Integration) **High impact / medium difficulty** 1. **Explicit billing UX in UI + docs** - “Pay with $ELIZA (x402 default)” vs “Pay with card/USDC/etc (if supported)” and what happens behind the scenes. 2. **A single “Payments & x402” guide with examples** - “How to bill x402 services with $ELIZA” (confirmed by odilitime) + code snippets and failure modes. - *Comparable approach:* Stripe’s “Payments 101” plus copy-paste examples; Cloudflare Workers billing docs. 3. **Reduce cognitive overhead: default to “works without token” for onboarding** - If token is default in some contexts, provide an automatic fallback (where product strategy allows) or a clear “why token is required here” explanation. --- ### Pain Point F: Scammers and safety (Community) **High impact / low-medium difficulty** 1. **Harden onboarding permissions** - Rate limits for new accounts, restricted link posting, and “first-message approval” in sensitive channels. 2. **Security banner + reporting flow** - Pinned “How to verify staff / avoid scams” message; one-click report to mods. - *Comparable approach:* Large crypto OSS communities use Collab.Land verification + restricted DMs guidelines. --- ## 4) Communication Gaps (expectations vs reality) ### Gap 1: “Quiet dev servers” vs community expectation of transparency - Devs are optimizing for focus by moving work elsewhere; community experiences this as “lack of updates” in the main server. **Fix:** publish short, frequent broadcast updates back into the main channel (even if work happens elsewhere). ### Gap 2: Token utility messaging is mixed - Apr 26: “accept any payment method, buy back tokens” (low friction). - Apr 28: “$ELIZA default payment in x402” (sounds like token-first). **Fix:** one canonical statement: what is default vs what is required vs what is optional; include examples. ### Gap 3: Unanswered “product status” questions signal missing onboarding/FAQ - Milady news + degenAI timeline questions recurring and sometimes unanswered. **Fix:** lightweight FAQ automation and a pinned status post. --- ## 5) Community Engagement Insights ### Power users / high-leverage participants (and needs) - **odilitime**: active moderation (scammer bans), token utility clarifications; needs better tooling for moderation + FAQ triage. - **shawmakesmagic (Shaw)**: primary status source for v3/Milady; needs a low-overhead broadcast mechanism to avoid repeated manual updates. - **zadayos / cryptologos_00014**: pushing for PR/business strategy messaging; can be recruited into a “Comms working group” to draft weekly updates. - **kevin111s**: signals a builder-to-business bridge need (US-based client-facing partner). This is an opportunity to formalize a partner directory. ### Newcomer recurring questions indicating onboarding friction - “What’s the status of v3 / Milady?” - “What’s the utility of $ELIZA in practice?” - “Can I bill x402 with $ELIZA?” (needed explicit confirmation) - “Where are degenAI updates?” ### Converting passive users into contributors 1. Create a **“Good first issue: docs/status”** label and assign community volunteers to update the status page weekly. 2. Offer a **“partner matching thread”** (builders who want business counterparts) to channel requests like Kevin111s’ into structured collaboration. 3. Publish a **moderation + safety playbook** and invite trusted helpers into a rotation. --- ## 6) Feedback Collection Improvements ### Current effectiveness - Discord is high-volume but low-structure; price discussion distorts signal-to-noise. - GitHub has rich engineering signal, but user-impact feedback is not being collected in a standardized way in these excerpts. ### Improvements 1. **Structured weekly feedback form** - 5 questions max (biggest blocker, what you tried to do, what failed, logs/link, desired outcome). - Post results back weekly (“Top 3 issues this week”). 2. **Discord “/feedback” bot command** - Converts a message into a GitHub Discussion/Issue template automatically (with labels: docs/ux/bug). 3. **Underrepresented segments to target** - **Non-crypto builders** (may avoid Discord due to token noise) - **Mobile end-users** (Milady install path) - **Plugin authors** affected by Bun/CI breakage (need a dedicated channel or office hour) --- ## Prioritized High-Impact Actions (next 1–2 weeks) 1. **Publish a pinned, weekly “Shipping Update” + single status page** (v3, Milady, degenAI, Cloud, known blockers). 2. **Unblock the Bun install / dependency modernization chain** by prioritizing the missing transitive dependency fix (PR #7146) and adding toolchain/CI guardrails. 3. **Re-structure Discord to protect builder support** (separate token talk; enforce channel routing; add office hours). 4. **Fix Milady Play Store link + add automated link checking** to prevent repeat onboarding dead-ends. 5. **Clarify payments/x402/token utility in one canonical doc** (default vs optional, “pay with anything” stance, concrete billing examples including $ELIZA confirmation).