Maintainer workflow: using oss-signal for triage and CI evidence

[SalmonPlays]

This discussion is the public place for maintainer workflow questions around oss-signal.

Useful starting points:

• Run a local audit: npx oss-signal .
• Audit a public repository: npx oss-signal owner/repo
• Generate an issue-ready follow-up: oss-signal owner/repo --format issue
• Add the GitHub Action: SalmonPlays/oss-signal@v0.6.4
• Review the maintainer playbook: https://github.com/SalmonPlays/oss-signal/blob/main/docs/maintainer-playbook.md
• Review public evidence for reviewers: https://github.com/SalmonPlays/oss-signal/blob/main/docs/reviewer-evidence.md

Good topics for this thread:

• Which repository-readiness rules are useful or too noisy for maintainers.
• How to use Markdown, JSON, SARIF, inventory, or issue-ready output in an existing workflow.
• Examples of reports that helped reduce maintainer triage time.
• Suggestions for future rules that stay tied to contributor clarity, CI evidence, release hygiene, or security-report routing.

Boundary: oss-signal measures visible maintainer-readiness signals. It does not claim that a repository is secure, popular, or high quality.