Skip to content

General Notes K6DGW

Jump to bottom
K6DGW edited this page Mar 30, 2014 · 1 revision

I hope I'm doing this right. These are a summation of things from my notebook for the last several years that I think are applicable to the current effort.

Fred K6DGW

Hi All,

I don't think I'll be writing code for this project but I'll be glad to break anything you'd like me to try. A couple of general items:

a. I know nothing about GitHub, hopefully I'll learn

b. I came away from the 27 Mar meeting a bit concerned that several folk are already into code design and we have no process architecture and no real project plan. Or, possibly we have several undocumented process architectures in the heads of several people, one or more processes per head. :-)

I ended my so called "career" in systems engineering, mainly for the DoD in black projects working for a defense contractor. What follows are notes I've been making over the last few years from the perspective of a Human Adjudicator working with the output of Green, and as an observer of the results and events in a process I didn't have detailed visibility into for how the logs got to Green in the first place.

  1. CQP has always seemed to have a "Benefit of doubt goes to the operator" philosophy. I think this is a good philosophy, I think it is partially responsible for the popularity of CQP, and I think it should be continued as a general guiding philosophy for all aspects of the entire contest.

  2. More logs is better. Things we might do to the process that would decrease the number of logs we get is, generally, not a great idea. More CA logs is hugely better, and effort to improve CA participation is probably worth quite a bit.

  3. A major problem each year involves the various categories and sub-categories for each entry. The current Cabrillo spec does not include enough of the right tags to satisfy all of our needs. That could be fixed, it will take time and effort, but is a worthy goal, especially since we know Trey. :-) It is not a viable solution for 2014 however, maybe 2015.

  4. Even with a CQP Cabrillo spec, logging program modules must be modified by multiple authors to ask for the information and build the Cabrillo logs correctly and completely. In the case of WinTest, we'll have to get them to support CQP first. None of this is trivial, in fact it's probably way beyond "non-trivial," and not viable for 2014 and maybe not 2015 either [maybe never].

  5. Email submittals are unfortunately a "Fire and Forget" environment, even if we qualify received logs and send "Please correct the errors in your log" emails back to the operator. He's already crossed "Submit CQP log" off of his To-Do list, and a lot of folks won't add "Fix CQP log" to their To-Do list. Those that do are likely to put it at the bottom. The exceptions will likely be those who think they might win something, however those who think they are likely to win a category are also likely to submit a correct log in the first place.

  6. Assuming we remove direct email submittal from the equation, it looks to me like we have exactly one (1) engagement opportunity with the operator ... on the web site, when he/she tries to submit the log. Once that opportunity has ended [i.e. the op has moved on to another website, we've accepted the odds that he'll never respond to "please re-submit emails." We either tell him what's wrong right then, or we're not going to hear back from many once they abandon the web page, lowering the log and total QSO count [see #2 above].

  7. Were I building the architecture, except for the call sign, I'd ignore the Cabrillo header lines and ask for the information we need, as user-friendly as we can, on the log submittal website. Check boxes, radio buttons, "what's this" links to help with entry category rules, whatever ... but to submit your log you must answer or check all the info we need. Then paste in your log, header and all, and you go away. We ignore the header entries until we know all the loggers do it right. I'll likely be dead by then. :-)

  8. Feed back syntactic errors in the QSO: lines immediately. Don't let this single encounter we'll have with the op pass without a clear explanation of the problem(s) to him.

  9. If validation determines that the QSO: lines are missing fields, or the fields are in the wrong order, or fields appear to have inappropriate contents, the error message should include a prominent link to a page that tells the op what the error means and how to correct it.

  10. There will be situations where the errors in a log are systemic, like every SSB QSO has an invalid mode. Ideally, the system<-->user interchange would be something like:

    The mode "SSB" is not recognized in QSO lines. The correct Cabrillo entry for phone QSO's is "PH". Shall I change this in the log for you?

    "RTTY" is not a valid mode in CQP. I can change this for you if you tell me what mode those QSO's should be

    two checkboxes [PH] [CW]

Obviously this can only be done when the problem is systemic. However, as was pointed out in the meeting [by Matt, I think], we've seen a lot of these and there are some common ones.

The overall goal is to keep him engaged until we're pretty sure we've got all the info we need and the errors are fixed before he gives up in disgust.

  1. Audit trail: From my perspective, this has been a much overlooked part of the overall process. Once a log is accepted and a receipt number issued to the operator, the process must have an audit capability to assure that every accepted log can be tracked through the process steps ... and ... logs that don't make it through each step are flagged.

For 2013, we got all the way to human adjudication missing at least one large log and ultimately started over. I brought it up because I noticed that N6M was getting BYE's in all the logs, I looked and couldn't find it in the set of logs, and likely the only reason that meant anything is that I was on the N6M crew. And, when that kind of problem arises with one large log, it raises the obvious bigger issue, "Are there any others? How can we tell?" I'm not sure anyone else would have noticed it.

  1. Resubmittals: I think most people are accustomed to the idea that if you submit your log, later find an error, you can fix it and resubmit. The usual instruction is, "If you need to correct your log, just resubmit. It will replace any prior submittals," which is fine to the operator. We've already issued a receipt number [or sure should have :-)] for the first one, we now have two different logs and issue a different receipt number for the re-submittal [or sure should have], and maintaining an audit trail to assure that the first log gets quarantined and the second log enters the process critical. This is a whole lot harder that 110% of systems designers think it is. :-)

  2. Log Cross-check [i.e. Green Human Ajudication]: Green, when fed well-formed logs, does a great job of cross-checking logs, and I agree with Trey's comment that, for most logs [my insertion], it's not worth a lot of effort. However, I submit that with Green and the UI, it isn't a lot of effort, we need to do it when Green can't decide a winner on its own, and while band/mode errors are not dings in CQP, some of them do lead to NIL's instead. And, if we didn't do it in 2013, my crews log probably wouldn't have been scored. :-) If we didn't have Green, I'd probably accept Trey's observation and certainly not suggest that we build Green. But, we do have it, it works well, and I'd vote to continue human ajudication.

  3. Log Assignment Spreadsheet: The multi-access Google SS has worked "OK" for several years. Its biggest problem probably stems from the fact that each log checker has his own set of logs. Decisions made by one log checker that could affect one of my logs don't show up when I open the log. As long as he makes his comment on the SS before I get to that log, it works pretty well. Not everyone, however, goes back and rechecks logs that garners a comment after they've checked that log.

There is always one or two who sign up to check logs and then don't or can't. I made the mistake this year of initially marking them off in the other assignment column on the premise that it preserved as much of the original plan and organization. It was a misteak, and for those yet to do, I began moving them into my column.

  1. Logistics: Totally aside from getting and scoring logs, a major effort each year [and a large number of the ultimate problems that seem to delay getting done] involve the logistics of the initial promotion, getting the correct information for the winners to the right people in a timely manner, getting the awards produced -- correctly --, and getting them distributed. The impact on the log acceptance and scoring portion of the overall process is identifying winners and their scores. Unfortunately, it doesn't all happen at once, so once again, there needs to be some sort of "version control" on the reports produced by the log scoring part. That apparently didn't happen for the 2013 effort leading to K6YL's extreme frustration. While the logistics is separate from log scoring, that interface point needs some attention.
Clone this wiki locally