Florian Reuter is a software engineer for Sun Microsystems and a contributor to the OpenOffice.org project. His particular interest is in the ongoing development of OpenOffice.org’s import and export filters for the .doc, .rtf and Word ML formats.
What follows is an exerpt from an interview Florian recently gave to Mad Penguin’s Christian Einfeld, highlighting the importance of end users submitting bug reports to help in the development of OpenOffice.org.
MP: You said earlier that you were helped out by end user bug reports. Many end users don’t really understand how they fit into your world as a developer. They don’t understand that there are developers out there who really do read their bug reports. What message do you have for simple end users about bug reports?
FR: If you have a Word document in .doc or .rtf or Word ML, and you use the current filter, and something goes wrong, even something not very noticeable, please submit the document as a bug document to OpenOffice.org, so that we can get a critical mass of documents that we can look at.
When we do the investigation of the file formats, we do it in the following way. We look at the basic engineering approach. We look at what happens, and we make an assumption. Then you have to see if your assumption is correct or not. The more documents we have, the more we can test whether our assumption is correct. The real value to me as a developer is having a huge amount of documents available so that I can check my hypothesis to see if it’s correct.
MP: Let’s break that down a bit. How does an end user help you out. What are the mechanical steps for submitting a bug document?
FR: Go to the OpenOffice.org website. Register as a user. You just have to pick up a user name. Enter your email address. Click on issue. Click on submit a new issue. Select the WW8 filter. Attach the file, and submit the bug. If possible, please also provide a description with what is wrong with the document.
MP: How is an end user going to know that there is something wrong with the document so that they need to do a bug report?
FR: That’s easy. If you document doesn’t look right, just go ahead and submit it as a bug. Let us worry if it is a bug or not. Don’t assume that you have made a mistake. It could be a bug.
If you use Windows, you can download a free Word viewer which will let you see what the document looks like. So you can download the viewer, view the document in Word, compare it to what OpenOffice.org looks like, and if it doesn’t look right, then submit it as a bug.
MP: Give us a little more detail about the value of bug reports. You mentioned something earlier about having lots of tables, and how that was helpful. Could you elaborate on that a little more?
FR: You need to have a critical mass of documents to either prove or disprove your current hypothesis as to how the Microsoft layout formatting works. As a developer, you see the differences at the edges of performance.
OpenOffice.org can import >90% of the documents correctly in 2.0. It is in the remaining 10% or 1% that some kind of magic happens, and you’re not sure what it is. You can only figure out what magic is making that work by looking at lots of samples. It’s only by seeing patterns in that small margin that you can get an idea of what makes the magic happen.
You need to have users making unexpected use of the application to figure out what is going on. As a developer, it’s hard to imagine all the different ways that something might be used. In computer science, having lots of samples helps us refine our hypotheses as to how to best import files from Microsoft Word. Real world samples make a big difference for us. It’s that way in most fields of science. You need to have a critical mass of data to test your theory.
So simple end users are really critical in the process of making the code better. It’s important for end users to understand how important they are in the process. That’s one reason why I enjoy working with the OpenOffice.org community. They help me do my job better. So thanks!
This work is distributed under a Creative Commons Attribution NonCommercial NoDerivs 2.5 license.