zlacker

Is this fundamentally different than just using tags on issues to separate ready to work on things from initial user submissions?

>>cortes+(OP)
I feel like "technically, no" but "practically, yes".

Somehow the distinction of just adding a tag / using filters doesn't communicate the cultural/process distinction in the same way.

>>cortes+(OP)
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.

>>cortes+(OP)
Yes. Even for casual users looking for help, it’s nice to know that the “issues” tab is just real issues and not random, duplicated complaints and questions. Especially on a project like this that attracts a lot of attention and is highly sensitive to the user’s very specific environment. Most issues are going to not be bugs, or even something the maintainers can work on directly. Instead of trying to cram everything into Issues, why not use the underutilized Discussions tool? Now the Issues list is much more useful as an active tracker of workable items, and as a historical reference of relatively deduped problems.

>>sleeke+8e
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+zK
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.