Author Topic: AUK FINANCES AND WEBSITE PROJECT was: AUK CHAIRMAN STATEMENT  (Read 24055 times)

Re: AUK CHAIRMAN STATEMENT
« Reply #450 on: September 29, 2018, 08:37:43 am »
At least us normal folk know that AUK has loads of IT professionals and we can make allowances accordingly. 

I’d always wondered why you were all so weird, but had just assumed you were all GPs or actuaries.   ;)

POTD !

quixoticgeek

  • Mostly Harmless
Re: AUK CHAIRMAN STATEMENT
« Reply #451 on: September 29, 2018, 12:18:14 pm »
At least us normal folk know that AUK has loads of IT professionals and we can make allowances accordingly. 

I’d always wondered why you were all so weird, but had just assumed you were all GPs or actuaries.   ;)

Surely the hand writing on the brevett cards would be a give away ? :p

J
--
Beer, bikes, and backpacking
http://b.42q.eu/

Re: AUK CHAIRMAN STATEMENT
« Reply #452 on: October 15, 2018, 11:43:48 pm »
I've been adamant from the instant all this website hullaballoo came to light that the membership needs to be balloted on what we do.

FWIW I don't quite agree with this.

I wish that the board would do the right thing. I don't trust the membership to be able to be informed enough to make the right decision if it went to a ballot.

What I wish the board would do is stop at the end of Phase 1 and reassess. Don't fall for the Sunk Cost Fallacy and throw good money after bad with Phases 2/3.

Look at what really is the problem (the current infrastructure is shaky) and the proposed solution (which does not change this) and realise that it is pointless to continue with Phase 2 or 3 as it stands.

Phase 1 has cost enough and scared enough people that a proper rethink is required. Balloting the members suggests that there is a viable alternative plan, there isn't yet.

This.

Manotea

  • Where there is doubt...
Re: AUK CHAIRMAN STATEMENT
« Reply #453 on: October 16, 2018, 12:25:13 am »
What I find difficult is the absence of any sense of vision of what the new website is supposed to achieve, what functionality and benefits it will offer members and the delivery programme.

The vision thing is especially important because if you're selling the family silver to pay for a system then you have to be focused on the long term, looking to develop a system that will be relevant in 5 or even 10 years time. That in itself requires a fairly solid vision of the future of Audax UK and how it will present itself in an increasingly online world. If a purpose of the website is for example to help promote audax - and help orgs promote their events - where are the photo galleries and social media elements? Yes, anathema to some but absolutely essential in the modern world (and standard elements of a modern website).

Its not unreasonable to expect this to have been nailed before issuing contracts and for it to be communicated to the users/members/customers. All we've had is a few column inches in Arrivee and the odd forum post, mostly consisting of statements to the effect of, 'we've gotta have it and very little of this has anything to do with you'.

Meanwhile the budget (so far as can be ascertained) has gone from a nominal £150k to a projected five year (additional) spend of £500k or more. A large chunk of the current overspend seems might have been avoidable either by stronger project/supplier management and/or by taking an approach which didn't neccessitate wholesale integration with old/existing systems.

At the end of the day, instead of having a complete solution/service we'll have a shiny front-end website developed and maintained by costly contractors who we are essentially going to be paying forever for every minor enhancement/change to come, whilst club volunteers will continue to kept busy (re) developing and maintaining  the backend database to facilitate the website. (Was it not part of the rationale for the project to allow the club volunteers to retire, i.e., to avoid being dependent on just one person? AUK ought to put up a statue to Francis for all he has done and is continuing to do for the club.)

The really worrying thing is that what has been implemented to date is relatively straightforward webstuff. All of the more technical elements are yet to come, so assertions that the later stages will not incur similar cost overuns seem naive at best.

I don't doubt that a vast amount of work has been put into this project by volunteers but much of the return will be lost if it is misguided.

The real tell is that those most involved with this project mostly want out. That does not bode well for the future.

Re: AUK CHAIRMAN STATEMENT
« Reply #454 on: October 17, 2018, 10:48:58 pm »
Manotea is so right. When I got the ‘offical’ Email I replied but no response. Which is ok but does feel like part of the problem. The new site has to be about customer service, us as members being the customer!  Whilst the present site has limitations and I suspect mainly from the organisers position. It allows us to choose our events, pay on line, download gps or route sheets, has maps of the courses, it ain’t bad.

