Closed for the following reason
the question is answered, right answer was accepted by
Alex Kemp
close date 2015-10-18 22:22:07.697660

Comments

You addressed a very important topic. I have several bugs stored because I cannot share the LibO file due to confidential content. Time to take out confidential staff takes me most often to much time. Thus, bugs are not reported.

How do you imagine that document will not be available for all to see? If you care so much about privacy, access of even one person will be critical for you. If not, what's the difference how many people access such document?

In fact, I think that if the problem is very critical for you, then you'll find time to hide confidential data and report a bug. Many people do it and it does not cause difficulties to them. Since you do not report a bug, problem is not so critical for you.

1 Answer

This is the preferred way, as then the document can be shared freely, but of course a modified document might not trigger the problem anymore, so this doesn't always work.

What you should always do when submitting a sample document:
Try to minimize it as much as possible. Delete first half of document, check whether the problem still occurs, if not, check whether it still occurs with the other half. Repeat with the half that still shows the problem until after deleting anything won't show the problem anymore.

To remove confidential data from a document:

check whether change tracking is activated and if so, clear it by either applying all pending changes or rejecting them. (Edit | Changes)

check whether the document is saved using multiple versions within one document (File | Versions)

Check document properties for confidential data (File | Properties)

change all the words to the word "word" or similar (File | Find and replace). Search for "[:alnum:]*" replace with "word" and make sure "[x] regular Expression" is ticked in the search options.

State that the document is confidential and wait for a request to mail it to a developer

This of course requires you to trust the developer, and for that you need to have a feeling for who actually is a developer and who is just a random person writing a bug-comment.

And this case of course is harder for QA and everyone else to check, so as an additional requirement in this case, you have to describe the characteristics of your document in the bugreport. I.e. is it rather big or small (in terms of wordcount as well as in terms of filesize/embedded objects), does it use lots of tables, graphics, OLE-stuff, other non-basic features? Is it using sections, etc... Any info that might allow QA people to see "ah, that sounds familiar, this could be bug xy that has a public document" or a developer "I know that one, xy did just fix something in that area".

Due to no written contract, this is based on the trust you have, and there might be legal restrictions for you to use that way (if the data is not your own).

Hire a contracted developer to fix the bug and have them sign a NDA or similar document