https://bugs.documentfoundation.org/show_bug.cgi?id=95039
--- Comment #13 from [email protected] --- Naturally, if the crash is reproducible, I will provide a backtrace. That's a given. Your two assumptions disregard many possibilities, including the most obvious one: that other people may experience the same issue and will add more details. One user already started doing this before the bug was erroneously relabeled as WORKSFORME. I have made no threats. Most of my clients are not willing to use software that exhibits hard crashes, that when reported, the response is the proverbial "don't let the door hit you on the way out". Furthermore, in good faith, a quality consultant cannot recommend such a product to any clients for production use. I'll take a few minutes of my time to explain best practices regarding software testing and development. I am available for trainings on this topic, although my schedule is completely booked for the immediate future. It is very common in the industry for software to have major bugs that are not easily reproduced This is nothing new. When such bugs occur, the best practice is to gather as much information regarding the circumstances of the bug. This typically includes software, hardware, and the steps the operator took when the bug occurred. My report is a good example of one that provides extensive details as to the steps that resulted in the product (LibreOffice, in this case) crashing. The best practice is also to gather as much information as possible as to the specific errors generated. Again, my report is a good example of one that provides such information. Now that you have a quality report, the last thing you want to do is shuffle it off into the "we will never look at this again" file. Best practice is to do exactly the opposite. Best practice is to request correlative data from other parties. An effective development team (which includes the QA department) will work to collect all other data that might be related to the issue. Such a team will also work to encourage users and developers alike to provide more supportive data. For example, some proactive firms will issue bulletins indicating that one customer is experiencing an issue, and request correlative data from other firms. Many serious bugs go unreported or under-reported. The onus is on the development team to gather more information about the bug, in order to fix it. The last thing a team wants to do is sweep bugs under the carpet. When that type of behavior is condoned, the quality of the product always declines. In response, the size of the user-base decreases as people find other solutions to meet their data processing needs. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
