Polish contributor support paths and issue routing. (#2)

Add a support guide, surface Discussions in the docs, and split guideline compatibility reports from generic bugs and feature requests so outside contributors know where to go.

Made-with: Cursor

Author: myceldigital

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -7,6 +7,7 @@ body:
     attributes:
       value: |
         Thanks for reporting this. Please include the exact command and enough input context to reproduce the issue.
+        If the problem is really about a specific public guideline converting or parsing badly, use the guideline compatibility template instead.
 
   - type: input
     id: version

.github/ISSUE_TEMPLATE/config.yml

@@ -3,3 +3,6 @@ contact_links:
   - name: Questions and ideas
     url: https://github.com/myceldigital/herald/discussions
     about: Use GitHub Discussions for open-ended questions, design ideas, or exploratory conversations.
+  - name: Security reporting
+    url: https://github.com/myceldigital/herald/security/advisories/new
+    about: Report security-sensitive issues privately instead of opening a public issue.

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -7,6 +7,7 @@ body:
     attributes:
       value: |
         Please focus on the real workflow or guideline problem you are trying to solve.
+        If your request is mainly "Herald should support this public guideline better", use the guideline compatibility template instead.
 
   - type: textarea
     id: use_case

.github/ISSUE_TEMPLATE/guideline_compatibility.yml

@@ -0,0 +1,49 @@
+name: Guideline compatibility report
+description: Report a real public guideline that converts or parses poorly
+title: "[Guideline]: "
+labels: ["help wanted", "documentation"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Use this when Herald struggles with a real public guideline and you want to point maintainers at a concrete parsing target.
+
+  - type: input
+    id: source_url
+    attributes:
+      label: Official public source URL
+      placeholder: e.g. https://www.nice.org.uk/guidance/...
+    validations:
+      required: true
+
+  - type: input
+    id: publisher
+    attributes:
+      label: Publisher
+      placeholder: e.g. NICE, WHO, SIGN, CDC
+    validations:
+      required: true
+
+  - type: textarea
+    id: observed_problem
+    attributes:
+      label: What went wrong
+      description: Describe the conversion or parse failure as concretely as possible.
+    validations:
+      required: true
+
+  - type: textarea
+    id: problematic_structure
+    attributes:
+      label: Problematic structure
+      description: For example two-column layout, tables, scanned pages, repeated headers, algorithm images, unusual section numbering.
+    validations:
+      required: false
+
+  - type: textarea
+    id: command_or_notes
+    attributes:
+      label: Commands run or notes
+      render: shell
+    validations:
+      required: false

CONTRIBUTING.md

@@ -26,6 +26,14 @@ ruff check src/ tests/
 5. New synthetic examples that demonstrate realistic, high-value clinical scenarios.
 6. Public-facing docs that make the trust model and limits clearer.
 
+## Where To Open What
+
+- GitHub Discussions: questions, design discussion, workflow ideas, and "would Herald support this?" conversations.
+- Bug report issue: reproducible breakage in parsing, querying, conversion, CI, packaging, or docs.
+- Feature request issue: concrete proposed change to Herald behavior.
+- Guideline-compatibility issue: a real public guideline that currently converts or parses badly and would be a good target for improvement.
+- Private vulnerability reporting: anything security-sensitive. See `SECURITY.md`.
+
 ## Ground Rules
 
 - Keep runtime querying deterministic.

README.md

@@ -98,6 +98,7 @@ Herald is not a bedside autopilot. It is tooling for turning guidelines into ins
 - `docs/supported_guidelines.md` - what converts cleanly and what does not
 - `SCHEMA.md` - full decision-tree schema
 - `CONTRIBUTING.md` - contribution workflow and standards
+- `SUPPORT.md` - where to ask questions, report bugs, and discuss ideas
 
 ## Install
 
@@ -279,6 +280,12 @@ To use Herald with a real guideline:
 
 See [CONTRIBUTING.md](CONTRIBUTING.md).
 
+## Discussions And Support
+
+- Use [GitHub Discussions](https://github.com/myceldigital/herald/discussions) for questions, design ideas, and early-stage workflow discussion.
+- Use GitHub Issues for concrete bugs, feature requests, and guideline-compatibility requests.
+- Use private vulnerability reporting for security-sensitive issues. See [SECURITY.md](SECURITY.md).
+
 ## License
 
 MIT

SUPPORT.md

@@ -0,0 +1,43 @@
+# Support
+
+## Where To Ask What
+
+### GitHub Discussions
+
+Use [GitHub Discussions](https://github.com/myceldigital/herald/discussions) for:
+
+- setup questions
+- workflow questions
+- design ideas
+- "would Herald support this?" conversations
+- early feedback before writing an issue or PR
+
+### GitHub Issues
+
+Use GitHub Issues for:
+
+- reproducible bugs
+- concrete feature requests
+- guideline-compatibility problems on public guidelines
+- documentation fixes
+
+If you can reproduce a problem with a small command sequence or synthetic example, include that up front.
+
+### Security Issues
+
+Do not open public issues for security-sensitive problems.
+
+Use GitHub private vulnerability reporting instead. See [SECURITY.md](SECURITY.md).
+
+## Good Support Requests
+
+The best reports usually include:
+
+- Herald version
+- exact command run
+- what input you used
+- expected result
+- actual result
+- minimal reproducer if possible
+
+For guideline-compatibility reports, include an official public source URL when possible.