CB.5:4.1 - Turn a general request into a receiving use

Ask who will use the contribution, for what next action, and under which conditions. Replace “we need more content” with the question a reader cannot yet answer or the action they cannot perform. Replace “we need ideas” with the use difficulty and the kind of proposal the receiving team can consider.

Choose the result before recruiting contributors. For a case, establish the subject and relevant configuration, what has been tried, the uncertainty, permitted material and useful response window. For a shared resource, establish its intended users, applicable content and the person who can maintain it. For a recommendation, establish what the recipient needs to decide and what the recommender actually knows.

Agree how the recipient will recognise a useful contribution. A case owner may need a justified next step; a design team may need a testable use account; a service owner may need evidence that a permissible intervention restored the required function. The criteria come from the receiving work and its domain, not from the number of responses or the contributor’s popularity.

Distinguish accepted, usable and applied. A recipient can accept a technically sound explanation but be unable to act because access is missing. A product team can find a suggestion informative while declining its implementation. Preserve the actual outcome so that the contribution can be improved without claiming work that did not occur.