Challenges Make Opportunities; Death of a Wiki

... is closing it's doors

Some knew of it before I did.  I only found out this morning.  It's true.  Wikispaces, where I run my game wiki, has decided to end its term as a wiki provider.  To continue my wiki, I will have to move it to another service.

Here is one of those moments where my Role-playing experience coincides with my professional experience.  I have moved databases before; I have torn them down, page by page, and built them up again ... of course, this was more "fun" when I was being paid for the privilege, and didn't have to worry so much about getting enough time or help to get the job done.  Still, this is old hat.

Wikispaces gives me an option to download my entire wiki into a pdf format.  I've done it every now and then, just to be sure I have a backup.  I've always been sure at some point that wikispaces would die; just as I've always been sure that blogger will go tits-up eventually.

This is an opportunity.  Yes, honestly.  The wiki needed a cleaning out of old business and pages that didn't accomplish their purpose ... and this is a good way to root them out and ensure they don't get carried over.  But it is a lot of work also.  Here's how I'll do it.

Once I settle on a new platform, which will probably be today or tomorrow, I will begin to move sections of the old wiki to the new, adjusting links as I go.  The link adjusting will be the most annoying part, but for as long as I can, I'd like to enable the reader to have full access to both the old and new wikis, while the transfer happens.

The usual business model (which I strongly disagree with, having seen the alternative), is to build a whole new duplicate wiki in secret, then reveal the new wiki on the same day the old wiki goes down (or, sometimes, with a decent overlap period).  This is the sort of thinking we can expect from managers who, in high school, had wonderful hair and were able to manage a 63 in math.  What always happens is that the new data base, because it was built in an untested vacuum, goes down in the flames of burning shit almost immediately, followed by twice as much work being needed to fix all the hidden problems that wouldn't have been hidden if it had just been built publicly.  But business managers will never learn.

It seems like more work to do it piecemeal, with having to adjust the links more often, but doing it this way, problems get exposed almost at once and then fixed before the whole wiki is brought across.  The process is then a learning experience and not a public relations clusterfuck.

Then, when I am running out of time in July, the most important stuff will be shifted; the pages on the old wiki that are shifted will be gone; and the remainder of the old wiki can be downloaded as a PDF.  Those will be the least valuable, the least needed pages, and many of those won't be shifted at all.

Following this, someone is going to suggest that I should use some program to automatically make the shift and "save time."  It's shouting into the void, but "saving time" is the best way to not save time ... and the best way not to improve something.  As I said, this isn't a disaster, this is an opportunity to make a better, cleaner wiki.

What does time have to do with it?