The naive approach is to have bug submission be part of the product you ship to customers. If you run into an issue - "a report has already been sent. If you want to follow the status of your report, click here <link with bug ID number>". If the user runs into an issue that doesn't trigger the automated bug report submission, then have a UI with the relevant questions, which can automatically attach stuff like application version number, OS version, etc.
The problem?
a) Pretty expensive to implement. You basically need to be FAANG with a huge install base and measurable reduction in customer service costs to justify the expense.
b) This pattern doesn't integrate well into developer workflows, i.e. if you try to automatically open a GitHub issue with it, then who opened the issue, a bot? How do you ensure users stay notified, even if they don't have a GitHub account? If the issue is a duplicate of an existing issue, how do you auto-subscribe the user to the existing issue? What if the repository is private?
You can't really come up with technical solutions to human problems. The human problem is that users need to be listened to, and you need to talk with them. Maybe it's a bug, maybe it's a feature. Maybe the user has an issue with their Internet access. Maybe the user didn't RTFM. You run into this problem with poor GitHub issues because GitHub issues is not a platform for Product, and you should not force it or expect it to become one just because it seems easier to do so when everything else relating to the open-source library is already there on GitHub.
GitHub Discussions is a step in the right direction, but GitHub's UI is currently lacking in terms of helping projects start to move Product and Customer Support into Discussions and creating a consistent user experience across projects for doing so.
Interesting you should mention about submitting details like app version number, OS version etc.
Although it's not within an app, and only partially automated, i tried building a tool to help people gather Python environment details etc to help them create richer Github issues with less effort: https://github.com/nmstoker/gatherup
The demo video needs work to explain it better and as a project it didn't really go anywhere but it was interesting to work on a few years back.
The problem? a) Pretty expensive to implement. You basically need to be FAANG with a huge install base and measurable reduction in customer service costs to justify the expense. b) This pattern doesn't integrate well into developer workflows, i.e. if you try to automatically open a GitHub issue with it, then who opened the issue, a bot? How do you ensure users stay notified, even if they don't have a GitHub account? If the issue is a duplicate of an existing issue, how do you auto-subscribe the user to the existing issue? What if the repository is private?
You can't really come up with technical solutions to human problems. The human problem is that users need to be listened to, and you need to talk with them. Maybe it's a bug, maybe it's a feature. Maybe the user has an issue with their Internet access. Maybe the user didn't RTFM. You run into this problem with poor GitHub issues because GitHub issues is not a platform for Product, and you should not force it or expect it to become one just because it seems easier to do so when everything else relating to the open-source library is already there on GitHub.
GitHub Discussions is a step in the right direction, but GitHub's UI is currently lacking in terms of helping projects start to move Product and Customer Support into Discussions and creating a consistent user experience across projects for doing so.