I am not a techie, but I do run a 70m turnover transport organisation and our website, with journey planners, live tracking, etc does not come close to the numbers being spoken about. I value the people running our club....... makes me sad.

Re: AUK CHAIRMAN STATEMENT
« Reply #455 on: October 17, 2018, 11:27:11 pm »
When I got the ‘offical’ Email I replied but no response.

Really?

Did you think that the volunteers at the other end have the time to answer all the emails they have coming in? (I do not doubt that your's was better than everyone else's and deserved to be replied to which I understand)
www.milehousebarn.co.uk - Cycle Frienldy B&B in Nantwich, Chehsire

Re: AUK CHAIRMAN STATEMENT
« Reply #456 on: October 18, 2018, 07:50:14 am »
...Whilst the present site has limitations and I suspect mainly from the organisers position. It allows us to choose our events, pay on line, download gps or route sheets, has maps of the courses, it ain’t bad...

You might have missed the posts made earlier suggesting that the present site could collapse at any moment, and relies on a very small number of people (probably numbering less than 2 in a lot of cases) to keep it going.

LittleWheelsandBig

  • Whimsy Rider
Re: AUK CHAIRMAN STATEMENT
« Reply #457 on: October 18, 2018, 08:06:56 am »
Along with the posts from those folk noting that there are cheaper alternatives to the current approach.
Wheel meet again, don't know where, don't know when...

Manotea

  • Where there is doubt...
Re: AUK CHAIRMAN STATEMENT
« Reply #458 on: October 18, 2018, 08:39:53 am »
You might have missed the posts made earlier suggesting that the present site could collapse at any moment, and relies on a very small number of people (probably numbering less than 2 in a lot of cases) to keep it going.

All sorts of things have been suggested....

The actualite is The One (shall we call him "Neo", though perhaps, "Paleo" might be more appropriate... these are the jokes, you may as well laugh... :) ) has stated that the current system is quite stable, and that from his perspective the major issue is that it is based on aging tech which makes development and maintenance problematic. This might have been addressed years ago however any such development work was shelved because of the pending new system.

As is, there is more than a suggestion that the 'new website (a.k.a., 'The Shiny') is simply a front-end to the existing system, that AUK admin will continue to be dependent on the existing system, and that extensive development to the existing system will be required to faciliate further development of 'The Shiny'.

Throw in the scope for problems arising from different elements of the system being developed and maintained by disparate groups with completely different priorities and working methods, and from an armageddon perspective its hard to see how we're any better off.

Re: AUK CHAIRMAN STATEMENT
« Reply #459 on: October 18, 2018, 09:09:33 am »
Manotea is so right. When I got the ‘offical’ Email I replied but no response. Which is ok but does feel like part of the problem. The new site has to be about customer service, us as members being the customer!  Whilst the present site has limitations and I suspect mainly from the organisers position. It allows us to choose our events, pay on line, download gps or route sheets, has maps of the courses, it ain’t bad.

I am not a techie, but I do run a 70m turnover transport organisation and our website, with journey planners, live tracking, etc does not come close to the numbers being spoken about. I value the people running our club....... makes me sad.

(My bold in the embedded quote)

The customer vs member question is a key one.  Were we ‘customers’, then it would be a case of take it (the price rise resulting from throwing c. £0.5m of good money after bad) vs. leave it.

However, many of us (can’t speak for everyone, but perhaps it’s all rather than many) had understood we were members of a club. As members of a club, we should have the right to vote on whether our membership fees should rise. We used to have that right. The Board (via a vote, but a vote in which members were advised that nothing substantial was changing) has removed that right.

YMMV, but in my view we have been reclassified from members to customers without the courtesy of either being notified or given the choice.
R10000 x 2   RRtY x 6    SR x 7    E = 128

Re: AUK CHAIRMAN STATEMENT
« Reply #460 on: October 18, 2018, 10:23:45 am »
So I emailed Richard the IT director this list of functionality asking where it fit into the project phases:
Quote
- Event entry and payment
- Event creation/admin/etc for organisers
- Event results database
- Points tables etc
- Calculation of awards etc (the ones AUKweb currently does automatically)

Here's the reply in full (my bold):
Quote
We originally carried out functional analysis on rationalising Calendar / Perm / DIY payments and workflows for organisers and riders.  Which includes the points you raise.  Unsurprisingly it is complex, and as the note explains, the recommended development strategy was not to start by re-developing the back end - high cost / high risk.  The agreed phasing is:

