ANNEX L – SOME FINAL DOS AND DON’TS
DXPEDITIONERS
Make your cards clear and unambiguous – and print both the call-sign and the island name.
The call-sign should be the one used during the operation –the time for deciding whether to use /P, /number, prefix/ or /suffix is before the operation takes place, not after the operation and before QSLing!
If you need to print further batches of cards, don’t change the call-sign to fit card design. And, remember, always print the island name.
If you include the IOTA reference number (please do), make sure that it is correct!
If your licensing authorities allow you a choice, avoid using a call-sign that is more usually associated with a different DXCC entity or IOTA group within your country.
In the case of island names, use the one that is commonly shown on maps – don’t translate it from the local language into English, without also highlighting the original name. Don’t include anything on the card that could raise doubts that the operation might not have been land-based.
Don’t assume that everyone knows the exact location of
your island – if it is really small, add the geographical co-ordinates and / or additional information pinpointing it in relation to a larger island in its group or to an identifiable landmark on the coast.
If you include the island name on the computer label, it is best to validate it with a rubber-stamped verification mark and your initials across the corner.
Don’t handwrite the island name on a card. With our system of decentralised checking we have no easy means of ensuring uniform treatment of cards if individual Checkpoints are required to take a view on the authenticity of every handwritten endorsement, those genuine, suspicious and in between. Sorry, we have to reject them all, no exceptions.
If you use a multi-box card with island names (and IOTA numbers) printed alongside, use a method of marking the relevant island that does not allow card-tampering.
Try to send your cards as soon as possible after the QSO. The IOTA Committee receives a lot of complaints about poor QSLing performance. These often include requests that we remove all credit for a particular operation – yes, the rules allow us to do this in exceptional circumstances. We encourage slow or erratic QSLers to pay particular attention to this important aspect of IOTA. This said, there are many DXpeditions which perform well on QSLing and we know that the IOTA community appreciates their efforts.
IOTA APPLICANTS
Take special care, when entering your claimed credits on the on-line system, to record all the QSO details requested accurately. It is not fair on Checkpoints to expect them to spend their time correcting avoidable errors.
Submit cards that are clear and unambiguous – this means selecting ones that have a printed call-sign and island name.
If you have a choice, submit QSL cards from more recent operations rather than old ones. Expect that some ‘unique’ cards could cause problems over acceptance.
Don’t expect your Checkpoint to advise on ‘doubtful’ cards on the off-chance that they may be valid for an IOTA. Check the cards carefully against the islands listing in the Directory and, if necessary, the co-ordinates box given for the group.
Don’t ask your Checkpoint to break IOTA rules clearly stated in the Directory. If there is a problem with the card, sort it out with the operator or QSL manager. Normally they will want their cards to count for IOTA but it is their choice if they don’t.
And, importantly, do not bypass your Checkpoint by sending your query direct to the IOTA Manager or IOTA Centre.
IOTA CONTEST: ISLAND ENTRANTS
Check before entering the contest that the island from which you plan to operate qualifies for IOTA and make sure that the island name (not the group name if different) is entered in your log entry.
Remember, QSL cards need to have the island name printed on them. Handwritten endorsements are not sufficient.
Please reply to QSL requests. A lot of your contacts will be island-chasers wishing to increase their IOTA scores and your QSL could be the one they particularly need.
NOTE ON DATA-CLEANSING
A few words to explain our approach to ‘data-cleansing’ – removing the very small proportion of incorrect credits that inevitably accumulate in the database. IOTA Centre enters on this central database the call-sign of each credit given to a partic- ipant. In this way we have not only a permanent historical record of past activity but also, equally importantly, information on the scale of the operation, demonstrated by the volume and geo- graphical spread of participants’ credits, and often a means of identifying the operators involved.
What should we do when we hear or strongly suspect, on balance of credible evidence, that an earlier operation did not take place from a qualifying island, or took place from a different IOTA group than the one given on the card? We are sometimes in a difficult position that we cannot put into the public domain the full extent of our knowledge or doubts on the basis of available information. In such cases we feel under no obligation to give credit just because a card has been submitted. Furthermore, we cannot accept the viewpoint that IOTA should be run on the basis that a credit once given cannot be withdrawn. This would make a nonsense of programme integrity and place too heavy a burden of responsibility on Checkpoints. Worse still, it would make for inconsistency of treatment leading to valid complaints of unfairness.
Decentralised checking offers great benefits. But it does require the establishment of procedures for monitoring data-input centrally.
First introduced a few years ago, data-cleansing is now an established feature of management control. The procedure adopted is to delete credits that are definitely wrong but also ones that are strongly suspected of being incorrect. Many of these relate to unique credits, i.e. a credit which only one participant has on his / her record from an operation which IOTA Centre knows nothing about. Experience has shown that these are usually errors of some sort. Faced with the deletion of a credit, the participant should recheck his card and resubmit or replace it as appropriate. A card from a different, possibly more significant, operation may provide a solution. If we have made a mistake, we will be happy to correct it. However, please do not assume that such cases are always or mainly the Checkpoint’s fault. Data-cleansing is an IOTA Centre function, its purpose being to keep the database as free as possible of errors. If we are doing our job properly, errors will be identified on a regular basis and participants must accept this as a consequence of effective programme management.
In the past it has not always been possible to keep participants informed, but we will try to do so. Participants should understand the scale of the exercise facing the Committee and keep in perspective the likely small effect of this action on their scores. If participants ensure their database record includes a current e- mail address, the process will be simpler for everyone.
IOTA Centre’s maintenance of an effective procedure for check- ing data is one of the most important tasks now facing the Committee. Your cooperation and understanding of our reasons and method of doing this are appreciated.
No comments:
Post a Comment