Thoughts on logging

"Not in log." Nobody wants to receive an answer to a QSL card request with those words. I can tell you firsthand that no QSL manager wants to send a note with the dreaded "not in log" notation, either. I've thought about logging a great deal over the last few weeks. I'll try to compress that thinking into this post.
I answered the first batch of QSL card requests about a week ago and they should have arrived at their destination by now. Nearly all who asked for a card got one, but, alas, a few did not. I've received email from some who were disappointed. One wrote to say,

I would say you are going to have some unhappy people with the “not in the log” contacts. I received mine back and my friend, {callsign}, received his back too. He and I both worked VP2MTC within 5 minutes of each other. We both live in {city} and work DX while talking on 440. But thanks for sending my SASE back.

If I were these guys, I'd be angry, too. In this specific case, I think it very likely that the fellows sending us the card may have worked Tom in those early hours. In those first few hours of the DXpedition, we did have some goof-ups. I believe I remember Tom coming to me sheepishly admitting that he may have accidently deleted (or otherwise lost) a small handful of contacts in his computer log. My response to him at the time was, to paraphrase, "stuff happens." What else could be said when Murphy comes to visit?
The above was an isolated incident. I have expressed my remorse and disappointment to these fellows. It really was a very unfortunate turn of events. But, if you make a few thousand contacts (or tens of thousands of contacts, as the big DXpeditions do) there are bound to be at least a few of them that don't line up. Some will be logged incorrectly. Some may even be deleted. All you can do is try to minimize errors through planning and try to spot troublesome situations on the trip before they cause damage.
As for the planning, we did a great deal. First, we created a planning document (I am making the first 2 pages available through this link) which described in great detail how the logging system would work on the island and after the trip. I had also worked hard to develop tools to put our log on the web at the end of each day. Both of these efforts, I now see, fell short. Let me elaborate.
The planning document was a very good start. It covered much of the mechanical aspects of logging well, but failed to cover the organizational aspects sufficiently. Here are some examples of things I should have included (and will next time):

• Valid call sign check - With tools like the QRZ ROM and the web-based call sign look-up services, it is inexcusable to hand off a log for daily consolidation without at least checking to see if all the QSOs are with valid call signs. Further, there were (and still are!) some call signs that were logged that are malformed. I'm not picking on anybody in particular here. In fact, I've been known to log a bizarre call sign once in a while! But, there should have been a mandatory review by the operator of all their logged QSOs before I accepted that log for consolidation.
• Consolidation should not be at end-of-day - This was probably my biggest mistake. There were late night operations and the last thing people wanted to do at the end of a very long day was fight with me over logging. I'm not sure if there is a better time, but I'm convinced there is no worse time! I think I might suggest that operators give me a clean log in the morning before they either start operating again, or before they take off for a portable operation. Perhaps things would go smoother if folks were rested and not bleary-eyed when they did their checks and log exports.
• Computer logging should be mandatory - unless it is a portable operation where it is impossible. There were probably hundreds of QSOs logged at the villa on paper that should have gone directly into a computer. This would have helped ensure times, dates, bands, and modes were accurate. We had trouble with errors in all these categories. Even if it can't necessarily help with broken call signs, computer logging solves many, many other problems.
• There should be peer reviews on logs - Chris and I actually did a great deal of this while on the island. He was tired, and I was pushy. He was patient, and I was, well, impatient. But we got it done and it was easier because we did lots of log checking as a team. One reads, one checks, make things go much faster and reduces errors. Given that I've advocated log review above, I believe it makes sense to assign "logging buddies" as part of team assignments. Now when you catch something stupid in the log, you can make fun of two people for being careless. {grin}
• There should be an explicit backup strategy - I took on this task myself, ensuring that the data collected was protected with backups (in multiple places). In retrospect, while this worked fine, I should have documented this process so it was part of the group planning and not just a personal assignment.

This particular trip was problematic with regards to logging for a couple of reasons. First, there were a large number of QSOs made from portable locations resulting in many pages of paper logs. Transcription from paper to the computer is rife with opportunities for error. My experience from paper logging on Georges Island and Field Day from NARA (just to name a few) has taught me that this is the most likely place to make a logging error (in the transcription).
Finally, the aspects of our planning that you might have thought would be problematic were not. There were four or five different computer logging programs used on the island by the team. All these program were able to export to ADIF and did so without incident. MacLoggerDX consumed those ADIF files easily. Interchange between computer programs was a breeze. The errors in our log were data entry errors by the operators, or accidental deletions. To paraphrase a common saying, "to really screw things up requires a human."