Phase 1 is read only replacement for the CMS element of AUKWEB, with a membership dashboard.  Part of the cost problem was that even simple looking routines were building data from the original unstructured data in AUKWEB.  We underestimated the amount effort required.  Since then Francis Cooke has restructured the results data which will be a huge help going forward.   

Phase 2 will be membership management. 

Phase 3 is end to end rationalisation of all the different event types.  This is where your points will be tackled.  We haven’t started to think about the best way to do this, there are many development options.  We need to complete the current phase first.

So, to clarify, by the end of Phase 2, we will:
  • Have spent £240,000
  • Still be 100% dependent on AUKweb for things as basic as entering events or creating them.
  • Have no money in the kitty
  • Be paying £27,000/year in support costs, and thus never have money in the kitty ever again
  • Be required to believe that Phase 3 will only cost £100,000, despite consisting of all of the complex bits that have been put off from phase 1

The stuff in some of the board papers about Phase 3 just being "some DIY stuff" or whatever now strike me as completely fraudulent. Phase 3 is where the core hard bits get done!

This is much more than an IT project gone a bit over budget, this is discovering your senile grandparents have handed over their house to a door-to-door salesman level of intervention required.

Ben T

  • What you saying, then?
Re: AUK CHAIRMAN STATEMENT
« Reply #461 on: October 18, 2018, 10:36:30 am »
And let's not forget all the complexity is purely so Ernest Higgins can check how many perms he did in 1986.
If you'd started from square one with a new database with no requirement to import legacy data it would be a fraction of the cost.
Why is legacy data so important? Just keep your brevet cards or better still maintain your own spreadsheet or use strava if you're that bothered. Personally I don't give a toss how many rides I did years ago. I can remember the ones I can remember, the rest obviously weren't that memorable.
This is destiny, it's fate, it's the matrix working in my favour.

Re: AUK CHAIRMAN STATEMENT
« Reply #462 on: October 18, 2018, 10:51:48 am »
And let's not forget all the complexity is purely so Ernest Higgins can check how many perms he did in 1986.
If you'd started from square one with a new database with no requirement to import legacy data it would be a fraction of the cost.
Why is legacy data so important? Just keep your brevet cards or better still maintain your own spreadsheet or use strava if you're that bothered. Personally I don't give a toss how many rides I did years ago. I can remember the ones I can remember, the rest obviously weren't that memorable.

That's only a fraction of the problem.

The bulk of the work related to results/awards is creating the schema for storing results data and the work needed to allow awards to be defined with minimal (ideally none) code changes (only changes in the awards DB) when new awards are devised, i.e. the awards themselves are not hard coded. This will all need to be done whether legacy data is imported or not if the new system is going to keep track of results and awards.

Once that's all done, mashing the legacy data into the new schmea format and importing it, and tweaking the system to produce the correct results is a relatively small chunk of work.

The only saving would be if the new system did not automate the tallying of awards (and/or results at all).
"Yes please" said Squirrel "biscuits are our favourite things."

Re: AUK CHAIRMAN STATEMENT
« Reply #463 on: October 18, 2018, 11:00:12 am »
Why is legacy data so important?

Because the scope of Phase 1 doesn't include any of the tools to create or manage event listings (or anything else) - it's "read only". The only way to get events into the new front end is to use the AUKweb tools to put them into the AUKweb database. Thus the "legacy data" includes events that haven't happened yet, or even been thought of yet! Nothing whatsoever to with legacy data from 1986*.

Arguably starting afresh with a new database might have been a better plan, but would also have required writing new management tools at the same time. In any case, importing the legacy data into that new database would have been a relatively trivial task.

The issue to me is that they've ignored that we already have working code that can read the existing data, and instead of using that, they've paid a very expensive team to recreate that code from scratch in a new language, apparently without consulting the old code to see what it did. This is the only way I can explain how they ended up burning £100+k bolting a basic event listing system onto an off-the-shelf CMS.

(* and the new front end doesn't even have a results listing feature AFAICT)

Re: AUK CHAIRMAN STATEMENT
« Reply #464 on: October 18, 2018, 11:07:51 am »
Here's the reply in full (my bold):

Interesting, thanks for doing that.

That and my other reading seems to confirm my suspicions about this project as a whole.

I'm still torn on what to do. Part of me wants to help AUK minimise the possible fuck-up in the future by helping get the existing code into a better shape (to make future integrations easier and to avoid security nightmares from running code that doesn't run on the most recent versions of the underlying software), but the other part of me is loath to do this whilst AUK is seemingly pissing money up the wall.

