The plans for the Grading System

[Brian Towers]

Surely the first thing to do is to establish the need (or not) for monthly publication of grades.

No, I disagree.
The first question to ask is something along the lines of "Is the current system fit for purpose?". If the answer is "Yes" then, as the old saying goes, if it ain't broke don't fix it.

Were the ECF a business (Oh, hang on ...!) the analysis would be fairly straightforward and go something like this:

The ECF's main "customers" are ordinary club players and the "product" is the grades and the grading system.
The calculation and storage of grades has been automated using a computer program and associated relational database which minimizes work in that area.
The collection and entry of data is manual with unpaid volunteers collecting and sending the information via email to one individual who validates the data and enters it into the system by hand.

This is labour intensive, relies heavily on the goodwill of an army of volunteers, is inflexible and is highly vulnerable to, on the one hand, the availability of volunteers and, on the other, a change to the relatively static "customer base". If volunteers start giving up, retiring or passing away then this will cause a crisis. If there were to be a massive surge in player numbers and / or games played without a corresponding increase in volunteer work then again there would be a crisis.

In other words the current system is designed for stasis and failure.

Then would come a systems analysis of what is there, what its shortcomings are, what is needed and how to get there. A much cut down version could look like this (and not being an insider this could easily be wrong):

Currently there is a backend consisting of an Access relational database with a VB6 program for manual data entry and calculation of grades.
There is a frontend consisting of a website which provides
1) capability for manual dowload of member details for all recorded members to provide volunteers with the backend data they require in zipped Excel format.
2) search facilities to allow members to see grading history and club affiliation for all members.

The main weakness of the current system is the manual collection and entry of data along with the single, human gatekeeper. When he is sick or on holiday data validation and entry stops (as happened recently!). The primary aim should be to automate this as much as possible. Many clubs and leagues already have software, in the form of league management software, which does much of the work.

The first step should be to automate validation and data entry to use data already entered and partially validated by existing LMS systems. On the server end something like an HTTPHandler to accept Xml data files posted to the server. These would be validated, processed and archived with error records recorded and flagged for administrator intervention. This should start to reduce the manual labour involved.

Since many clubs and leagues and possibly congresses won't have an LMS the ECF should provide an LMS with the appropriate ECF interface, either custom built or off the shelf. Ideally this would be free to clubs and congresses. Once this is universal the additional manual work in getting results into the system will be minimized.

As long ago as 17 years ago Microsoft were saying that their MS Access database was not suitable for multi-user applications because, in effect, it was not fully thread-safe. At the time they provided a free database engine called MSDE (MS SQL Server Data Engine). This meant that there was no excuse for using Access instead of MSDE. Today (and for something like the last 10 years or more) Microsoft give away SQL Server Express which allows databases up to 10 GB. Given the ease with which an Access database can be migrated to SQL Server (a few clicks in the DB management GUI - also free) there is no good reason to cling to a database which MS say may crash or give unreliable results if more than 5 simultaneous accesses are made of if high frequency access is made.

The grading database should be migrated as an urgent priority to a more modern and robust database engine.

VB6 is even more out of date and unsupported than FoxPro. The grading database code should also therefore be migrated as a matter of urgency.

Once a more robust backend is in place more advanced "data mining" features can be considered and implemented in the frontend without risk of crashing the brittle backend.

[Carl Hibbard]

You cannot host SQL server express cheaply hence very few people use it.

[Gareth T Ellis]

Carl Hibbard » Sun Feb 14, 2016 5:29 pm

You cannot host SQL server express cheaply hence very few people use it.

Carl, what sort of cost would it involve ?

[Carl Hibbard]

Carl Hibbard » Sun Feb 14, 2016 5:29 pm

You cannot host SQL server express cheaply hence very few people use it.

Carl, what sort of cost would it involve ?

I haven't done hobby Windows hosting for a while but it's more expensive for sure.

[Brian Towers]

Carl Hibbard » Sun Feb 14, 2016 5:29 pm

You cannot host SQL server express cheaply hence very few people use it.

Carl, what sort of cost would it involve ?

I haven't done hobby Windows hosting for a while but it's more expensive for sure.

That explains a lot, Carl, although I have to admit I've done even less than you.
What I have done is a quick Google search and the first (sponsored, no doubt) result gave me this - http://www.winhost.com/hosting-plans/basic.aspx which talks about charging $4 per month, admittedly for just half a GB of DB space.
Perhaps their top of the range offering - http://www.winhost.com/hosting-plans/ultimate.aspx - with 5 GB of database space would be more appropriate at $16 per month would be more useful.

Anyway, I'm deeply puzzled where you get your pricing knowledge from based on almost zero experience.

PS Perhaps Gareth was asking with the intention of undercutting whatever figure you came up with

[MartinCarpenter]

