BenHenning
commented
1 year ago @KolliAnitha @seanlip @adhiamboperes @MohitGupta121
This is an idea I had to introduce an easier system long-term for filing new issues, and ensuring that the technical team receives all of the context that it needs for investigation. This would be a tester & alpha only feature (as we expect production users to provide feedback in the form of the in-app feedback system that's planned). I'm curious to understand your thoughts. Specifically:
@KolliAnitha as someone who's filed a large number of issues, do you see this as actually being a simpler or more convenient way to file them?
@adhiamboperes & @MohitGupta121: this is meant to be used both by QA testers and development team members. For the latter, do you think the approach mentioned would be viable for our less experienced contributors to do?
@seanlip do you have thoughts on the overall approach and whether it's worthwhile to implement? This could be a really nice future GSoC project as it's very self-contained and has clear milestone divisions (e.g. one milestone for the in-app data collection & UI features, and a second milestone for Firestore uploading, data management, and the action for reading & posting data).
adhiamboperes
MohitGupta121
Is your feature request related to a problem? Please describe. It's quite onerous to file bugs on GitHub today when manually testing the app. We have ways to make this much easier and streamlined for testers.
Describe the solution you'd like Two parts:
This is a feature that should be gated by a platform parameter as we'll likely want to enable it at least for test builds (but possibly for alpha builds in the future, as well).
From a technical perspective, it would be nice to capture all of the following information upon a bug report:
From a UX perspective, I think that the prompt should include:
Separately, I think integrating with something like https://github.com/square/seismic might be a good way to initiate the bug prompt (e.g. by just shaking the device) from anywhere in-app. As far as for crashes, the app already has an uncaught exception handler that can be used to capture the need for filing a bug report upon next app open (and then launch it at that point).
Describe alternatives you've considered From a UX perspective, the main alternative is manually filing issues (the status quo) which is definitely less efficient than introducing a way not only to make issues easier to file, but also ensure that the team is being given all of the necessary information to investigate the problem being reported.
Additional context Implementation for this feature is a bit tricky because of the following technical constraints:
The most obvious solution here is probably to leverage Firestore to hold the actual issue information, direct the user to file an issue with the base context pre-filled out (along with an identifier in-issue that points to the Firestore data), and then run automation that moves the data from Firestore to GitHub (possibly via Gist for images) and removes the data from Firestore.
I'd expect the Firestore data to auto-expire after short periods (maybe a week?) since there's no need to hold onto this data long-term once it's on GitHub. Directing the user to a URL to file the issue may also be slightly cumbersome as it requires them to log into GitHub on their mobile device, so an alternative may be to provide them the option to share the link with an application like WhatsApp or Gmail in order to send it to themselves on a different computer to file the bug. Some user research on acceptable flows among team members may be useful here to determine the best path forward.
As far as the mechanism for actually extracting the Firestore data, this can be done much more easily within GitHub Actions than on an actual device since we can provide secrets for Firestore & shared Gist access tokens, making image uploading much more viable and less prone to potential abuse. The automation could also work to generate a pretty output for things like the device and event logs, and then add them directly as a comment to the issue via summary tags. There's a lot of possibility in what can eventually be provided using this system, and it should make the barrier to entry for filing bugs much lower (just shake the device, open a link, and click submit).
Also a quick note: if the user isn't logged into GitHub when they open the link, it will prompt them to log in and will retain the URL (so none of the title or body information is lost).