Sitting back and watching AUK implode due to spiralling IT costs for a misplaced vanity project might not be what is best for AUK.
"Yes please" said Squirrel "biscuits are our favourite things."

jiberjaber

  • ... Fancy Pants \o/ ...
  • ACME S&M^2
Re: AUK CHAIRMAN STATEMENT
« Reply #465 on: October 18, 2018, 11:19:04 am »
As risk mitigation and improving certainty of scope/costs on Phase 3, perhaps a volunteer team could start work on a new schema now and then that could be used to narrow the scope of Phase 3?

Surely there is a target architecture for the end solution?

Some of my understanding with the legacy data problem is that a lot of awards were 'hand crafted' rather than machine crafted (eg: RRtY rides been user selected for particular months rather than the month they appear in within the results for example)  I wouldn't see there a need to re-calculate awards/results from the legacy data but to be able to report on it.
Regards,

Jason

frankly frankie

  • I kid you not
    • Virtual Alps
Re: AUK CHAIRMAN STATEMENT
« Reply #466 on: October 18, 2018, 11:32:00 am »
And let's not forget all the complexity is purely so Ernest Higgins can check how many perms he did in 1986.
If you'd started from square one with a new database with no requirement to import legacy data it would be a fraction of the cost.

Not wishing to derail an otherwise interesting discussion, but once you have an event Entry system maintaining a Results system is quite trivial - Entries and Results are two sides of the same coin.
At its barest bones, an Entry is just a EventNo/MemNo pair of fields.  A Result is just the same pair of fields with a third one added to show the status of that ride - Started, Finished, Validated whatever - you could even build simple Tracking into that 3-field schema.
Even when fleshed out with other stuff to deal with non-members, off-date rides (eg helper rides) etc etc, the Results table is a very simple thing.  Assuming one row in the table = one ride, the Awards lists are simply queries on that table, the queries can sometimes be very complex but that's no big deal, they're all stored.
"This is a complex subject, with a need for more than one highlighter pen."

citoyen

  • Cat 6 Racer
Re: AUK CHAIRMAN STATEMENT
« Reply #467 on: October 18, 2018, 11:42:54 am »
And let's not forget all the complexity is purely so Ernest Higgins can check how many perms he did in 1986.

Is it really? Surely it's the current membership and events management/planning elements of the site that are the real cause of the complexity?

If Phase One is all about making a shiny new website, that sounds relatively trivial. However, even with my limited expertise in this area, I can see that making a new website interact with a live and constantly updating membership and events database that is based on outdated technology would be far from trivial.

So the options are either rebuild the database from scratch (mental) or try to make the new website work with the existing database (complex). Neither option is ideal.

The fact that the database contains a lot of legacy data about historic rides sounds like a bit of a red herring. Maybe I've misunderstood what is actually happening but I can't believe that preserving legacy data about historic rides is that high on the priority list, and I would have thought that kind of data could be parked and dealt with later if necessary.

Ben T

  • What you saying, then?
Re: AUK CHAIRMAN STATEMENT
« Reply #468 on: October 18, 2018, 11:44:01 am »
And let's not forget all the complexity is purely so Ernest Higgins can check how many perms he did in 1986.
If you'd started from square one with a new database with no requirement to import legacy data it would be a fraction of the cost.
Why is legacy data so important? Just keep your brevet cards or better still maintain your own spreadsheet or use strava if you're that bothered. Personally I don't give a toss how many rides I did years ago. I can remember the ones I can remember, the rest obviously weren't that memorable.

That's only a fraction of the problem.

The bulk of the work related to results/awards is creating the schema for storing results data and the work needed to allow awards to be defined with minimal (ideally none) code changes (only changes in the awards DB) when new awards are devised, i.e. the awards themselves are not hard coded. This will all need to be done whether legacy data is imported or not if the new system is going to keep track of results and awards.

Once that's all done, mashing the legacy data into the new schmea format and importing it, and tweaking the system to produce the correct results is a relatively small chunk of work.

The only saving would be if the new system did not automate the tallying of awards (and/or results at all).

Oh I see, so it's about the system automatically recognising when someone has won an award.
That's not exactly rocket science.
I would model it as something like:
AwardDefinition
  Name
  Type
  RideCollectionRequirement[]

