Users sometimes solve tool errors after a bug report has been submitted. A directly reply email can always be sent back (and some users do send that email), but it is not obvious to user that this type of feedback is helpful or even possible since we state to not reply to the message.
It was suggested by @drpink that we could make the feedback simpler/more obvious to do if we added a link to the bug report itself to send in that feedback. If we do decide to add a link, bundle with a simple explanation sentence. Something like:
Has the problem been resolved? Cancel the request for feedback by clicking here: link
Where the link generates an email that is sent back to the galaxy-bugs mailing list. Ideally the subject line that will allow Gmail - and other email clients, when possible - to thread the reply back with the original bug report, instead of creating an email that does not thread, complicating match-ups between original bug reports and the "cancel feedback" message.
More ideas to enhance how reported bugs could be tracked/given visual cues in the UI, associated datasets tagged/assigned a new attribute about bug submission state, summarized in admin reports, and related: https://github.com/galaxyproject/galaxy/issues/5174
I guess a more tight integration into sentry would be great here. We could even indicate that this bug was reported before and these kind of things.
I wouldn't tie the implementation to sentry. That workflow does not work for everyone (i.e. many people still use email / would prefer github.) We could expose extra information in the error_report plugin methods, so when reporters are capable of it, they could share details like "known bug" or "new bug".
As far as I know sentry does not provide information to the bug reporting client that it is a known bug (because bug ingestion happens immediately, but classification / grouping happens "offline", out-of-process) so it wouldn't be possible to get this from sentry. The github reporter would be the only one which could support it.
I am not sure what the best approach would be, just wanted to state limitations:
We do not want to build our own bug tracking app and making the second email to 'thread' with the previous one in email clients sounds very tricky without it.
@martenson getting mails to thread is actually surprisingly easy.
You'd just add a header like Message-ID: thread-<job_id>@galaxy-server-fqdn and then any follow-ups would simply write In-Reply-To: <thread-<job_id>@galaxy-server-fqdn>
edit: just to add, any reasonable mail client should support that. And the follow up mails could use a message-id like thread-<job_id>-somerandomvalue@galaxy-server-fqdn or just not specify a message-id. Some links:
Most helpful comment
I am not sure what the best approach would be, just wanted to state limitations:
We do not want to build our own bug tracking app and making the second email to 'thread' with the previous one in email clients sounds very tricky without it.