Comment by g947o
10 hours ago
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.
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.