RideCollectionRequirement
  DateTimeScopeRequirement
  RideTypeRequirement
  CountRequired
  DistanceRequirement
   
RideDefinition
  Date
  Type
  Distance

So e.g. an award definition has a collection of ride requirements. Each ride requirement has a time span in which the matching rides must be completed, how many rides of that type are required, and what distance they are required to be. So a simple SR would be:
[
{DateTimeScope: WithinSameYear, RideTypeRequirement: BRM, CountRequired: 1, DistanceRequirement: 200},
{DateTimeScope: WithinSameYear, RideTypeRequirement: BRM, CountRequired: 1, DistanceRequirement: 300},
{DateTimeScope: WithinSameYear, RideTypeRequirement: BRM, CountRequired: 1, DistanceRequirement: 400},
{DateTimeScope: WithinSameYear, RideTypeRequirement: BRM, CountRequired: 1, DistanceRequirement: 600}
]
Fairly easy from there to write a matcher that detects new award won when a ride is entered.
There you go - job done, can I have a hundred grand?  ;)

And let's not forget all the complexity is purely so Ernest Higgins can check how many perms he did in 1986.
If you'd started from square one with a new database with no requirement to import legacy data it would be a fraction of the cost.

Not wishing to derail an otherwise interesting discussion, but once you have an event Entry system maintaining a Results system is quite trivial - Entries and Results are two sides of the same coin.
At its barest bones, an Entry is just a EventNo/MemNo pair of fields.  A Result is just the same pair of fields with a third one added to show the status of that ride - Started, Finished, Validated whatever - you could even build simple Tracking into that 3-field schema.
Even when fleshed out with other stuff to deal with non-members, off-date rides (eg helper rides) etc etc, the Results table is a very simple thing.  Assuming one row in the table = one ride, the Awards lists are simply queries on that table, the queries can sometimes be very complex but that's no big deal, they're all stored.

Yep, absolutely. (In my example above, 'RideDefinition' is analogous to 'Event', and 'Ride' would be synonymous with 'EventCompletion'.)
This is destiny, it's fate, it's the matrix working in my favour.

frankly frankie

  • I kid you not
    • Virtual Alps
Re: AUK CHAIRMAN STATEMENT
« Reply #469 on: October 18, 2018, 11:51:03 am »
Quote
{DateTimeScope: WithinSameYear, RideTypeRequirement: BR, CountRequired: >=4, DistanceRequirement: >=200},
{DateTimeScope: WithinSameYear, RideTypeRequirement: BR, CountRequired: >=3, DistanceRequirement: >=300},
{DateTimeScope: WithinSameYear, RideTypeRequirement: BR, CountRequired: >=2, DistanceRequirement: >=400},
{DateTimeScope: WithinSameYear, RideTypeRequirement: BR, CountRequired: >=1, DistanceRequirement: >=600}

FTFY [and edited]
"This is a complex subject, with a need for more than one highlighter pen."

Ben T

  • What you saying, then?
Re: AUK CHAIRMAN STATEMENT
« Reply #470 on: October 18, 2018, 11:53:04 am »
And let's not forget all the complexity is purely so Ernest Higgins can check how many perms he did in 1986.

Is it really? Surely it's the current membership and events management/planning elements of the site that are the real cause of the complexity?

If Phase One is all about making a shiny new website, that sounds relatively trivial. However, even with my limited expertise in this area, I can see that making a new website interact with a live and constantly updating membership and events database that is based on outdated technology would be far from trivial.

So the options are either rebuild the database from scratch (mental) or try to make the new website work with the existing database (complex). Neither option is ideal.

The fact that the database contains a lot of legacy data about historic rides sounds like a bit of a red herring. Maybe I've misunderstood what is actually happening but I can't believe that preserving legacy data about historic rides is that high on the priority list, and I would have thought that kind of data could be parked and dealt with later.

Maybe legacy data isn't the complexity - maybe the complexity is a rod has been made for AUK's back in terms of 'when do we start using the new system instead of the old'.
The way I would have tackled it would be swtich everthing over at once - get the new system fully working, including putting events in and entering them, fully tested, and then switch over. That way you don't build in a requirement to use the legacy data.
Once the system is fully tested and working - pick a date, any event occurring after that date is scheduled, and entered, in the new system. Any event occurring before that date is scheduled, and entered, in the old. There would obviously be a short time when people are using both the new and the old system, but I don't see as that being a problem.
This is destiny, it's fate, it's the matrix working in my favour.

