zlacker

>>xpe+(OP)
Is this fundamentally different than just using tags on issues to separate ready to work on things from initial user submissions?

>>cortes+Ud
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.

>>sleeke+2s
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.

>>g947o+tY
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.