RADAR · PARTICIPATION & DELIVERY
Six checks before starting a public bounty task
A public issue reveals a request. An open state does not prove that funding remains available, nobody else has claimed it or every submission will be paid. The task directory brings source, visible discussion and AI-policy signals together to support a decision, not to promise income.
1. Check whether the work is still needed
Read recent discussion as well as the original description. Look for merged implementations, duplicates, scope changes and maintainer responses. Long-standing requests especially need current confirmation.
2. Confirm the bounty independently
Check the amount, currency, claiming conditions, payer and whether someone already holds the task. A displayed amount marked unconfirmed is not a payment commitment.
A comment count measures visible discussion, not competitors. One person may comment repeatedly and many comments may clarify requirements. Use it to prioritize reading, not to calculate a probability of being selected.
3. Agree on a minimum acceptance result
Describe testable behavior, inputs, outputs and a verification method. Confirm whether the deliverable is code, a design, documentation or a deployed service, and identify the expected submission destination.
A concise clarification can state intended scope, verification, deliverables and the bounty conditions you need confirmed. Avoid spending days implementing before discovering that “finished” means different things to each party.
4. Clarify AI and information boundaries
Permission to contribute publicly does not establish permission to send private material to arbitrary model services. Check AI assistance, dependencies, licensing and data-use conditions for the particular task.
The radar’s assistant can organize a plan. Its generated answer cannot replace maintainer agreement or prove that a task will be accepted and paid.
5. Validate a small slice first
Check that you can run the project, reproduce the problem and execute its tests before taking on the full change. If the environment cannot be made to work, report that limitation early.
Separate feasibility from implementation and set a clear decision point for continuing. Time already spent is not evidence that further work will be useful.
6. Keep delivery and discussion records
Explain what changed, how it was verified and what remains limited; link to the relevant discussion. Submitting a pull request, merging it and receiving a payment are separate events.
The radar does not hold payments, charge a task commission or make acceptance decisions. Discuss task conditions and payment with the official task publisher.