I write about GNU/Linux for a living. It always frustrates me when I make a mistake that makes it through my review process to the actual published article. Most often, it is a spelling error that I missed during my proofreading process. I recently decided that I had to find a systematic method of identifying errors BEFORE publishing my articles.
Quality assurance is the most important aspect of any endeavor, whether its is building safety systems into a state-of-the-art hybrid vehicle at Toyota, or writing articles that present accurate information about the GNU/Linux operating system.
In this edition of The Linux Week in Review, I will demonstrate how to use tools readily available in GNU/Linux to do quality assurance checks on texts before submitting them to a professor, publisher, code reviewer, reader, editor, or other authority. The principles that I will present are applicable to ANYTHING, not just writing.
Developing a Systematic Review Process
I have learned the hard way that quality assurance takes time, patience, diligence, and commitment. It means slowing things way down, and doing quality assurance in small manageable chunks. I have learned these lessons through thousands of hours of writing, proofreading, and also through trial-and-error. What I am presenting here is the best system that I have come up with, and the one that allows the smallest percentage of errors to get through.
Here are the basic principles of a quality assurance program:
Principle 1: Do quality assurance checks in small chunks.
If you try to proofread a 1500 word article on GNU/Linux powered tablets all at one time, it is almost certain that you will miss one or more mistakes. Here is what I do: I write one section of my article or paper at a time: the summary, for example. Then, I do a quality assurance check on ONLY that section. During the check, I am looking for spelling errors, grammatical errors, factual errors, and phrasing errors. After I complete the check, I assign the section a passing or failing grade. A section almost never passes my first time check. After the first check, I go back and correct errors, or I find a better way to word certain phrases. I then repeat the process until that section passes, and then I move on to the next section of the paper or article.
Principle 2: Check for precise acceptance and failure criteria. Checklists are the best proven method for completing quality assurance checks.
Vagueness breeds inefficiency, and inefficiency breeds failure. It is best to develop precise things that you are looking for during a quality assurance check. In a quality assurance check of written material, I only look for four very specific things: spelling, grammar, factual accuracy, and phrasing. The more precisely you define what you are looking for, the easier the checks will be, and the more mistakes you will find.
GNU/Linux is a great platform on which to develop a quality assurance (QA) program because it is free, popular, and it comes with a lot of free tools.
My tool of choice is LibreOffice Calc, but you could easily use Gedit, Nano, Pico, OpenOffice, Emacs, Koffice, Abiword, or any other tool that you feel most comfortable with.
Principle 3: Whatever tool you decide to use should be easy to build, easy to use, and easy to maintain.
Gone are my days of poring over documentation for hours to figure out how to use a program to create the tools that I need. If you cannot figure out how to use a program within 1 hour, it is probably not worth investing (wasting) your time in it. I was able to plan out and build a QA spreadsheet in LibreOffice Calc in about 10 minutes. I knew that I wanted to keep it simple: I wanted a checklist that was easy to build, and that would only take me a very short time to complete.
In LibreOffice Writer, it is very easy to add checkboxes to your spreadsheet by using the Form Controls toolbar. You can view the Form Controls toolbar in LibreOffice by going to View > Toolbars > Form Controls, as shown in Figure 1 below.
In the Form Controls toolbar, you left-click on the Check Box, and then paste the check box wherever you want it in the spreadsheet. By default, the check box has a label. I do not want this since the label actually shows up in the cell with the checkbox. I remove the label by doing the following: right click on the checkbox, and hit Control. A Properties box similar to Figure 2 below will pop up. Just scroll down and delete the contents of the Label entry.
The checkbox field has little green boxes around it. When you put your cursor on the checkbox, arrows pop up, and you are allowed to resize the checkbox field, or move it around. I like mine centered in the spreadsheet cell, but you can move it around in any way that you like. Once the checkbox has the characteristics that you want, you can simply copy it from that cell to all of the other cells in the spreadsheet where you want a checkbox. The final result should look something like Figure 3. I can print the checklist and use it on up to 13 articles before I have to print a new one.
1 note of warning: the checkboxes do not move automatically if you change the width of columns or the height of rows in the spreadsheet, so I recommend that you set the size of rows and columns to your desired values BEFORE you fill the spreadsheet with your checkboxes. Once it is filled with checkboxes, you should never change any size settings again unless you want to do a lot of rework.
Principle 4: Use the QA checklist as a generic template that is as flexible as possible. Once your work is done, it’s done!
The whole principle of the QA checklist is to save you work. Once you get the list set, you should not have to change it very much. Make it as generic as possible so that you can use the same QA checklist for a wide variety of jobs. If you want, you can even leave the sections of the checklist blank so that you can write them in after printing it.
Principle 5: Run through the entire document one last time after the QA checklist is complete.
Once all of the sections of my article or paper have passed the QA checklist, I read through the entire thing one last time. I pretend that I am reading the article as a reader would. If there are one or two mistakes that I missed, I will catch them during this final review. I will also experience the exact same things that my readers will experience while they are reading the article or paper. In this final read, I am really doing a QA check that I will call the “Experience Check”.
GNU/Linux and Free Software are great tools that can make our lives easier if we apply them efficiently. In the end, all that anyone cares about is the results that we produce. The best way in which to produce results consistently is to develop a systematic method of checking our work. Systematic methods produce good habits, and good habits produce works that are of a consistently high quality. Consistently producing high quality results is what wins in the long run.