Searching for existing bug reports is a fairly random affair. If the current searcher fails to utilise any keywords the original reporter identified, they rarely find a match or the potential targets incorporate every aspect of LO. Would it be possible to make some form of process ID available with the menu choices - and the context menus - and compel reporters to include that process ID in the brief description? Searching for CALC LOC0001 - or whatever - increases the prospect of finding relevant issues about a million% and could just speed the process a tad. Also, we could all find it regardless of our first language
May even reduce the number of duplicated reports. Should that have been my primary motivation rather than simplifying identification? :)))
I'm adding this here because it is an issue impacting bug reporting. Every report requests the status of user profile reset Many reporters are subsequently requested to test with a user profile reset Clearly, the user profile environment is not sufficiently robust. I have no idea which component of LO causes all the profile corruption and I'm assuming a project to identify the root cause and implement procedures to reduce the fragility could be beneficial. Perhaps a permanent log file to identify any changes as they are made to the underlying options could help in both the identification and recovery from profile corruption. I have certainly experienced unauthorised profile amendments by simple version upgrades which include but are not limited to:- Lost Calc Sort Lists New sort lists in foreign languages My entire "view" profile with toolbar choices and styles obliterated Not once, in my recollection, has resetting my user profile, or running in safe mode, ever made any difference to the substance of one of my bug reports. Surely that says more about the profile weaknesses than anything else - especially as the responders are constantly having to suggest resetting profiles to eliminate these acknowledged inherent weaknesses. Imagine the productivity bonus if the responders had more faith in the profiles
(In reply to Colin from comment #0) > Searching for existing bug reports is a fairly random affair. > > If the current searcher fails to utilise any keywords the original reporter > identified, they rarely find a match or the potential targets incorporate > every aspect of LO. > > Would it be possible to make some form of process ID available with the menu > choices - and the context menus - and compel reporters to include that > process ID in the brief description? > > Searching for CALC LOC0001 - or whatever - increases the prospect of finding > relevant issues about a million% and could just speed the process a tad. > > Also, we could all find it regardless of our first language I guess "process ID" here would be .uno: command as in https://wiki.documentfoundation.org/Development/DispatchCommands I don't think we could ever compel normal reporters to include such info. It is more the area of quality assurance volunteers and staff to fine tune the data for discoverability. Meta bugs are one way of categorising and can sometimes be useful at a glance (Show dependency tree) https://wiki.documentfoundation.org/QA/Tracking_Bugs
(In reply to Buovjaga from comment #3) > (In reply to Colin from comment #0) > > Searching for existing bug reports is a fairly random affair. > > > > I don't think we could ever compel normal reporters to include such info. Perhaps "compel" is a little aggressive but if there is a "strong recommendation" to utilise the specific input field with a reminder to use it if the 1st attempt to post the bug doesn't have that ID field completed. I think (hope) people who are reporting bugs are as interested in a resolution as those more directly involved - Why else would they bother reporting it?
Also note that for crashing issues, crash reports already include a signature that makes it easier to link reports to each other, and metadata that contains the last 4 UNO commands used. See for example the Metadata tab in https://crashreport.libreoffice.org/stats/crash_details/e0ef61ce-4916-41f9-9d30-1f57c5cb1579 I understand that a precise ID would help the search queries, and that UI strings do evolve over the years, but I agree with Buovjaga here that the effort to get a "normal" user to provide such information would be as much (if not more) effort as the QA contributor doing it themself. We can't include these command IDs by default in the UI for obvious reasons, so the most efficient workflow would be to tell the bug reporter to "please include the ID by turning on an expert configuration option in the settings, restarting LO and repeating the steps". It might even scare off some reporters who already find Bugzilla daunting... Because the reporting of bugs is to be done in English, the command is usually easily identifiable. And if it isn't, QA contributors will add the name in English in the comments or summary – sometimes even with the corresponding UNO command. (In reply to Colin from comment #2) > Perhaps a permanent log file to identify any changes as they are made to the > underlying options could help in both the identification and recovery from > profile corruption. I'd recommend reporting this idea separately.