Ben T

  • What you saying, then?
Re: AUK CHAIRMAN STATEMENT
« Reply #471 on: October 18, 2018, 11:54:26 am »
;D
yes obviously, and
Quote
{DateTimeScope: WithinSameYear, RideTypeRequirement: BR, CountRequired: >=4, DistanceRequirement: >= 200},
{DateTimeScope: WithinSameYear, RideTypeRequirement: BR, CountRequired: >=3, DistanceRequirement: >= 300},
{DateTimeScope: WithinSameYear, RideTypeRequirement: BR, CountRequired: >=2, DistanceRequirement: >= 400},
{DateTimeScope: WithinSameYear, RideTypeRequirement: BR, CountRequired: >=1, DistanceRequirement: >= 600}

FTFY
although the logic that it's never harmful to ride too much could be hard coded into the matcher as an axiom - if it indeed is regarded as an axiom that is :)

This is destiny, it's fate, it's the matrix working in my favour.

Manotea

  • Where there is doubt...
Re: AUK CHAIRMAN STATEMENT
« Reply #472 on: October 18, 2018, 11:58:08 am »
The legacy stuff is important - an essential element of being a club - but it was never a priority.

We constantly hear about how complex this project is.

Consider this approach:

Phase 1: Start with the static web pages, membership and shop side of things, i.e., all standard website elements.

>> One of the operational shortcomings of AUKweb is the way it manages online event entries, the financial transaction and registration being decoupled;  this is why Orgs get so many queries regarding failed event entries. This would allow the financial and registration elements of the transaction to be handled as a single element, resolving these problems and providing Orgs with access to an uptodate ecommerce facility to manage their events (A multi-shop approach would allow each Org to administer their own event transactions without involving AUK in the financial transaction.)

At this point,
- Riders would still enter via aukweb; only the financial transaction is handled by the new website.
- All of the 'heavy lifting' associated with implementing the CMS functionality is complete; from here on its mostly more of the same, forms and reports, all standard fare.

Phase 2: implement support for event listings for display, search and entry, updating overnight/on demand.

>> The events continue to be admin'd through Aukweb

Phase 3: implement support for event results for display and search, updating overnight/on demand.

>> The event results continue to be admin'd through Aukweb

Phase 4a: implement support for additional member services (awards, personal calendar, etc.).

Phase 4b: implement event admin and planner functionality.

>> Once this becomes live AUKweb is for reference only.

Phase 4c: copy over the historical data

Phase 4d: integrate additional external systems developed by AUK volunteers (AAA checker, route planner, DIY validation, etc.)   

----

Here the focus is on early delivery of functionality. maximising benefit and minimising wasteful systems integration with complex historical systems.

Rather then the new system referencing and being dependent on the old, the old system port data into the new system until such time it is ready to standalone.i

This allows developers to ignore historical complexities and focus on developing a complete new system; any systems integration is essentially handled by the team responsible for the historical system, which they are very familiar with. The most complex elements (event and results admin, planner, etc.) are not progressed until the relevant data structures are well established, at which point it becomes relatively straightforward.

Assuming you select a CMS equipped with the relevent key functional elements none of this is technically complex; the real complexity is in the individual toolsets (AAA, routing, DIY, etc.) developed by AUKs with extensive understanding and experience of the problems being addressed.

So its all about project sequencing. What we've seen is a rush for The Shiny, which to be fair looks very shiny indeed, but at a very great long term cost.

Where we go from here is difficult to divine. As Greenbank says, its hard to know how best to help.

This is mostly a project managent problem; the technical stuff is relatively straightforward. Alas, the one thing you cannot outsource is management.
 

Jaded

  • The Codfather
  • Formerly known as Jaded
Re: AUK CHAIRMAN STATEMENT
« Reply #473 on: October 18, 2018, 12:00:41 pm »
Surely the legacy data is the same as the current or new data? It just has older dates?
If you don't like your democracy, vote against it.

citoyen

  • Cat 6 Racer
Re: AUK CHAIRMAN STATEMENT
« Reply #474 on: October 18, 2018, 12:05:41 pm »
There would obviously be a short time when people are using both the new and the old system, but I don't see as that being a problem.

I admire your optimism!

But my past experience of this kind of situation suggests that the transition period would be painful.