Proposed work: add a related bounty/source field to the proposed-work template

[xyjk0511]

Problem

#649 asks proposed-work submitters to either link the bounty issue from the proposed-work issue or comment back on #649 with the proposed-work URL. The current proposed-work issue form has required sections for problem, evidence, proposed work, expected value, acceptance, tests, duplicate search, and out-of-scope notes, but it has no explicit required field for the related bounty, source issue, PR, or discussion that prompted the proposal.

That makes #649-style intake depend on authors remembering to place Bounty #649, Related proposed-work bounty: #649, or a source link somewhere in free text. It also makes later queue/reporting work harder because the source context is not captured in a predictable form field.

Evidence

• MRWK bounty: 50 MRWK - accepted proposed-work requests, round 1 #649 process step says to link this bounty issue from the proposed-work issue, or comment here with the proposed-work issue URL:
  MRWK bounty: 50 MRWK - accepted proposed-work requests, round 1 #649
• The current proposed-work template has no related_bounty, source_issue, or equivalent field:
  https://github.com/ramimbo/mergework/blob/main/.github/ISSUE_TEMPLATE/proposed-work.yml
• The current template field ids are problem, evidence, proposed_work, expected_value, reference_tier, acceptance, tests, duplicate_search, and out_of_scope.
• Existing submissions use different free-text forms, for example Proposed work: add review-bounty candidate selection report #693 uses Related proposed-work bounty: #649, while newer submissions such as Proposed work: distinguish bounty references from GitHub linked issues #696, Proposed work: clarify partial pending-payout availability guidance #697, and Proposed work: align generic work-proof JSON availability keys #698 use a terse Bounty #649.

Proposed work

Add a small required field to .github/ISSUE_TEMPLATE/proposed-work.yml, for example:

• id: related_bounty_or_source
• label: Related bounty or source issue
• description: ask submitters to link MRWK bounty: 50 MRWK - accepted proposed-work requests, round 1 #649 or the issue, PR, discussion, API route, or docs page that prompted the proposal

Also add focused docs-smoke coverage so the field remains present and required. If useful, add one short sentence to an existing contributor/agent doc telling #649-style submitters to fill this field.

Expected value

• Maintainers reviewing proposed-work intake can see the source bounty/context without parsing arbitrary prose or chasing a separate claim comment.
• MRWK bounty: 50 MRWK - accepted proposed-work requests, round 1 #649-style submissions become more consistent while preserving the existing issue-form sections.
• Future queue/reporting work can consume a predictable source field instead of guessing from free text.
• Contributors get a clearer prompt before opening the issue, reducing needs-info loops for missing source context.

Relationship to related proposals

• Proposed work: Add proposed-work intake triage report #672 proposes a proposed-work intake triage report. This proposal is smaller: capture the source context at submission time so reporting has a cleaner input later.
• Proposed work: handle unlabeled proposed-work intake from CLI submissions #684 covers proposed-work issues that lack the proposed-work label because the submitter cannot add labels through CLI/API. This proposal is about a missing source/bounty field even when the template is used.
• Proposed work: distinguish bounty references from GitHub linked issues #696 covers PR bounty-reference wording versus GitHub linked-issue semantics. This proposal is only about the proposed-work issue form.
• Proposed work: expose structured submission mode for non-PR bounties #676, Proposed work: add typed OpenAPI response schemas for public MRWK read APIs #688, Proposed work: add review-bounty candidate selection report #693, Proposed work: clarify partial pending-payout availability guidance #697, and Proposed work: align generic work-proof JSON availability keys #698 cover submission mode, OpenAPI schemas, review candidate reporting, partial availability guidance, and work-proof JSON shape respectively; they do not add this proposed-work source field.

Possible acceptance criteria

• The proposed-work issue template includes a required related bounty/source field.
• The field description explicitly tells MRWK bounty: 50 MRWK - accepted proposed-work requests, round 1 #649-style submitters to link the intake bounty or source issue, PR, discussion, route, or docs page.
• scripts/docs_smoke.py or equivalent focused coverage fails if the field is removed or no longer required.
• The existing non-claimability warning remains intact: a proposed-work issue is not a live MRWK bounty and /claim should not be submitted unless a future live bounty exists.

Evidence or tests required

• Inspect .github/ISSUE_TEMPLATE/proposed-work.yml and confirm the new field exists with validations.required: true.
• Run the focused docs-smoke check, likely python scripts/docs_smoke.py, or a narrower equivalent test if maintainers prefer.
• Confirm the existing warning text about proposed work not being a live MRWK bounty remains present.

Duplicate search

I searched for existing issues using phrases including:

• proposed-work template related bounty source
• related bounty/source field
• source issue proposed-work template
• Bounty #649 template field

I did not find an existing proposed-work issue for adding a required related bounty/source field. Related but distinct issues are #672, #684, #696, #676, #688, #693, #697, and #698 as described above.

Out of scope

• No label automation or permission changes; Proposed work: handle unlabeled proposed-work intake from CLI submissions #684 covers unlabeled CLI/API intake.
• No proposed-work queue/report implementation; Proposed work: Add proposed-work intake triage report #672 covers intake triage reporting.
• No changes to bounty payout, proof creation, ledger execution, treasury proposals, wallet material, balances, exchange, bridge, cash-out, private security handling, or fabricated paid-work status.
• No claimability change for proposed-work issues; they remain intake only until a separate live bounty is created and reserved.