Add AnchorKit issue application guidance

[El-swaggerito]

Description

Difficulty: Hard

Type: Documentation

Summary

Add issue application guidance for contributors applying to work on AnchorKit issues.

Current Behaviour

Contributors may comment unclear applications or start work before being assigned.

Expected Behaviour

The repo should explain how to apply, wait for assignment, reference the issue, communicate progress, and submit PRs.

Suggested Implementation

Create contributor guidance, example application comments, assignment expectations, PR linking rules, and maintainer notes.

Files or Areas Likely Affected

• docs/
• README.md
• .github/

Acceptance Criteria

• Issue application guidance is added.
• Example contributor comments are included.
• Assignment-before-work rule is documented.
• PR linking expectations are documented.
• Maintainer assignment notes are included.
• README links to the guidance.

Additional Notes

This should align with the auto-assign workflow.

[vickman787]

Hi, I'd like to take this on.

The note about aligning with the auto-assign workflow matters a lot here — I'd check the actual .github/workflows/ automation first, since the guidance is worthless if it describes a process the bot doesn't actually enforce (e.g. if the guidance says "wait to be assigned" but the workflow auto-assigns on any comment, or requires a specific keyword/format to trigger).

My plan:

Read the actual auto-assign workflow to understand its real trigger condition (keyword match? /assign command? first-comment-wins?) before writing anything prescriptive about it.
Write the guidance around the real lifecycle: how to comment an application, what "wait for assignment" actually means given the bot's behavior, and what to do if not assigned within a reasonable window (re-apply elsewhere vs. wait).
Include 2-3 example application comments — a clearly good one (references the issue specifics, states a concrete plan, gives a timeline) and a clearly weak one (vague, "I can do this," no plan), so the contrast itself teaches the standard rather than just asserting it.
Document the assignment-before-work rule explicitly: don't open a PR before being assigned, and why (avoids duplicate/wasted work across multiple applicants).
PR linking expectations: Closes #N conventions, and how that interacts with the PR evidence checklist (#138) if that's landed — same underlying requirement, shouldn't be documented twice with drifting wording.
Maintainer-side notes: brief, e.g. how maintainers should communicate assignment decisions or claim-window expectations, kept factual rather than prescriptive about internal process I don't have visibility into.
Link from README, verify against the six acceptance criteria literally.

Given this is the seventh related documentation issue in this campaign, the actual risk to quality is inconsistency across all of them — different documents describing "how to apply" slightly differently. If I take this on, I'd want to explicitly cross-reference the other in-flight or landed docs (PR checklist, self-review template, CI workflow) rather than write this in isolation.

[grantfox-oss]

🦊 GrantFox — @vickman787 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #98)
2. Your PR will be reviewed by the Axionvera maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@vickman787's PR #192 was approved and merged by @El-swaggerito.

🏆 @vickman787: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (393 total points). Track your full progress on GrantFox.

👏 Great work, @vickman787! Keep contributing to Axionvera.