Defining a standard on Contest Scoring

Foundations of Amateur Radio Not a weekend goes by without an amateur radio contest or six, each with its own objectives, audience, times, rules, exchanges and scores. When you get bitten by the contesting bug, you'll quickly graduate from using pen and paper to keyboard and screen. That process comes with the inevitable selection of software suitable to both run on your shack computer and log your particular contest since as you'll discover, not all software knows about all contests or runs on every computer. When you eventually do arrive at a working solution, you'll reap the rewards of using technology. Contesting software can help in many different ways. From logging your operating frequency and mode to tracking where other stations are active and it doesn't stop there. Type in a partial callsign and your software can suggest which ones it might be. Log a contact and you'll see if your contact is valid within the rules or not. Software can track your activity level and warn if you're exceeding any contest time limits. It can keep track of multipliers and the impact on your total score and at the end of a contest, contesting software can help with submitting your log. After you've done this for a while, you'll notice that contest rules and scoring change over time. That brings with it the possibility of your software using old and invalid rules for validation, scoring and other contesting requirements. In most cases, software is updated manually by the author to implement the latest rules. This means that authors are required to keep up to date with the rules for all of the contests that their software supports, let alone add new contests. There are a few applications that support the idea of a contest definition which suggests the ability for anyone to define contesting rules to use them within the application. Unfortunately their functionality is strictly limited and they are not sufficient to define every contest rule that is in use today. Sadly, flexible as they might seem, they're neither universal nor compatible with each other. One definition, written by one amateur, for one application, cannot be used anywhere else, never mind trying to determine what the latest version is. I strongly believe that we need a shared open standard that can serve contest organisers, contest software developers and contest participants. Before I elaborate, I will be explicit in pointing out that the intent is to standardise in a way that makes it possible to document all past, current and future contests and in doing so, provide a collaborative way to share contesting rules between organisers, software developers and contesters, not to mention awards committees and amateur associations. So, if such a contest rule standard were to exist, what would it look like? Until now, the approach has been to create a list of keywords and values that deal with particular types of rules, things like band start and stop, zone score, valid prefixes, power level, exchange, etc. The result is a growing but always incomplete list of keywords with no means to define any logic. At the moment, all the contesting applications manage any scoring logic internally, requiring that it's updated when any of the rules change. Not only that, the contest organiser has no insight into the mechanism and no means to validate the process. As a contest organiser, scoring hundreds if not thousands of logs is a whole different challenge. Many contests do this manually, rely on someone else's software, or if the contest is popular enough, write their own code to manage the process. All this effort creates a disconnect between the contester, the organiser and the contest software developers, each using their own definition of the rules of any particular contest. A different approach might be to implement specific rules in a universal programming language like say JavaScript, and use those to manage the scoring and validation logic specific to each contest. For example, you might define a function that returns the starting and ending time for a contest which gives you a mechanism to detect if the contest is happening right now. A contester could use it to determine when the contest starts and ends, but the same definition could be used by the organiser to determine if a submitted log entry is for a valid time. Another might be a function that uses a callsign to determine if it attracts points or not and if it does, how many. Contesting software might use it to change the colour of the screen to indicate an invalid entry, but an organiser might use it to exclude a contact from a log. You could have a function to determine if the exchange is valid, or what the next exchange number is, or if the frequency on which the radio is currently tuned to is allowed for a contest. You could combine some of these simple rules to determine, for example, if the frequency the radio is on is the same or different since the last contact and if that's permitted or not within the rules. As long as the framework in which this standard is defined is extensible, any contest could be defined in this way. If it's written well, contest organisers might be able to write their own rules using this standard and everyone can use the same rules for their own needs. You might recall that I've spoken about aspects of this problem before and at the time I suggested that an amateur radio standards body would be helpful. Failing that there's nothing stopping a few people collaborating in a discussion about how this might be implemented. As an IT professional outside my shack I have some ideas on what's needed and what could give the whole amateur community something useful, but unsurprisingly, I don't know everything. Working together as contesters we might come up with a better result. As a starting point, I've created a repository on GitHub called "amateur-contesting-standard" to start a conversation about this scheme and I would love to read your thoughts and see your ideas on how this might be achieved. If you'd like to get in touch, send an email to [email protected] or find my callsign on Twitter and GitHub. I'm Onno VK6FLAB