Description: Most crash reports come without any description, about the circumstances when the crash happened. People send in a crash report and expect it to be enough. It can be added afterwards at the bug-report website, but the numbers are quite low. So I would propose some-sort of - character limited - comment field, which can be filled before sending the report. Not all the comments will be friendly (I expect). So not sure how 'open' the access to the comments should be. Actual Results: Expected Results: Reproducible: Always User Profile Reset: No Additional Info:
I'm not sure adding the comment field would be a good idea. We would have to create the another value in the database and it would be tedious to check them, we get thousands of reports every month. Instead, I would propose to improve the wording and add clickable links to the dialog.
See the link in about dialog as a reference -> https://opengrok.libreoffice.org/search?project=core&q=buildIdLink&defs=&refs=&path=&hist=&type=
Is this enhancement request still valid? I doubt that user input will help to make LibreOffice better. Moreover you need man power to analyze and utilize the comments. If a user want give more information he/she is enforced to create a bug report with the crash ID. I don't think more is needed.
(In reply to Thomas Lendo from comment #3) > Is this enhancement request still valid? > > I doubt that user input will help to make LibreOffice better. Moreover you > need man power to analyze and utilize the comments. If a user want give more > information he/she is enforced to create a bug report with the crash ID. I > don't think more is needed. The bugtracker isn't to accessible. Registering, English only (with an international audience); certain requirements without really 'good' guidance. If you know what you're doing it's rather simple, but posting for the first time quite a hurdle, IMHO. The main idea: there are sometimes lots of crashes in the some area (if crash reporter would show to full stack; currently not the case), where some small comments could give some hints where to look. So if they crash reporter would ask for a small description this might help. A group of people assumes that the 'crash reporter' reports all what 'we' need to know to solve the problem. It's actually more used for statistics and sometimes a helpful BT. But conversion rate from crash report to bug report not great. And the people who make it from crash reporter to bug tracker (clicking the link in the reporter I assume) report the default fields most of time without any additional info However with the current quality of BT of the crash reporter it's pointless for sure. And if it would work is questionable too.. so going for NOTABUG