For the record, I don’t plan on doing these very regularly myself.  Why?  Well, I simply don’t have that much time to even write these regularly myself.  For the most part, it will be other editors doing this, writing about anything that doesn’t quite fit in any of the story categories we have.

With that out of the way, I really wanted to discuss what it takes to run a site this complex as ThrillNetwork.

It’s definately not the same site as it used to be.  I remember the day when the first version of this site came out, with the "phases".  Then, September 11th hit, and for some reason, the phases kinda went out of the window.  A few months later, in an attempt to upgrade the forums, the common login between ThrillNetwork and CoasterForum’s vBulletin (which had problems from day 1) quit working.

Then, in August of 2002, TNv2 came out.  The login worked, but it was bloated, slow, and some of the stuff never worked… period.  Anyone who remembers the first version of our coaster database would definately remember that.  Plus, we were locked into a version of vBulletin until I managed to do an upgrade that was one of the worst experiences I could ever deal with (took 8 hours to do an upgrade just so we could be ready for down the road).

Well, I am sitting here typing this using an administrative backend that is slick compared to what we had in the past.  Plus, I just upgraded vBulletin yesterday (took me all of 3 minutes).  So, I guess everything should be a breeze with the new version of ThrillNetwork, right?

Wrong.

Working on the site is never done.  We are always fixing, maintaining, and adding features to the core of the site.  Some of you may think of the forums when I say core… and those that think that are so far from the truth that you need to get out more.  The core of the site is really the main site… the stories, the content.

How can this be?  Well, with this version of ThrillNetwork, we aimed to make the forums one of the sections, and not the center of attention.  That meant a lot of attention to our stories, our database, and pretty soon, a SpeedZone update (it’s not a redesign, because we’re just applying the main site’s look/feel to it).

These sections require a lot of attention.  That’s why we have a lot of staff.  At current count, we have 19 staff members handling anything from moderating to editing.  Lately though, we’ve been making a major push for content editors… not just for stories, but for sections like SpeedZone, TV and Events, and other things.

Of course too, we get help from the members.  We’ve tried our hardest to make this site a lot more member friendly in terms of submissions.  It used to be that submissions would just sit in a queue, which would screw things up.  Now, submissions are e-mailed to staff (not stored in a database), and we can post them a lot more readily.  Statistically, more submissions have been posted in this new version, plus we can much more easily credit the submitter (like this story about Eisner, which was submitted by a member).

A common thought about how I work is that I direct everything.  Well, it’s the partial truth.  I do have a lot of say in what goes on, but generally, when it comes to content, moderation, etc., I don’t restrict the kind of content.  I have guidelines set forth to maintain consistency for content, but in terms of the actual content, I am not picky and let the editors work it out on their own.  For moderation, I generally let moderators deal with stuff unless it’s an issue where we need to see more of an independent thought on it.  Otherwise, I have been heavily focusing on the server end of things.

So, you know that 3 minute upgrade of vBulletin?  If I did it straight to the live server, it would have taken at least 1-2 hours (reverting modified templates and re-modifying them, testing, noting any anomalies, etc.).  However, starting with this version of the site, we also have a duplicate development and testing site, where we can work out bugs as we go, which has a separate database in case anything goes wrong.  That way, the live site stays up if something breaks during an upgrade/modification/addition.  So, in truth, the upgrade did last about 1 hour.  But, thanks to standard procedures, tools, and in vBulletin 3’s case, XML-based templates, I can minimize downtime when I perform the same actions on the live site.

It’s not easy running a site like ThrillNetwork.  Without these people, it would slow to a crawl.