Community scope and maintenance

PyFFmpegCore grows through completed workflows and reusable evidence, not star targets. The project asks users what they finished, how long the first useful result took, and what friction remains.

Public routes

• Reproducible defects use the bug issue form.
• Concrete new workflows use the recipe request form. A proposal enters the supported catalog only with a typed plan, preflight behavior, deterministic fixture, receipt contract, documentation, and a maintainer.
• Discussions are for recipe ideas and completed-workflow show-and-tell.
• Vulnerabilities use private security reporting, never a public issue or Discussion.

The initial bounded newcomer queue is #7, #8, #9, #10, and #11. Each issue names files, acceptance criteria, verification commands, and non-goals where useful.

Labels have narrow meanings: good first issue is bounded and reviewable, help wanted has an active maintainer, recipe is a user outcome, documentation changes explanation, platform covers environment-specific behavior, bug is reproducible incorrect behavior, and security tracks public hardening work without exposing vulnerabilities.

Distribution ethics

Release announcements must identify the maintainer's project, lead with one reproducible use case, link the exact artifact and evidence, and invite workflow feedback. The project does not use star exchanges, purchased engagement, mass unsolicited posting, fake benchmarks, or unverified fastest/easiest/secure claims. Community-specific rules and disclosure requirements always win.

Triage and credit

The best-effort response targets and maintenance-pause policy are in SUPPORT.md. Release preparation must review external issue reporters, recipe authors, testers, and code contributors for credit, including contributors who prefer an anonymous acknowledgement.