## User Feedback Analysis — 2026-02-26 (based on aggregated signals through 2026-02-25)

### Data snapshot used
- Discord daily summaries: 2026-02-23, 2026-02-24, 2026-02-25
- GitHub activity (month-to-date window shown): **38 PRs (18 merged), 41 new issues, 35 active contributors**
- Notable GitHub issues referenced in feedback: **#6486 (duplicate URL processing), #6490 (custom OpenAI endpoint), #6443 (payment infrastructure plugin)**

---

## 1) Pain Point Categorization (top recurring friction areas)

### 1) Technical Functionality — **Versioning / branch integrity confusion (high severity)**
**What users experienced**
- A critical repo state issue: the `develop` branch unexpectedly contained **2.0.0 code instead of 1.x**, and maintainers reported it could not be traced via normal PR/commit history (“unfixable” through conventional means).
- Mitigation was to create a separate **`v2-develop` branch** to preserve 1.x for users still transitioning.

**Why it matters**
- This is a trust-breaking failure mode: users can’t reliably target a stable branch, and downstream plugin/app teams can’t pin expectations.

**Frequency proxy**
- While this was discussed primarily in core channels, it dominated the technical discussion highlights for 2026-02-25 and triggered immediate workflow changes (branch split), indicating high severity even if not high volume.

---

### 2) Integration — **GitHub ↔ Linear bidirectional sync causing issue-tracking “mess” (high severity)**
**What users experienced**
- Confirmation that **Linear was synced bidirectionally with GitHub**, and this created a cleanup burden and confusion about canonical status.

**Why it matters**
- Issue duplication, state drift, and broken triage loops raise contributor overhead and slow responses—especially costly during a multi-product push (Milady, Babylon, App, etc.).

**Frequency proxy**
- Mentioned as a distinct operational blocker in the same window as the branch incident; both point to “source of truth” problems in release + tracking.

---

### 3) Documentation / Communication — **Unclear timelines and “what’s shipping when” (medium-high severity)**
**What users asked (unanswered in Discord)**
- “When will new AI news be released?”
- “When is the Babylon release?”

**Why it matters**
- The org is visibly shifting to revenue-focused shipping (Babylon/Hyperscape/Milady), so timeline ambiguity increases speculation and repeated questions.

**Frequency proxy**
- At least **2 distinct timeline questions** appeared in a quiet day, suggesting this is a recurring FAQ even when overall chat volume is low.

---

### 4) Community / UX — **Access control and role/room permission friction (medium severity, recurring)**
**What users experienced**
- Multiple requests for **milady room** access handled manually.
- A role assignment/permissions issue where “core dev” role couldn’t be assigned as expected; access required manual channel additions before resolving.

**Why it matters**
- Manual gating doesn’t scale; it delays onboarding contributors and makes “who can see what” inconsistent.

**Frequency proxy**
- Across 2026-02-24 to 2026-02-25, access requests appeared multiple times (at least **3 separate access/role events**: shad0w role upgrade + Bill Ding + ElizaBAO).

---

### 5) Performance / Cost — **Token/cost blowups and duplicated work (high severity when triggered)**
**What users reported**
- GitHub issue **#6486**: sending a message containing a URL triggers **duplicate LLM calls** (processed as both text and attachment), doubling cost and producing duplicated output.
- Core-dev discussion also touched token usage problems stemming from “recent messages and reflections collecting excessive data.”

**Why it matters**
- Direct cost + UX degradation; also undermines confidence in production readiness for webapp/cloud chat.

**Frequency proxy**
- At least **2 separate cost/token concerns** surfaced (duplicate URL processing + reflection/message bloat discussion).

---

### 6) Integration — **Provider compatibility gaps (medium severity, high leverage)**
**What users requested**
- GitHub issue **#6490**: OpenAI provider should support a **custom endpoint/base URL** to work with OpenAI-compatible services (e.g., SiliconFlow).

**Why it matters**
- Provider flexibility is a common adoption gate for agent frameworks; missing `base_url` blocks many teams from using their preferred inference vendor.

**Frequency proxy**
- One explicit request in the top issues, but high leverage: it impacts every “OpenAI-compatible” provider integration story.

---

### 7) Community / Security — **Migration and scam-risk anxiety (medium severity)**
**What users expressed**
- Confusion about token migration and scam concerns; explicit warnings not to trust DM links or fake ticket systems.

**Why it matters**
- Even if not a core framework bug, this affects user trust and reduces willingness to engage with official links and processes.

**Frequency proxy**
- Mentioned as a notable community concern in 2026-02-23 highlights.

---

## 2) Usage Pattern Analysis (actual vs intended usage)