... which looks not dissimilar to how a grading submission file currently looks: the same data content; the same essential structure; just different formatting/syntax. My point was that I don't really think it's necessary (at this stage at least) to change the format of the submission and certainly not necessary (if this is what was envisaged) to allow different types of submission (a subset of an event's results say, rather than a full set of results).

The basic format wouldn't be very different. Same data

The big thing would be that its formally defined and verified vs that specification before being sent.

You can then build other checks into the software sending it - requiring verification if someone doesn't have an ECF number attached say, also things like (bypassable with modest effort) drop down lists for someone to insert the name of players/clubs etc to protect vs spelling mistakes.

Will still need a little manual checking at HQ for really odd stuff, but it should be much reduced. The person to ask how well this works from that perspective would be Jon Griffith - he's been doing the Yorkshire system for a few years.

I don't think that has to cope with different LMS's mind, everyone just uses chessnuts as there wasn't anything extant when that got set up and it works OK.

[Angus French]

... which looks not dissimilar to how a grading submission file currently looks: the same data content; the same essential structure; just different formatting/syntax. My point was that I don't really think it's necessary (at this stage at least) to change the format of the submission and certainly not necessary (if this is what was envisaged) to allow different types of submission (a subset of an event's results say, rather than a full set of results).

The basic format wouldn't be very different. Same data

The big thing would be that its formally defined and verified vs that specification before being sent.

You can then build other checks into the software sending it - requiring verification if someone doesn't have an ECF number attached say, also things like (bypassable with modest effort) drop down lists for someone to insert the name of players/clubs etc to protect vs spelling mistakes.

Will still need a little manual checking at HQ for really odd stuff, but it should be much reduced. The person to ask how well this works from that perspective would be Jon Griffith - he's been doing the Yorkshire system for a few years.

I don't think that has to cope with different LMS's mind, everyone just uses chessnuts as there wasn't anything extant when that got set up and it works OK.

My point is that all this API/XML talk seems to me like an unnecessary distraction. While there may be scope to automate the interface between LMSs and the central grading system, why is it necessary to create a new (API/XML) interface to achieve this?

There's already a specification for the current format of grading submission file and I'm pretty sure it works very well. An application, which is provided to local graders, checks that grading submission files adhere to the format. For what it's worth, it's legitimate for a grading submission file to contain results for players without a player reference (the central grading system will allocate references and return them).

[NickFaulks]

Everybody has the right to believe 3 impossible things before beakfast, except possibly the Members of the Qualification Commission.

Stewart,
This is already many pages back, but I've just found it. According to your own strict linguistic approach, "over 50" should mean at least 51. You are right, but in practice I don't mind the traditional extension to some people who are 50. What I do not understand is bringing in people who are 49. However many weird jokes you may crack, I doubt that I ever shall.

[Roger de Coverly]

There's already a specification for the current format of grading submission file and I'm pretty sure it works very well. An application, which is provided to local graders, checks that grading submission files adhere to the format.

To what extent can existing League Management systems automatically generate files in the required format?

If they can then little additional work would seem to be needed by local graders to submit data monthly. If that's not the case and they have to key elements of the data or paste it from one place to another that's where the problem lies. Clubs where the management system for their club tournament is a piece of paper in the equipment cupboard are a further difficulty.

It's easy enough to set up a spreadsheet to record results from a competition. How easy is it to transform such results into a format that the ECF grading system can understand ?

[Roger de Coverly]

What I do not understand is bringing in people who are 49.

Once upon a time, the International rating system published full dates of birth. Over time perhaps it was noted that it wasn't desirable to publish dates of birth for the attention of every fraudster and scammer. As a consequence the only published data was year of birth. Thus it's a 50/50 choice. Do you choose age next birthday or age last birthday? Notwithstanding that they use age last for juniors, they choose age next for seniors.

[NickFaulks]

Notwithstanding that they use age last for juniors, they choose age next for seniors.

This is sounding a bit actuarial, perhaps no surprise. One is "under", the other is "over". 19 year olds are absolutely banned from under 18 competition, and I find it consistent that 49 year olds should be banned from over 50 competition.

[Ian Thompson]

It's easy enough to set up a spreadsheet to record results from a competition. How easy is it to transform such results into a format that the ECF grading system can understand ?

One approach would be to use the spreadsheet the ECF supply for results submission to record your individual game results and then use the ECF Checker program to generate your tournament tables.

[Angus French]

To what extent can existing League Management systems automatically generate files in the required format?

If they can then little additional work would seem to be needed by local graders to submit data monthly. If that's not the case and they have to key elements of the data or paste it from one place to another that's where the problem lies. Clubs where the management system for their club tournament is a piece of paper in the equipment cupboard are a further difficulty.

It should be relatively easy to write the code to generate a submission file.

The file will still need to be put through the ECF's Result File Checker - both to check the format and to check the player details against the latest grading list file. The latter part can throw up candidate matches for players for which you don't have a Grading Reference. You might then need to investigate these further and then update your system and regenerate the submission file. Where a player doesn't have a Grading Ref and there's no match with an entry in the latest grading list, the central system will generate a new Ref - this will be sent back and you'll also need to update your system.

FWIW, the league for which I'm the controller also replaces estimated grades with January grades where they exist. Other leagues might do the same and this is a process which might want to run more frequently if there's a switch to monthly grading.

[Roger de Coverly]

The file will still need to be put through the ECF's Result File Checker - both to check the format and to check the player details against the latest grading list file. The latter part can throw up candidate matches for players for which you don't have a Grading Reference. You might then need to investigate these further and then update your system and regenerate the submission file. Where a player doesn't have a Grading Ref and there's no match with an entry in the latest grading list, the central system will generate a new Ref - this will be sent back and you'll also need to update your system.

All of which says that submitting monthly results would be rather more complicated than selecting "submit latest results for grading" and pressing OK.

[Kevin Thurlow]

"Surely the first thing to do is to establish the need (or not) for monthly publication of grades."

Yes - but one that most people are ignoring.

The so-called "consultation" should happen and address this very point.