Stakeholders & RACI
Stakeholders & RACI
Status
Draft v1 — 2026-07-30
Stakeholder table
This RACI covers platform delivery — the work of building and maintaining Rymflux itself. Plugin developers and room authors are Responsible for their own plugins and rooms, but that work is outside the scope of this RACI.
| Stakeholder | Role | R | A | C | I |
|---|---|---|---|---|---|
| End user (listener) | Consumes audio through rooms | — | — | — | I |
| Plugin developer | Writes content-source plugins | — | — | C | I |
| Room author | Builds room experiences on the framework | — | — | C | I |
| Core platform team | Builds and maintains the core platform, plugin runtime, and room framework | R | A | C | I |
| Platform operator | Manages releases, CI, documentation, and support | C | R | C | I |
| Technical lead | Owns architecture decisions, API contracts, and technical direction | C | A | R | I |
| Product owner | Owns scope, priorities, and stakeholder communication | I | A | R | I |
R = Responsible (does the work), A = Accountable (signs off), C = Consulted (input before decision), I = Informed (notified after)
Stakeholder profiles
End user (listener)
Description: A person who listens to audio — music, podcasts, audiobooks, radio, or other spoken-word content. They want a listening experience that fits the content they are consuming, not a generic player.
Needs from Rymflux:
- Intuitive, room-appropriate interfaces for each audio type they consume.
- Seamless switching between rooms without losing their place.
- A unified library that works the same regardless of where content came from.
- Reliable playback.
Not needs: Rymflux is not a content service. Users do not come to Rymflux for music; they bring their own sources.
Success looks like: The user installs Rymflux, installs a Music Room and a plugin, and immediately understands how to find and play music without reading a manual. When they later discover the Podcast Room, it feels different from Music in the right ways.
Plugin developer
Description: A developer integrating a content source with Rymflux. This could be the maintainer of a large streaming service API wrapper, or someone writing a plugin for their personal music collection.
Needs from Rymflux:
- A clear, stable protocol specification with no ambiguity.
- Minimal boilerplate — the fastest path from zero to a working plugin.
- Freedom to use any programming language and any tools.
- Clear error handling and debugging support.
Not needs: Plugin developers do not need to understand the room framework, the playback engine, or the library system. Their plugin only needs to speak the plugin protocol.
Success looks like: A developer reads the plugin spec, writes a plugin in their language of choice in under an hour, drops it into the plugins directory, and sees their content appear in the relevant room.
Room author
Description: A developer or designer creating a new experience type — a Podcast Room, an Audiobook Room, a Meditation Room, or something entirely new. They understand the content type deeply and want to design an interface tailored to it.
Needs from Rymflux:
- A clear room framework API: how to register, what they control, what the core provides.
- Ability to define navigation, search behavior, metadata layout, player expansion, and context menus.
- Access to shared services: search manager, library, playback engine handle, queue.
- Freedom to design the UI without fighting the platform.
Not needs: Room authors do not need to understand plugin internals, the playback engine implementation, or how content is cached. They compose services at the room framework level.
Success looks like: A developer builds a new “Language Learning” room in a weekend. It has its own search filters (language, level, instructor), its own player expansion (slow-down controls, transcript, repeat-phrase button), and integrates seamlessly with the existing Music Room. Users switch between them without noticing they are using different architectures.
Core platform team
Description: The engineers building the Rymflux core — the plugin runtime, the room framework, the playback engine, the library, search, queue, and shell/navigation. They own the contracts and ensure everything works together.
Needs:
- Clear, documented contracts for every interface.
- Good testability of each layer in isolation.
- Observability into plugin and room behavior.
- Versioning and migration strategy for all APIs.
Platform operator
Description: The person or team responsible for releases, CI/CD, documentation, issue triage, and community support.
Needs:
- Automated quality gates (build, test, lint, spec validation).
- Clear release process (version bumps, changelog, migration notes).
- Documented runbooks for common issues.
Technical lead
Description: Owns the architectural integrity of the platform. Makes or ratifies all significant design decisions.
Needs:
- Every major decision captured as an ADR.
- Visibility into all plugin and room API changes.
- The ability to say no to scope additions that compromise the contract.
Product owner
Description: Owns the “what” — scope, priorities, stakeholder communication, and release planning.
Needs:
- A clear understanding of each stakeholder’s priorities.
- Escalation path for scope disputes.
- Visibility into technical decisions that affect timelines.