Bounty template for verified work

[OxBenji]

Create the first bounty template.\n\nIt should include:\n- problem statement\n- accepted artifact\n- verification method\n- reviewer requirement\n- reward notes\n- failure credit rules\n- what does not count\n\nGoal: someone should be able to propose a bounty without turning it into vague hype.

[OpensrcLord]

/claim #2

Hey — I'd like to work on this one. I just started going through the repo and reading the issue description in detail. I'll put together a PR once I have a clear fix in mind. Let me know if there's anything specific you'd like me to focus on.

[testdasislyt]

Aquí tienes una propuesta de comentario breve, profesional y directo para GitHub:

---

Hi there! Is this issue still open for contributions?

I’d love to help with this. My proposed approach is to draft a structured Markdown template covering all the requested fields. To meet the goal of avoiding vague hype, I plan to include clear, actionable placeholder prompts within the template—specifically guiding authors to define objective "verification methods" and strict "out of scope / what does not count" boundaries.

If this approach aligns with what you're looking for, please let me know and I'd be happy to take it on!

[OxBenji]

Appreciate the interest here.

This repo is extremely early, so I am not assigning issues yet. For now I am trying to keep the first pass focused on discussion before PRs.

For this issue, the most useful help would be a short proposal in the comments:

1. What fields should every bounty template require?
2. How would you make "verification method" objective instead of vague?
3. What should explicitly not count as completed work?
4. Can you give one example bounty that would be easy to verify?

Once v0.1 is clearer, I will start turning the best proposals into PRs.

[Thecesar85]

1. Required Fields

Every bounty template MUST include:

Field	Purpose
Problem Statement	One sentence + one paragraph. What is broken or missing, for whom, why now
Acceptance Criteria	Bullet checklist. MUST be verifiable (not "improve X" — say "X is satisfied when Y test passes")
Verification Method	Command, script, or manual checklist that proves completion. Automated preferred
Reviewer Requirement	Who can approve (maintainer, domain expert, core team). If external, what qualifies them
Reward	Exact amount + currency + payment method + expected timeline
Out of Scope	Explicit list of what does NOT count (prevents scope creep)
Failure Credit	What happens if PR is rejected: partial credit? feedback-only? Can they re-submit?

2. Making "Verification Method" Objective

• Automated checks first: CI pipeline, test suite run, lint pass, build success
• Reproduction script: A single-command reproducer (bash/Python) that returns exit 0 on success
• Screenshot/artifact: When UI-related, require before/after screenshots at specified viewport sizes
• Golden dataset: Pre-defined input/output pairs the solution must match
• No subjective adjectives: Replace "looks good" with measurable criteria like "button is visible at 320px viewport without horizontal scroll"

3. What Should NOT Count as Completed

• PRs that pass CI but don't include the exact acceptance criteria (feature mismatch)
• Draft PRs opened without tests
• Code that introduces new lint/type errors
• Solutions that work only on a single OS/browser when the issue requires cross-platform
• Submissions that don't include the verification evidence specified in the template

4. Example Bounty: Easy to Verify

Problem: The README install command fails because it references a non-existent Python version.

Acceptance: Replace python3.11 with python3 in README.md line 12. The command pip install -r requirements.txt must succeed in a clean Python 3.10+ venv.

Verification:

python3 -m venv /tmp/testenv && source /tmp/testenv/bin/activate && pip install -r requirements.txt && echo PASS || echo FAIL

Reward: $10 USD via PayPal within 48h of merge.

Out of Scope: Changing other docs, optimizing imports, upgrading dependencies.

Failure Credit: Rejected PRs get actionable review feedback. One free re-submission within 7 days.

---

This template makes every bounty verifiable by a machine or a human with zero ambiguity. Happy to turn this into a PR once the v0.1 direction is confirmed.

[jihadMo]

I have created the verified work bounty issue template (#2). Added .github/ISSUE_TEMPLATE/bounty_template.md covering problem statement, accepted artifacts, verification methods, reviewer requirements, reward notes, and failure credit rules.

Fix branch: https://github.com/jihadMo/capgo/tree/fix/bounty-template-for-verified-work

[OxBenji]

This is really useful, thank you.

The acceptance criteria, out-of-scope section, and failure credit framing are especially close to what I want for v0.1.

I am going to keep this issue in discussion mode a little longer so other people can pressure-test the template before we turn it into a PR.

One thing I want to tighten: reward terms should probably stay separate from verification accepted so we do not blur completion, review, and payment.

Appreciate you helping shape the first pass.

[OxBenji]

Thanks for taking a pass at this.

For now I am keeping #2 in discussion mode before accepting PRs or external branches as the source of truth. If you want this considered for v0.1, the most helpful next step is to paste the proposed template structure directly in this issue so everyone can review and pressure-test it in public.

Once the direction is stable, I will turn the best version into a PR against this repo.

[jihadMo]

Here is the proposed Markdown issue template structure for v0.1:

`markdown

name: Verified Bounty Proposal
about: Propose a verified bounty with clear acceptance criteria and verification rules
title: '[BOUNTY]: '
labels: 'bounty'

🎯 Problem Statement

Clear, objective description of the technical problem or feature requirement.

📦 Accepted Artifact

• Core source code changes / pull request
• Automated unit test suite verifying the fix
• Architecture / technical documentation (if applicable)

🧪 Verification Method (Objective & Machine-Verifiable)

• Command line to run tests:
  pm test\ or \go test ./...\
• Expected output, exit code 0, and passing assertions

👤 Reviewer Requirement

• Code review by repository maintainers
• Verification of test coverage and code quality

💰 Reward Notes & Escrow

• Bounty Amount: $[Amount] USD / Tokens
• Escrow / Payout details: [Platform link or wallet address]

⚠️ Failure Credit Rules & What Does NOT Count

• Does NOT Count: Incomplete submissions, unverified claims without code/tests, or duplicate pull requests.
• Scope Boundaries: Solutions that fail cross-platform checks or introduce unhandled lint/type errors.
  `

Happy to refine any of these sections based on community feedback!

[OxBenji]

Quick update: I pulled the first public draft into the repo here:

https://github.com/OxBenji/progress-ledger/blob/main/docs/bounty-template.md

This is still not final. I want #2 to stay open for pressure-testing the template before we treat it as the source of truth.

Most useful feedback right now:

1. Which fields are missing?
2. Which fields are too vague?
3. Where does the template blur verification, review, and payment?
4. What wording could invite spam, token-first framing, or unverifiable claims?

One note: for v0.1, I want reward terms to stay careful and separate from verification accepted. No token-first bounty language yet.

[OxBenji]

Also added a tiny example bounty here for people who prefer concrete objects over abstract templates:

https://github.com/OxBenji/progress-ledger/blob/main/examples/bounties/proof-receipt-example.md

Use it as something to critique. If the example is too loose, too narrow, or missing an anti-gaming rule, call that out here.

[jihadMo]

Looks great! Moving payment terms into a separate dedicated section (## 💰 Payment & Escrow Terms) keeps the verification block strictly focused on technical acceptance criteria and test commands. The structure in docs/bounty-template.md looks very clean and balanced for v0.1.