parkrun is probably a much simpler model. Person X did run Y on date Z in time T is the bulk of it (you may think AUK's model is roughly the same but it really isn't)
Maybe that's how it should be. The event organiser can decide whether someone has done the important job of hitting the control points in time based on data gathered by the controllers/info control responses i.e. 'have they completed the ride', and then hands off yes/no to the AUK website for the purposes of generating the certificates. What more metadata is required for AUK purposes aside from the date of the ride, for awards season calculations?
Surely it can't be too intensive a job to have a module that crunches a member's finished/not finished data to render awards. That's something excel can do.
That's not the point I was making (and AUK doesn't record times, that's a complete red herring).
parkrun is simpler because you either did one of their things or you didn't. Their awards are based on a simple count of how many of their things you've done. It couldn't be any simpler.
The point I was making is that AUK's awards aren't a simple count of how many things you've done.
Rider has achieved award X if they've done this set of rides, of this sub-type or this sub-type but not this sub-type, within these dates, except these rides that are tagged like this, oh and one of the rides that could qualify could actually be made up of 2 different rides (a calendar ride and an ECE) so you need to take that into account.
Oh, and some awards have sliding time windows (i.e. a B25000 or whatever it is that has to be done over a 6 year period) so you need to check each possible sub group of rides to see if any subgroup qualify for the award, etc.
Oh, and for this award (RTTY) this ride can definitely count for this month or possibly be counted for the following month but it needs a human to confirm that at least 200km of the ride was done in the later month, etc, etc.
It's all possible, and made much easier if the underlying DB schema is designed with the awards and things like ECE in mind, but it's made much harder (to impossible) with bad schema design. More importantly it takes someone with knowledge of all of the little quirks and foibles of AUK to come up with a decent schema (and suitable schema design experience), the thought of having to communicate all of this to an outsider in order for them to come up with a suitable schema is a terrifying thought.
parkrun, by contrast, is simple set of SQL queries.
The bulk of AUK's results processing work is custom programming to determine pretty much each and every one of the awards. I don't have a problem with this. For a lot of people AUK is about all of these weird and wonderful awards and it'd be a shame to lose that going forward.
But, again, the awards are still only part of it. The AUK site manages and streamlines a lot of the organiser process that riders simply don't see. It can do more to help out with membership work (which is what Phase II was mostly aimed at). It can do so much more for presenting ride information to potential riders.