### How users are actually using elizaOS right now
1. **Crypto trading and agentic finance workflows**
   - Community focus includes Babylon (crypto trading platform), Hyperscape duel betting, OTC agent, and external tools like **fomolt** (CLI trading platform designed for testing with Eliza agents).
   - Feature gravity: payments infrastructure (issue **#6443**) and non-custodial agent wallets (MoonPay Agents discussion).

2. **Rapid plugin-driven expansion**
   - Users ask “which plugin should I use?” (image generation: recommendation shifted toward **plugin-bootstrap** vs older plugin-image-generation).
   - Pattern: users want “blessed defaults” and deprecation clarity.

3. **Operational maturity needs**
   - Branch/release hygiene and issue-tracker hygiene are now part of “user experience” for builders adopting the framework.

### Emerging / unexpected applications
- **LLMs for hardware workflows**: FPGA development and 3D printing were discussed as practical uses; indicates interest in “agent + toolchain” beyond web automation.

### Feature requests aligned with real usage
- **Payment infrastructure plugin** (#6443) aligns with the finance-heavy agent usage trend.
- **Custom OpenAI endpoint** (#6490) aligns with teams mixing providers for cost/performance.
- **Cost controls** (seen in the recently closed “Cost Evaluator” work) align with token sensitivity.

---

## 3) Implementation Opportunities (solutions, prioritized)

Below, each major pain point includes concrete fixes with impact/difficulty notes.

### A) Branch/version integrity incident (develop contained 2.0.0)
**Opportunities**
1. **Adopt explicit release branch model + protections**
   - Create protected branches such as `release/1.x`, `release/2.x`, and make `develop` point to only one major line.
   - Enforce branch protection: require PRs, signed commits (optional), CI green, and CODEOWNERS review for branch-changing files.
   - **Impact:** Very high (restores trust) | **Difficulty:** Medium  
   - Similar approach: Kubernetes / many OSS projects use release branches + strict protections.

2. **Add a “Version target” CI guard**
   - CI job that fails if package.json / core version markers indicate wrong major version for the branch (e.g., `develop` must be `1.*` or `2.*`).
   - **Impact:** High | **Difficulty:** Low-medium

3. **Publish an official “Which branch should I use?” matrix**
   - A single doc/table mapping: branch → major version → compatibility notes (plugins, webapp, cloud).
   - **Impact:** Medium-high | **Difficulty:** Low

---

### B) GitHub ↔ Linear sync chaos
**Opportunities**
1. **Make GitHub the source of truth for OSS + restrict Linear sync direction**
   - One-way sync (GitHub → Linear) or scoped bidirectional only for labeled issues.
   - **Impact:** High | **Difficulty:** Medium

2. **Introduce an “Issue hygiene” automation**
   - GitHub Action to detect duplicates (same title prefix), warn on mirrored IDs, and apply canonical labels (`canonical`, `mirrored-from-linear`).
   - **Impact:** Medium | **Difficulty:** Medium

3. **Create a public triage rubric**
   - Define where to report what (bugs vs product tasks), expected response times, and how Discord reports become GitHub issues.
   - **Impact:** Medium | **Difficulty:** Low

---

### C) Timeline ambiguity (Babylon release, AI news schedule)
**Opportunities**
1. **Single “Now / Next / Later” public roadmap**
   - Lightweight, updated weekly; include Babylon rollout stages (e.g., “1% → 100% rollout” already discussed internally).
   - **Impact:** High (reduces repeated questions) | **Difficulty:** Low

2. **Pinned Discord posts + automated weekly announcement**
   - Auto-post release notes / upcoming milestones to a single channel; link to roadmap.
   - **Impact:** Medium-high | **Difficulty:** Low

3. **Define “release criteria” per product**
   - Even if dates are uncertain, publish what must be true for release (onboarding complete, billing enabled, etc.).
   - **Impact:** Medium | **Difficulty:** Low

---

### D) Access/roles friction (milady room, core dev role assignment)
**Opportunities**
1. **Self-serve access via Discord onboarding gates**
   - Use Discord’s built-in onboarding/questions or a simple verification flow (e.g., GitHub-linked role) for read access.
   - **Impact:** Medium-high | **Difficulty:** Low-medium

2. **Document the permission model**
   - A short page: roles, what they unlock, how to request, and expected turnaround.
   - **Impact:** Medium | **Difficulty:** Low

3. **Create an “Access Requests” form + audit log**
   - Route to a single queue; track who granted access and why.
   - **Impact:** Medium | **Difficulty:** Medium

---

### E) Cost/performance blowups (duplicate URL processing; reflection/message bloat)
**Opportunities**
1. **Fix message normalization: URLs should not be both text + attachment**
   - Resolve #6486 by ensuring a URL preview/metadata path doesn’t enqueue a second LLM call.
   - Add regression test: “URL message produces exactly 1 completion.”
   - **Impact:** High | **Difficulty:** Low-medium

2. **Add “cost guardrails” as a default capability**
   - Promote the cost evaluator concept into default tooling: per-message token/cost ceilings with clear logs when truncated.
   - **Impact:** High | **Difficulty:** Medium

3. **Reduce context bloat from reflections/recentMessages**
   - Implement configurable caps (N messages, max chars) and/or summarization for reflections.
   - **Impact:** Medium-high | **Difficulty:** Medium  
   - Similar approach: many agent frameworks cap memory windows and summarize older turns.

---

### F) Provider compatibility gap (custom OpenAI endpoint)
**Opportunities**
1. **Add `baseURL`/`endpoint` to OpenAI provider config**
   - Match common patterns in OpenAI SDKs (`base_url`) to support OpenAI-compatible services.
   - **Impact:** High (unblocks many users) | **Difficulty:** Low

2. **Add documented examples for 2–3 popular “OpenAI-compatible” vendors**
   - Provide copy-paste config snippets.
   - **Impact:** Medium | **Difficulty:** Low

3. **Add provider conformance tests**
   - Minimal smoke test suite that ensures the provider respects base URL, headers, and model naming.
   - **Impact:** Medium | **Difficulty:** Medium

---

## 4) Communication Gaps (expectations vs reality)

1. **Expectation:** `develop` is safe to build against  
   **Reality:** It contained a different major version without traceable history.  
   **Improve:** Publish an explicit branching policy + enforce with CI and protections.

2. **Expectation:** “Where do I ask / where is canonical info?”  
   **Reality:** Timeline questions (Babylon release, AI news schedule) are asked in chat and go unanswered.  
   **Improve:** Roadmap + pinned FAQ + weekly cadence posts.

3. **Expectation:** “Plugins are stable and discoverable”  
   **Reality:** Users are advised to use **plugin-bootstrap** instead of older packages, but there’s no obvious deprecation/best-practice index in the provided feedback.  
   **Improve:** A “Blessed plugins” page and deprecation notices.

4. **Expectation:** “Migration processes are safe”  
   **Reality:** Scam warnings and migration confusion persist.  
   **Improve:** Single official migration page; standard “never DM links” banner; verified bot that replies with official URLs.

---

## 5) Community Engagement Insights

### Power users observed (and what they need)
- **Odilitime**: heavy on repo hygiene, plugin guidance, access admin, framework comparisons.  
  **Needs:** tooling that reduces manual admin (access automation), and stronger release/branch controls.
- **Stan ⚡**: helped clarify GitHub/Linear sync; engaged in optimization collaboration.  
  **Needs:** clear ownership boundaries for tooling decisions (Linear policy, where fixes land).
- **ElizaBAO**: shipping (hackathon submission), community guidance (Babylon spaces), asks for news schedule.  
  **Needs:** official comms cadence to amplify updates and reduce uncertainty.
- **Fido**: introduced **fomolt** and requested feedback—signals a builder ecosystem forming.  
  **Needs:** integration guides, example agents, and a standard testing harness.

### Newcomer friction signals
- “Can I get access to milady room?” repeated requests indicate onboarding gates aren’t self-evident.
- “Which plugin should I use?” indicates missing “start here” plugin pathways.
- Migration/scam anxiety suggests newcomers lack a single trusted onboarding checklist.

### Converting passive users into contributors
- Create “first contribution” lanes:
  - “Good first issue” tags tied to docs (roadmap/FAQ, plugin index) and small bugfixes (URL duplicate call regression test).
  - Discord-to-GitHub bridge: a bot or template that turns a Discord report into a prefilled GitHub issue.

---

## 6) Feedback Collection Improvements

### Current channel effectiveness
- **Discord** is good for rapid detection (branch incident, role issues) but poor for closure (timeline questions unanswered).
- **GitHub issues** capture concrete, actionable bugs/requests (#6486, #6490), but discovery from Discord is inconsistent.
- **Linear sync** currently adds noise rather than structure (per feedback).

### Improvements
1. **Structured weekly “Feedback roundup”**
   - A simple form or GitHub Discussion prompt: “Top 3 pains this week, with links.”
2. **Standard intake templates**
   - For bugs: reproduction + expected/actual + environment (already strong in #6486).
   - For feature requests: “who is blocked, what provider/workflow, config sample.”
3. **Underrepresented segments to actively solicit**
   - **Non-crypto SaaS/workflow users** (despite n8n/Gmail/WhatsApp work in the broader repo context, little direct Discord feedback here).
   - **Self-hosters** (performance, deployment pain not strongly represented in this day’s Discord data).
   - **Plugin authors** (need more systematic feedback than ad-hoc “use plugin-bootstrap”).

---

## Prioritized High-Impact Actions (next 2–4 weeks)

1. **Lock down branching/release policy + protections** (prevent repeats of `develop` major-version drift).  
2. **Fix the duplicate URL processing bug (#6486) + add regression tests** (direct cost/UX win).  
3. **Define GitHub vs Linear source-of-truth and change sync to reduce triage noise** (restore contributor efficiency).  
4. **Publish a lightweight roadmap + pinned FAQ covering Babylon timing and AI news cadence** (reduce repeated unanswered questions).  
5. **Add OpenAI provider `baseURL` support (#6490) + document 2–3 OpenAI-compatible provider examples** (high leverage adoption unlock).