One difference is that if I submit an issue, and it requires some back and forth to figure out the actionable improvement, then suddenly the issue is very noisy.

Whereas if it goes via a Discussion first, the back and forth happens elsewhere.

Arguably an separate issue could still do this, but it being a discussion sets the expectation better.

▲

g947o 10 hours ago | parent [-]

This kind of thing happens in Jira or any company's internal bug tracker, and GitHub Issues is not any different. If you want a certain kind of "hygiene", you can always do that in the existing system instead of inventing a whole different solution.

> Arguably an separate issue could still do this, but it being a discussion sets the expectation better.

People do that all the time in bug trackers.

	▲	evanjrowley 8 hours ago \| parent [-]
		As someone wearing the post-sales support hat for a non-OSS product, I appreciate use of "ready" tags in Jira. Unlike OSS, our engineers prioritize KPIs to be compensated for their work, and so we must find a way to track the triage discussions within Jira. In a significant way, Jira is solid proof that work happened, even if no actual code was pushed into the repo. If the support team has an unconfirmed bug that requires a technical deep dive, then the "non-ready" Jiras seem like a good fit. I'm open to a better way of doing this and would like to learn more about alternatives, but for now, this is how the teams engage.