Decide what to do with a community request

The five-stage arc

1 · Program audit. Audit the system before you rank the queue.
2 · Signal and response. Turn community signal into the right kind of response.
3 · Portfolio and capacity. Build a portfolio the organization can carry.
4 · Participation design. Design participation around the work.
5 · Change and follow-through. Make the hard update and close the loop.

Approximately 3–4 minutes · There is no score at the end. The output is a decision record.

The closing argument

The queue is not the community strategy.

The goal is not to maximize yes. It is to make every yes, not yet, experiment, route, and no legible, owned, and open to learning.

That is the layer I know how to build.

Distributed community work also needs an accountable center. See who owns the whole.

Original public model · West of Obvious

How the model works

This interactive needs JavaScript to run. The method is still explained below. The scenario is an illustrative composite: it does not represent a current or former employer, a real community, or a live request queue.

The five stages

Program audit. Before ranking any queue, decide three operating rules: how volume and representation shape priority, whether contributor progression is designed or absorbed informally by veterans, and when a request is allowed to become a public promise.
Signal and response. Six fictional community requests, each with a proposed solution, an underlying problem, affected groups, evidence, and risks. Not every signal should become a feature: the valid responses are Deliver, Discover, Program, Route, and Decline with a reason and a return path.
Portfolio and capacity. Responsible teams declare fictional capacity: two delivery envelopes, one community-program intervention, one bounded investigation, and one protected reserve. Prioritization does not create capacity, and ownerless work cannot honestly read as committed.
Participation design. A delivered feature is not automatically a functioning community program. Six operating layers carry the work: access and localization, roles and permissions, onboarding and education, mentorship, recognition, and renewal, moderation and safety, and communication and feedback. Omitting a recommended layer is recorded as an exposure, not hidden.
Change and follow-through. A delivery team loses capacity mid-cycle. The choice is to absorb it quietly, reduce scope silently, or reopen the commitment with affected participants and publish the change. A changed commitment should create a changed public record.

The six fictional signals

Keyboard-complete review flow. 68 supporters, critical access severity. Low volume and high severity make the case for published safeguards. Vote count alone would miss the need.
Right-to-left contributor dashboard. 42 supporters across 11 language communities. Clear need, unclear implementation: usually a bounded discovery question first.
Shared review queue and reviewer pathway. 710 supporters. A tool request hiding a contributor-system gap: the strongest response pairs a bounded technical commitment with a program intervention covering roles, onboarding, mentorship, recognition, renewal, moderation, and escalation.
Personal workspace themes. 1,320 supporters, the top vote count, no core workflow failure. Volume is evidence, not the whole decision.
Assisted topic suggestions. 1,040 supporters, a real newcomer problem, and unresolved questions about outcomes, data use, bias, and safeguards. Usually a discovery question, or a human-supported program pilot.
Restore dataset export utility. 190 supporters, high impact for a small technical group, and no accepted production owner. The honest response is usually routing with accountability: escalate ownership, keep the request visible, and set a decision checkpoint.

The point

Community strategy is the operating contract between participation and delivery. It defines who can enter, how needs are interpreted, which response is appropriate, what the organization can honestly promise, how contributors participate, and how the answer comes back. The goal is not to maximize yes. It is to make every yes, not yet, experiment, route, and no legible, owned, and open to learning.

Companion piece: Who owns the whole?

Design and build notes

Strategic premise. A request queue is the visible tip of a community program. Underneath it sit the questions this model walks through: who can participate at all, whose needs volume can hide, how contributors progress into responsibility, when a request may become a promise, what capacity exists, and how decisions travel back. The model treats staff judgment as legitimate and necessary; what it refuses is judgment that changes outcomes invisibly.

What it deliberately is not. There is no priority algorithm, no weighted score, no community health number, and no verdict about whether you are a good leader. Several portfolios are defensible. The output is a decision record: what the community can see, what delivery teams can rely on, how contributors can participate, and what the program still needs to learn.

Public example. The community, the requests, the vote counts, and the capacity envelopes are fictional composites created to demonstrate the method. They contain no employer, community, or customer information, and no outcome shown here is claimed as a historical result.

Companion. Who owns the whole? argues that distributed work needs an accountable center. This piece is the reciprocal case: the center matters most when people can see what happened to their input.

Build. Original concept, writing, interface, and vanilla JavaScript. One file, no framework, no libraries, no analytics, no storage. Keyboard navigation, a screen-reader status line, visible focus, reduced-motion support, and a print-ready decision record.