Addendum 6 TD Tracking and Maintenance

Another of our time consuming and almost completely manual areas is TD Tracking and maintenance. Our organization tests and certifies the tournament directors that run our rated events. This module provides the resources to track, analyze, and document our TDs certification and performance.

TD Certification - A description of our TD certification standards is available on or web-site www.uschess.org and is also found in chapter 9 of the USCF's Official Rules of Chess or as a handout. The program needs to be able to keep track of the certification history for each level. The UA program has some capability in this area and the module should be able to access and update the necessary fields in the UA program.

TD renewal and upgrade - When a TD's certification is about to expire or a request to upgrade is received, research needs to be done for renewal and feedback purposes. One important piece of information is their performance in submitting reports on time. Another is any formal actions taken by the office and/or Tournament Director Certification Committee (TDCC). In order to easily accomplish this, the module should support the capability to record and retrieve significant actions associated with each of our TDs. I have suggested a file structure below to accomplish this but the programmer is free to use any appropriate methods to fulfill our requirements. A summary of his TD activity over the past to see if a re-test is needed. Additionally, a summary of the submission pattern over the past 2 years is needed.

TD Warnings and suspensions - We occasionally have TDs who make mistakes and have appeals filed against them. When a TD is very unprofessional, actions such as probation, suspension, or revocation of their certification can occur. These actions also need to be kept track of.

Data storage

The file I am recommending is designed to record and retrieve important interactions with a TD and allow easy retrieval of important categories of information. The file I recommend has the following fields. Through use of the code and date fields, important historical data can be observed such as the TD's history of renewals and upgrades can be retrieved. If the UA program does not support keeping track of current certification level, expiration date or the other data kept in the current accumulator fields, than an additional file or fields need to be created to support the necessary data.

Field	Comments
ID #	USCF ID number - Used to link to other tables
Date	Used to record date of action
Activity type code	Used to indicate type of action. Some common actions are T = test sent or received, F = formal action of some type. I = Informal action, C = contact or other general non-specific action, R = renew certification, U = upgrade certification, N = New TD. A null code or undefined code values should be supported.
Memo field	Used to keep notes and record specifics of actions.

When the TD update action is selected, a screen where the ID number is entered or a search by name is displayed. Once the specific individual is identified, the options for the listed codes are displayed to be checked by the operator. The date field is also displayed and a default value of the current date is used. Once the code is checked and date changed if necessary, the actions occur

T - (send tests) will ask for the level and test version. It will then auto-fill the memo field with boilerplate such as "sent <level> test, version <version>. It will allow the operator to then update another record, immediately print a form cover letter and mailing label, or postpone the letter and label creation until later for batch processing.

T- (received tests) will ask for the date received, test level, test version, score, and result. The memo field will be filled with the appropriate boilerplate to document the information. If pass is selected, the operator will be asked if the appropriate N, R, or U record should be created and display the proper values based on already entered values if yes is selected. Automatic updating of the certification level and expiration date in the membership files should also occur as a result of any of these actions. The option of immediate or batch processing of an appropriate form letter and TD card printing should be also be provided.

U, N, or R should follow the action concept for the T-received. Note that automatic updating of the certification level and expiration date in the membership files should occur as a result of any of these actions. One of the reasons for standardized boilerplate is to make searches for data in the memo field easier as the entries will have a standardized format as well as to insure all necessary information is entered.

Part of the upgrade/renewal process is evaluation of the TDs past history. The current program keeps track of this through accumulator registers and the problems with this have already been discussed. Ignoring what method is selected, when an upgrade or renewal is selected, the ability to verify the TDs history is needed. A screen should open and request if it is a upgrade or renewal, and for what level. A report should then appear that shows what events qualify based on the requirements for the level being attempted. The operator should have the ability to just search for qualifying events or to get a complete report of every event in the computer. The basic report will show

For Chief TD and a second section for ATD - Event ID, Event name, Event type (R or Q), # rounds, # players(total) sorted descending based on total players. Finally a summary should appear that shows the totals for category A, B, or C events for activity as Chief TD should appear. This report will be used to see if the applicant qualifies for the requested upgrade.

The second important report will provide an indication of problems with the TD. This report will provide a summary of the report submission timeliness as well as a list of the events actually run. The operator will be able to specify a range of years with a default of earliest year to current year. The summary will be grouped by year and show the following for each year based on CTD activity.

# of events submitted, # of events late (received date - ending date =>14 days), average submission delay ((received date - ending date)/# of events). The summary should also include contact activity for codes of F or I.

A detailed report showing all the events submitted ( event ID, name, rated date, and submission delay) sorted descending by submission delay will also be available and based on a range of years.