Add proposals directory, evidence convention, and CONTRIBUTING

CONTRIBUTING.md

@@ -0,0 +1,75 @@
+# Contributing
+
+Feedback and contributions are welcome. The OWASP Top 10 for Quantum Security
+Risks is at draft v0.1 and is explicitly opened for discussion - the v0.1 entries
+hold no incumbency and may be revised, merged, or dropped.
+
+The route from v0.1 to a community-validated v1 is set out in the
+[sprint plan](plans/sprint-plan-quantum-top10-2026.md). Contributors do not need
+to be entry leads or working group members to submit.
+
+## Where your contribution goes
+
+| You want to | Do this |
+|---|---|
+| Propose a new risk entry | Pull request adding a file to [`proposals/`](proposals/) |
+| Give structured feedback on an existing entry | Pull request against that entry in [`quantum-top-10/`](quantum-top-10/) |
+| Raise a question, flag an error, or discuss scope and ordering | Open an [issue](https://github.com/OWASP/quantum-security-project/issues) |
+| Contribute without using GitHub | Use the [candidate risks and feedback form](https://forms.gle/8NbEEX6mmiKdUXxXA) or the [work areas and proposals form](https://forms.gle/n7BicJJpQJFQ8eRz7) |
+
+Issues are the right place for feedback that is not yet a concrete edit. A pull
+request is the right place for feedback that is.
+
+## Making a change
+
+```bash
+git clone https://github.com/OWASP/quantum-security-project.git
+cd quantum-security-project
+git checkout -b my-contribution
+# edit or add entries; start from quantum-top-10/_template.md for new risks
+git commit -am "Describe your change"
+git push -u origin my-contribution
+```
+
+Then open a pull request against `main`. If you do not have write access, fork
+the repository first and open the pull request from your fork.
+
+Please keep a pull request to one entry or one concern where you can. It makes
+review tractable and keeps discussion of a disputed scope boundary separate from
+discussion of a citation fix.
+
+## What contributions need to satisfy
+
+- **Grounded in evidence.** Ground new or revised content in published
+  standards, regulation, or peer-reviewed research. See the
+  [evidence and anchor convention](quantum-top-10/_evidence-convention.md) for
+  the tags and the anchor hierarchy, and cite primary sources rather than
+  secondary summaries.
+- **Vendor-neutral.** Naming a product is fine where it is the evidence - a
+  library's default configuration, a documented vulnerability - but the project
+  does not endorse or recommend vendors.
+- **Practical.** The success criteria for v1 are that it is useful to defenders
+  today, actionable, and linked to existing guidance. Mitigations should say
+  what to do, not that a problem should be addressed.
+
+Contributions on the **platform surface** (QS08-QS10: QPU tenant isolation,
+toolchain and compiler security, side-channel and control-plane exposure) are
+particularly sought, since the practitioner community there is smaller.
+
+## Community
+
+- **OWASP Slack:** `#project-quantum-security` - [join the OWASP Slack](https://owasp.org/slack/invite)
+- **Biweekly community call:** Mondays 17:30-18:30 London, every two weeks from
+  3 August 2026. Zoom link, meeting ID, and an ICS invite are in the
+  [README](README.md#community-and-contact); decks are published in [`calls/`](calls/).
+- **Email:** contribute@quantum-owasp.org
+
+The project follows the OWASP Code of Conduct and OWASP's vendor-neutrality
+requirements.
+
+## License
+
+Contributions are made under the
+[Creative Commons Attribution-ShareAlike 4.0](LICENSE) license (CC BY-SA 4.0).
+By opening a pull request you agree that your contribution is licensed on those
+terms.

proposals/README.md

@@ -0,0 +1,45 @@
+# Proposals
+
+This directory holds proposed new entries for the OWASP Top 10 for Quantum
+Security Risks while they are under consideration. It exists because the
+[sprint plan](../plans/sprint-plan-quantum-top10-2026.md) routes new entries
+here: *"Open submission of new entries via pull request to the proposals
+directory."*
+
+Proposals live here rather than in [`quantum-top-10/`](../quantum-top-10/) so
+that the draft list and the candidate pool stay visibly separate. Nothing in
+this directory is part of the Top 10.
+
+## Submitting a proposal
+
+1. Copy [`../quantum-top-10/_template.md`](../quantum-top-10/_template.md) to
+   `proposals/PROPOSAL_Short-Name.md`.
+2. Fill in the template sections. Ground the content in published standards,
+   regulation, or peer-reviewed research, and keep it vendor-neutral.
+3. Tag the evidence for each attack class you describe, following
+   [the evidence and anchor convention](../quantum-top-10/_evidence-convention.md).
+4. Open a pull request against `main`.
+
+Proposals do not carry a QS number. Numbering is assigned if and when an entry
+is selected for the list.
+
+## What happens to a proposal
+
+Per the sprint plan, the generative sprint (to 3 August 2026) collects
+proposals; Sprint 1 (3-17 August) ranks them by community vote alongside
+internal review of evidence quality, scope overlap, and coverage across the
+migration and platform surfaces. The v0.1 entries hold no incumbency and
+compete on the same terms, so a proposal may displace an existing entry rather
+than only be added alongside one.
+
+Selected proposals move into `quantum-top-10/` with a QS number. Proposals that
+are not selected stay here as a record of what was considered.
+
+## Other kinds of contribution
+
+- **Structured feedback on an existing entry:** open a pull request against that
+  entry in `quantum-top-10/`, not a proposal here.
+- **Less formed feedback, questions, or a discussion about scope:** open an
+  [issue](https://github.com/OWASP/quantum-security-project/issues).
+
+See [CONTRIBUTING.md](../CONTRIBUTING.md) for the full picture.

quantum-top-10/_evidence-convention.md

@@ -0,0 +1,63 @@
+# Evidence and anchor convention
+
+The [sprint plan](../plans/sprint-plan-quantum-top10-2026.md) sets out the
+working principle this document implements:
+
+> **Evidence over speculation.** Proposals are tagged as demonstrated, emerging
+> or theoretical, so that the evidence base of the final list is visible rather
+> than implied.
+
+Tagging makes the strength of each claim explicit in the artefact itself. A
+theoretical risk is not disqualified by being theoretical - a list that only
+admitted demonstrated attacks would miss most of the migration surface, where
+the defining risk is that the attack is not yet possible. What matters is that
+the reader can see which is which without reconstructing it from the references.
+
+## Evidence tags
+
+Tags apply per attack class, not per entry. An entry may carry more than one
+tag where it describes several failure modes.
+
+| Tag | Meaning |
+|---|---|
+| **demonstrated** | Shown against real systems: a published exploit or proof-of-concept on production or production-representative systems, or an assigned CVE. |
+| **emerging** | Shown under laboratory conditions, typically in peer-reviewed research, or documented as a near-miss - but not yet observed against systems in production use. |
+| **theoretical** | A sound analysis of a plausible failure mode, following from published cryptographic or architectural results, with no demonstration yet. |
+
+A useful boundary case: an attack that depends on a cryptographically relevant
+quantum computer (CRQC) is tagged by the state of everything *except* the CRQC.
+Harvest-now-decrypt-later collection is demonstrated as collection; the
+decryption step is not. Where an entry turns on this distinction, say so in the
+text rather than resolving it in the tag alone.
+
+## Anchor hierarchy
+
+Every claim should rest on the strongest anchor available to it. Where a
+stronger anchor exists, prefer it:
+
+1. **Standards and regulation** - NIST FIPS and IR publications, IETF RFCs, UK
+   NCSC guidance, EU regulation and roadmaps, NSA CNSA.
+2. **Peer-reviewed research** - papers at recognised venues; cite the venue and
+   a DOI or the publisher's page.
+3. **CVEs and demonstrated proofs-of-concept** - cite the CVE record.
+4. **Preprints and working drafts** - acceptable where nothing stronger exists,
+   but mark the status in the citation.
+
+Two practices keep the anchors trustworthy over the life of the list:
+
+- **Cite the primary source.** Link the standard, the RFC, the CVE record, or
+  the paper itself, not a secondary summary of it. Secondary sources have
+  already introduced errors into this repository's citations.
+- **Record verification.** Entries carry an HTML comment above the reference
+  list noting the date the references were verified and any corrections made.
+  Keep it current when you touch the references, and note when an anchor has
+  been superseded - drafts become RFCs, and draft names change on working-group
+  adoption.
+
+## Applying a tag
+
+State the tag inline where the attack class is described, or in the pull request
+where an entry's overall evidence base is under discussion. If the template
+gains a dedicated field for this - as proposed in
+[issue #15](https://github.com/OWASP/quantum-security-project/issues/15) - that
+field takes precedence over any convention here.