I also replied to this off list. We are consistent and that's good ;) Ultimately, we're not going to change our workflow. It's up to a user to report with clear steps and a simple test document - else it's just a waste of our time. Glad we all think alike :-D
Best, Joel On 07/14/2014 05:38 PM, Jay Philips wrote: > Hi All, > > I have found that asking for a document is the best way to get closest > to what the user is experiencing and what they are writing the bug for. > If they report the bug on windows, i load up windows to confirm it and > then also check if its on linux as well. Sometimes the steps to > reproduce are easy enough to follow, but not every one of us are experts > in the bugs we triage, so having an example file to begin the process of > triaging saves quite alot of time. Users i've been dealing with have > been quite happy to provide an example file, while a very few have asked > that the file be kept confidential. Here is an example bug with steps to > reproduce i triaged today [81292]. > > -------------------- > > Problem description: > I have a table first column alpha-numeric,crashes when sorting is ask. > Steps to reproduce: > 1. Load table, > 2. select table > 3. sort > > Current behavior: crash > > Expected behavior: alpha-numeric sorting > > -------------------- > > From this example, should i waste time that i could be spending triaging > other bugs to create a table full of values in order to sort the table. > It could be possible that some small feature within the table he is > sorting is causing the crash, that i could never reproduce because i > dont have his file. In the user's most recent comment, he states that if > he deletes the text from the last column, it wont crash. No way i could > reproduce such a thing if i created an example file myself. > > I just submitted a bug today [81351] that crashes calc from as early as > 3.6, simply by undo-ing a sort. It is possible that this may not have > happened with another file, so i submitted the one i was working on, in > order to speed up triaging and hopefully fixing. We have ~1k bugs to > still triage and the quicker we are able to triage a bug, the faster we > can confirm/close it and move on to the next one. > > Just my two cents. ;) > > Regards, > Jay Philips > > On 07/15/2014 01:48 AM, bfoman wrote: >> Hi! >> From my experience asking for an example file is the best way to triage for >> following reasons: >> - saves time - you can download the attachment and check it in different >> builds right away - important with current backlog in Unconfirmed bugs >> - reproducible case - sometimes when you follow the STRs and create document >> from scratch the bug can be gone. >> Users' files can have their history - be created in different build, envs, >> corrupted etc. So asking for a file is a best way to receive verified test >> case. >> - involve the reporter - some people tend to use Bugzilla as file and forget >> system. Needinfo stats tell a story... >> Bug reports with attachments are more interesting than those without them. >> Some reporters do even screencasts or special STR graphics to help the >> triagers. IMHO there is no need to panic that most triagers ask for them. >> Overall I think this is a good policy and reporters should be educated how >> good bug report should look like. >> If a reporter cannot spend few minutes to attach a file or make a >> confidential one into a public document (by search and replace strings - if >> that makes bug still reproducible), then how can he demand a fix? This >> cannot be made without a reproducible test case. >> BTW: Mr Manciot is active in Wireshark Bugzilla, so should be accustomed >> that good bug report needs attachment. LO needs users' files as much as >> Wireshark example frame captures... >> Best regards. >> P.S. >> As for bugs closed as Invalid or Worksforme - there are defined QA documents >> which describe how this process should look like. See >> https://wiki.documentfoundation.org/QA/BugTriage or >> https://wiki.documentfoundation.org/QA/BugReport. Most triagers respect >> them, but those rules are, well, more guidance than a strict policy. >> LibreOffice is powered by a team of volunteers, every bug is confirmed >> (triaged) by human beings who mostly give their time for free. Some people >> see things from different perspective and don't like to "babysit" stagnant >> issues. >> >> >> >> >> -- >> View this message in context: >> http://nabble.documentfoundation.org/Re-tdf-discuss-Intervention-tp4115537p4115583.html >> Sent from the QA mailing list archive at Nabble.com. >> _______________________________________________ >> List Name: Libreoffice-qa mailing list >> Mail address: libreoffice...@lists.freedesktop.org >> Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa >> Problems? >> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ >> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette >> List archive: http://lists.freedesktop.org/archives/libreoffice-qa/ >> > _______________________________________________ > List Name: Libreoffice-qa mailing list > Mail address: libreoffice...@lists.freedesktop.org > Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa > Problems? > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette > List archive: http://lists.freedesktop.org/archives/libreoffice-qa/ -- To unsubscribe e-mail to: discuss+unsubscr...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted