Moving Uncyclopedia: things we didn't do that we probably should have
< Blog
On 5 January 2013, after years of complaining about their previous host, the Uncyclopedia community split from Wikia and sidled most of their butts over to the new site: en.uncyclopedia.co.
I was one of those behind the move, working with a team that changed considerably over the months the project was active, and in the end I found myself acting as some sort of vague director person despite from the very start having absolutely no idea what I was doing. Although apparently I wasn't the only one.
Here are some of the things that seem, based on what happened, like they might actually be kind of important when dealing with a project such as this.
1. Set deadlines.
Sure, it's a volunteer project carried out in everyone's spare time - can complete it whenever, right? The problem is, then it just never gets done.
We started in February or March of 2012. We deployed in January 2013. We didn't mean for it to take this long, of course - said at first we should be moved by the summer. Then it was summer and we said soon, we need to move soon! Then half the summer was gone, so it became October, definitely; we have all the beginnings of what we need. Then it was November and then December...
At this point, when I said we would be ready by 2013, nobody believed me. But this time it was serious - we had to be moved by then, at least as far as I was concerned, because I just couldn't keep working on it after. I had an internship starting on the 2nd, and classes not long after that, and frankly I was bloody tired of the entire thing. And this time it happened - I finished the import scripts (or the important ones, at least), some of our other lovely guys got the environment shiny, another two finalised announcements and policies, and we went. There was no small amount of badgering, it wasn't perfect, and there was indeed a hell of a mess as a result, but it happened.
2. Define roles and tasks among team members.
We never did this at first. Even toward the end we didn't really explicitly define much, but at least by that point everyone had some idea what someone else was handling - the one guy was press, the other policy, those two over there organisational and support. These three, here, the sysadmins, and these ones over here, our wonderful team of angry developers...
Once the folks were even brought in and that was sorted out, it was a lot easier to get things done - work with relevant ones for thing a, delegate thing b to the applicable person for that, and it works out. Tasks could be defined because someone was specifically looking after that general area and thus knew what was going on with it. In most cases it wasn't written down or even in some cases communicated, but one of the sysadmins decided he would get mail up, and gods dammit, he got mail up. An angry developer went through and fixed a bunch of extensions, and they worked, though nobody even realised they had been broken until a few weeks later. That is how things got done.
Having somewhere to document at least some of it also helped.
3. Work on tasks concurrently.
Even if the final product is a long way off, working on secondary tasks as well as primary is still important. Even without the data, getting the server set up was still something we needed to do, as without it the database was useless, just as without the database the server software is pointless.
Especially at the beginning we wound up putting off some key elements much longer than we should have because there just didn't seem much point worrying about them at that point. We did not yet have the database and thus for a time put everything on hold for that - and as a result we almost didn't have some of the other things at all when it came time for deployment. For instance email, as far as I know, only got entirely up a few days before deployment.
But it wasn't just that - because we weren't working concurrently, for quite awhile we weren't working at all. Nobody else was working, so there wasn't any incentive to work either and the project just languished. When someone finally did do something, it affected the group dynamic and there was suddenly pressure on others to do something as well.
4. Bring up concerns.
No matter how silly it may seem, there could potentially be something to everything - the javascript is running slowly, the gifs not rendering, can't log in from here - and it may be a sign of some bigger issue. And if half of the team can't actually figure out how to use the server OS, well, that could be a problem too. If folks aren't communicating well, that's also potentially problematic.
Depending on the folks in question it could be fine, but in this case it led to everyone being locked out of the server for a month and having to remove two people from the project entirely.
That was fun.
5. Listen to team members who have concerns.
Particular concerns may or may not be an issue, but everyone on a good team will have a somewhat different background and bring different things to the table - for instance with a server some will consider efficiency more, others stability, others security, others usability. Now there will always be some overlap, but the security guy, for instance, won't necessarily consider usability at all even if he should - sure, suse is easier to lock down, especially if he's been using it for years and knows yast like the back of his hand. Except if nobody else knows how to use it, that's not going to be a whole lot of help, especially if they wind up trying to install things they way they're used - not through yast - thus breaking the entire configuration. And gentoo may be brilliantly fast, specially-tailored to the particular machine and purpose for maximum efficiency, but not working more quickly is still not working if folks forget a flag when building.
So if someone says that a particular OS won't work because half the folks don't know how to use it after three months trying, telling them it's easy to learn and they're not trying hard enough doesn't necessarily address the problem.
There's a reason we're now using ubuntu.
6. Consult the community as a whole before making large changes.
In this case, the 'large changes' were the move itself.
Even if you already know there is consensus, even if a multitude of reasons have been thrown around over the years, when the project is finally announced for real it still helps to have the folks discuss it now, vote on it now - now that it actually means something. Up until now it was all just talk, words thrown around, but with the reality facing down, if the users are given the opportunity to commit to it and have their say, they will. They want to be a part of it, for it is their project, their community, and because of this the reasons they all throw around will be far more convincing than any initial announcement that could be presented, and their support more effective at drawing the more uncertain folks in than any explanations could be.
I fear we have lost some good folks because of this.
Comments
Apheori 12 February 2013 at 6:30 am
Obvious doesn't make things easy to remember, or mean they'll sink in at the time, though.
zaiger 20 January 2013 at 10:14 pm
We ran into some of these same problems when rebuilding Encyclopedia Dramatica. Except we didn't have the luxury of having the actual database or any of the files. We rebuilt the site from Google cache and Archive.org. Sometimes change is for the better, even if it seems impossible at the time.
Apheori 12 February 2013 at 6:29 am
On the other hand you did have the luxury of being the only ED, no? We've got two competing projects now - Wikia and carlb. But these things do have a way of working out, as you've proven with you own issues, so eh.
Bizzeebeever 20 February 2013 at 3:07 am
CarlB does not run the new server. Just a note.
Apheori 22 February 2013 at 7:49 pm
Right. Those are two competing projects against ours... didn't realise the ambiguity there.
Laurence 'GreenReaper' Parry 23 April 2013 at 3:29 am
A year seems about right. It was a little easier for WikiFur, being so centralized; I was working with just one other person on the technical side, and over time I took on more and more tasks. Of course, that made it rather stressful, too! Like Uncyclopedia, it all got done in the end - though I was kept busy asking people to switch over to our own URLs from a year before, and for several months after.
Often fear of change is worse than the actual change. It can be painful, but it's an acute pain, rather than the chronic wasting caused by waiting too long. If the cause is good, hopefully the reason for departure will be apparent to all.
saper 14 January 2013 at 9:34 am
This is useful! I have worked on few community projects like this (cleaning up their servers with gazillions of unmaintained WordPress and MediaWiki instances) and this list is very useful. Actually ready to point here and say "look!".
Although some things may seem "obvious".
~~~~