Compatibility regressions and confidential documents

Several times in 3.6 (and 3.5) versions I have came across regressions where it is hard to reproduce the bug without sharing the original document that causes the bug in the first place.

Is there a way we could share problematic documents with the community - without them being available for all to see?

In this case I have received a .doc file that will not open in LO 3.6.3 (tested in Windows and Linux).

The file opens fine in Apache OpenOffice 3.4.1 and MS Office 2010…

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.

I would appreciate if a solution can be found.

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.

I try my best with reporting. If I am not wrong I reported yesterday about 5 and answered questions and added information for some bugs reported earlier. However, a day has only 24 h…

There are basically two approaches to this:

Eliminate confidential data from the document

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

This is the only way to have it handled in a legally binding way. (but still having signed an agreement doesn’t prevent that contracted person to break it and leak information either intentionally (bad guy) or by accident (stupid guy))
Unfortunately the Certification process is just in its early steps, so there is no list of capable/trusted companies yet, so I can only name the ones I know offer contracted work. Lanedo, SuSE, RedHat probably also Canonical (the linux distros rather being in the large-scale support)

This of course then will cost you money, but it will also make sure your bug is actually fixed. If you have a larger business with tiny quirks here and there that bother you, it might be worth a thought. For a one-shot bug the paperwork, etc might be too much…