Eliza mission queue — what contributors should work on

[NubsCarson]

Eliza mission queue

We want fewer artifacts and more completed product outcomes. Contributor work should make the shipped Eliza app, Eliza Cloud, the core agent runtime, or a primary capability on an existing product path materially better.

The only public eligibility signal

An issue is eligible for automatic contributor discovery only when it carries the actual repository label mission-ready.

Typing “mission-ready” in an issue title, body, comment, pull request, or Discussion does nothing. Creating a similarly named label elsewhere does nothing. Discussions and unlabeled issues are proposals, not approved work. Opening an issue is not an accepted contribution and earns no outcome credit.

Only maintainers promote work. Contributors and agents must not apply, request, or manufacture this label, mirror pull-request titles into issues, create speculative backlog, or split one outcome into multiple artifacts.

What qualifies

In priority order:

1. The shipped Eliza web, desktop, and mobile app.
2. Eliza Cloud user paths: authentication, deployment, model routing, storage, billing boundaries, and observability.
3. The core agent runtime: agent loop, tools, actions, providers, services, evaluators, memory, state, permissions, errors, and plugin loading.
4. Primary capabilities already used by the shipped/default product or an explicitly approved launch path.
5. Build, CI, packaging, deployment, and verification only when they block or misreport one of the paths above.

Niche plugins, toy examples, style churn, speculative refactors, count-only tests, generic cleanup, duplicate work, routine dependency churn, and artifacts created for leaderboard activity are not mission work.

How ideas become work

1. Propose or discuss early ideas in the Ideas category.
2. A maintainer verifies demand, reproduction, mission fit, duplication, scope, and acceptance evidence.
3. The maintainer creates or reuses one scoped issue and applies mission-ready.
4. The issue appears in the curated Mission ready Project view.
5. One contributor delivers the complete outcome with the repository-required tests and evidence.

The Project is live state; the issue is scope and acceptance; the pull request is code and proof; Discussions are proposals and coordination. An explicit operator request may authorize work outside the public queue, but a contributor cannot self-authorize that exception.

Maintainer promotion checklist

Before applying mission-ready, confirm:

• a real user, operator, or release path is blocked;
• the need is reproduced or otherwise evidenced;
• the issue advances one of the mission surfaces above;
• no active issue, pull request, or owner already covers it;
• acceptance criteria prove the real path rather than a mock;
• the scope is one coherent outcome;
• the work is worth doing now.

If any item is unclear, leave it as a proposal.

[NubsCarson]

Slop Hub contributor onboarding now has a dedicated companion announcement: https://github.com/orgs/elizaOS/discussions/20662

The mission queue and exact maintainer-controlled mission-ready label remain the only public work-authorization path. The Slop Hub post documents managed skill updates, consented aggregate ccusage receipts, separately redacted private traces, outcome-based scoring, optional public payout-address registration, and the current paused/zero-funded/payouts-disabled state. It does not create a second task queue or authorize speculative work.