issue-writing

Machine-authored is not the problem. Unreviewed is. curl's security intake produced a slop crisis and, a year later, its best confirmed-vulnerability rate in years — "somewhere in the 15-16% range" — while "almost every security report now uses AI to various degrees." The incentive, the platform, and the submitter population all changed together, so what fixed it is not identified; what the pair of measurements rules out is machine authorship as the cause. Maintainers object to reports nobody read before sending, not to the tool that drafted them. Never argue that the report is fine because a human would have written the same thing, and never soften a finding because a machine found it.

The elements maintainers want are the ones reporters find hardest to supply. A survey of 466 developers and users across Apache, Eclipse, and Mozilla found an information mismatch: steps to reproduce, stack traces, and test cases rank as most helpful to developers and most difficult for users to provide. That gap is where an agent is genuinely useful, because it can run the reproduction, capture the trace, and reduce the case. Spend the effort there rather than on prose.

A closed issue is not a fixed issue. Closure absorbs duplicates, wontfix, invalid, obsolete, and not-reproducible. Optimize for a maintainer being able to act, not for the issue being accepted.

Route the report before writing it

The channel decides the rules, and the wrong channel is a defect no quality of writing repairs.

• A suspected vulnerability never goes in the public tracker first. Disclosing it publicly is the harm. Find the private channel before writing anything down in public.
• A defect in observed behavior is a bug report, filed in the tracker under the project's template.
• A request for behavior that does not exist is a feature request, and it is judged on fit with project goals rather than on defect evidence.
• A question, a support request, or a usage problem is usually not an issue at all. Check whether the project routes these to discussions, a forum, or chat.

For a vulnerability, establish the current route by reading the project's own files, in this order: GitHub's private vulnerability reporting if enabled on the repository, then SECURITY.md, then the project website's security page. GitHub's documentation states that private vulnerability reporting "is separate from a repository's SECURITY.md file", and that where it is enabled "anyone can submit a private vulnerability report to the repository maintainers."

Look the route up every time; never reuse a remembered one. curl moved four times inside a single year — bounty ended, reporting shifted to GitHub, GitHub was judged insufficient, reporting returned to HackerOne — and its policy now states that the project "cannot handle vulnerability reports sent to us over email." A route that was correct months ago is a guess.