Skip to content

Requested Contribution Menu

Published register — instantiates Net-Additive Contribution Intake

Publishes a current, bounded list of the contributions the system actually needs — with specifications, timing, and exclusions — so willing contributors can self-serve toward net-additive help.

Most of the intake burden is created upstream, by a system that broadcasts an open, unbounded "we welcome contributions!" and then drowns in offers it can't use. Requested Contribution Menu attacks the problem at the source by shaping demand before it arrives. It publishes a current, specific, deliberately bounded list of the contributions the system actually needs — the types, the specifications, the timing, and, just as importantly, the explicit exclusions — so that a willing contributor can look, see what would genuinely help, and act on it without a coordinator in the loop. Its defining move is that it is a solicitation, not a gate: where the other intake mechanisms evaluate offers that already showed up, the menu changes which offers show up in the first place, steering effort toward the net-additive and away from the redundant before either is ever submitted.

Example

A regional citizen-science biodiversity project used to receive a torrent of well-meant photo submissions — thousands of the same common backyard birds, unusable because they lacked location data, and almost nothing of the species researchers were actually tracking. Instead of screening all of it after the fact, the project publishes a currently needed menu: specific species, in specific counties, during specific windows (breeding season), with specs (a clear scale reference, an untrimmed GPS-tagged original) and blunt exclusions ("please don't submit photos of captive or baited animals; we can't use common-species sightings this season").

The menu does the sorting up front. Contributors open it, see that their region needs documentation of a particular frog during a two-week window, and self-serve a submission that lands already useful — no coordinator triaging in between. Volume drops and value rises: fewer redundant common-bird photos, more of the observations the project can't get any other way. The intake queue shrank not because the project refused more, but because it asked better.

How it works

  • Signal demand precisely. The menu names what would genuinely help — types, specs, quantities — turning a vague open door into a targeted request that pulls net-additive contributions and lets redundant ones self-select out.
  • State exclusions out loud. What the system cannot use is published as plainly as what it can, pre-empting the most common low-value offers before they cost anyone an evaluation.
  • Enable self-service. A contributor can read the menu and act correctly without a coordinator translating for them, which is what removes the per-offer human cost the open door creates.
  • Keep it current and bounded. The list is small, time-stamped, and revised as needs shift, so it stays a real signal of present demand rather than an aspirational wish-list that re-opens the floodgates.

Tuning parameters

  • Specificity — how tightly each request is specified. Precise specs raise the usable-yield of what arrives but narrow the pool willing or able to meet them; loose specs draw more offers and more noise.
  • Breadth — how many request types are listed. A short menu concentrates effort on the highest-value gaps; a long one captures more but drifts back toward "we'll take anything."
  • Refresh cadence — how often the menu is updated. Frequent updates keep it a truthful demand signal; a stale menu keeps pulling contributions the system no longer needs.
  • Exclusion explicitness — how bluntly unwanted contributions are named. Clear exclusions save the most evaluation cost but must be worded to redirect rather than to insult a willing contributor.

When it helps, and when it misleads

Its strength is that it moves curation upstream of intake: by shaping demand[1], it prevents redundant and off-target offers from being created at all, which is far cheaper than screening them after they arrive and far kinder than declining them. It also gives eager contributors a dignified, autonomous way to help well — a menu answers "what do you actually need?" before anyone has to ask.

It misleads when it is mistaken for the whole intake system. A menu shapes incoming offers but does not evaluate them, own them, or handle the unsolicited contribution that ignores it — those still need the review, the sponsor gate, and a graceful path for offers that don't fit. A stale or aspirational menu is worse than none: it actively solicits contributions the system can no longer absorb. And an over-narrow menu can wall off genuinely novel help the system didn't know to ask for. The discipline that keeps it honest is to treat the menu as a living register — pruned and refreshed against real current capacity, and paired with a channel for the valuable surprise that no menu could have anticipated.

How it implements the components

Requested Contribution Menu realizes the demand-shaping components of the archetype — the ones that govern what offers arrive in the first place:

  • contribution_demand_signal — the menu is the signal: a precise, published statement of what the system currently needs, pulling net-additive offers and letting redundant ones self-deselect.
  • self_service_contribution_path — it lets a willing contributor act correctly on their own, removing the per-offer coordinator cost that an unbounded open door creates.

It does not evaluate the offers it attracts (Contribution Net-Value Review), set the acceptance constraints for physical goods (Material Donation Acceptance List), or handle the unsolicited offer that arrives outside the menu (Post-Integration Contribution Review supplies the lessons that keep it current; the intake gate handles the rest).

References

[1] Demand shaping is the operations practice of influencing what is requested — through pricing, availability, or published specifications — rather than only reacting to whatever arrives. A requested-contribution menu applies it to intake: by advertising precise needs and explicit exclusions, it steers the shape of incoming offers toward what the system can actually convert into value. ↩