[Contributing guidelines] Improve potentially verified bugs handling

[simon-liebehenschel]

Current

As the documentation says, a user must open a "discussion" instead of an "issue".

Any opened issues are moved by a maintainer to discussions (including issues with a reproducible code sample, etc.). As I understand, a discussion becomes abandoned.

Developers looking for a aiohttp or requests alternative may be fooled by a small number of unresolved issues. "Wow, such a great package with quickly resolved bugs!".

Proposal

1. Add an issue template similar to this. The issue template will motivate users to include all details. The template must include the following sections:
   • packages versions (e.g. pip freeze output)
   • mandatory small reproducible code sample
2. When a verifiable code example was provided, do not move the issue to the "discussions" immediately unless a maintainer says that the reproducible code sample is wrong.

[tomchristie]

No, thanks. This workflow works really well for us.

An initial "discussion" doesn't need to be treated as an actionable "issue" until it's been properly demonstrated.
When they do, we escalate them.

may be fooled by a small number of unresolved issues.

We're not in the business of "fooling" anyone. It's a good workflow for us, and keeps a better divide between "here's the actionable work we want/need" vs. "here's the discussion space".

Having worked on large scale open source projects over the last decade+ I'm far happier with how we're approaching this in httpx then I've been with any other approach, and I'm pretty confident that it's clearer for our users what we generally consider to be active/inactive.