4 ms·
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
by sleekest 9mo ago
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 9mo agoThis 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 9mo agoAs 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.