Contribution Checklist

Make a contribution request clear to someone who knows neither the project nor the conversation.

State the ask first

Open with who should do what and the expected result; put background after it. Read the destination's current submission guidance and pick the section that fits: an editor publishes an update or link, a developer implements a change, a tester reproduces a behavior. Marketing is an objective, not an implementation task: do not quietly turn it into feature recruitment, and never invent work only to qualify for coverage.

Before submitting, answer the three questions from Nell Shamrell-Harrington's review:

• What is the ask? One bounded change, its observable result, and what is out of scope.
• Where does someone start? Current links to the actual files or functions, the shortest setup and reproduction steps, and a first increment proportional to the stated difficulty.
• Is mentoring available? Who answers questions and reviews changes, or that nobody does. Never promise someone else's time.

Answer reviewer feedback

Answer the reviewer's concrete questions, acknowledge what was unclear, and point to the actual revisions. Do not answer a request for a bounded task with a general wish for traction, stars, or feature parity.