Evolving GitHub Issues

Post by ProxCoques » Wed, Oct 02, 2024, 7:57 AM UTC

mjw1007 wrote: post #30

I think the biggest weakness of github issues is that the main content it shows when you visit an issue page is the original report. That's very often unhelpful because: - it's likely that the actual problem wasn't understood at that point (it's likely to be describing a symptom, rather than a bug) - it's quite possible the original reporter wasn't very good at writing bug reports - issues often remain open after the…

Issues are a mess because they get used like bulletin boards for any random brain fart anyone has, despite Issue Templates trying to plead otherwise.

IMO the way to fix this is to gestate all issues in Discussions. Then, when a clear and agreed resolution is hammered out there, a maintainer creates an Issue (or just does a PR) referencing that Discussion. This would have the side effect of encouraging people to contribute to projects more when they can clearly see what needs picking up.

Post by mckn1ght » Wed, Oct 02, 2024, 4:00 PM UTC

ProxCoques wrote: post #89

skeptrune wrote: post #87

Earlier quoted context omitted.

Those work from a functional perspective, but don't solve the sticker shock of seeing "issues (852)".

Element is a great example with well over 3,000 open issues, most of which would be far better worked out in Discussions from which the maintainers could raise issues or PRs from whatever the outcome of the conversation was (if any). But they don't have Discussions because...

Yes, I mentioned Discussions in another comment, and that’s the other piece that makes Issues more usable, by siphoning away a lot of the noise that masks the signal. Take away all the me-toos, requests for updates, and discussions of similar phenomena that should be different issues, and Issues would get a lot better. An Issue should be: problem, forensic information, root cause analysis, solution, and record of work.

Re: Evolving GitHub Issues

Re: Evolving GitHub Issues