(Unfortunately, I don't know Russian or any form of Chinese, so I can't help there except maybe to proofread the final results)

Google translate is a thing guys, it translates Russian and Chinese into horribly mangled English and vice versa, it's cool.

ftfy

It's really not tantamount to a hostile takeover - we would not be able to do this ourselves, and would need not only the blessing, but the assistance of the other sites' translators and admins to make it work.

The license would be something to look into, though.

I'm not certain that the russian and chinese sites operate under the same creative commons license the main wiki has always used; that is, I'm not sure if we're actually allowed to copy their material.

That and it feels like doing what you suggested would be tantamount to a hostile takeover since there was no discussion with the others (e.g. whether they want to move off).

Hell, would it be possible to have the entire site available in different languages with the option to switch between? I'm not talking so much content as the basic structure, so it's navigable to Chinese/Russian/etc. speakers, and content is added as it's written or translated.

If we weren't already planning a move, I'd suggest we throw up what translations are available right now using the tabs voodoo magic Troy has on his member page. That, if there's a MediaWiki equivalent, might be the way to do this, tabs for different translations, divvy up up discussion pages based on the translation tab. Still, though, the framework would need to be available in multiple languages to facilitate easy navigation.

Simply put, I suggest keeping permissions how they are now. Allow anonymous users to read the site, discussion threads, and forums. Gotta be an accepted member to actually comment, edit, and post. There's no reason to split access into such categories as "Reader", "Editor", etc among approved members. That just makes things more convoluted and requires more involvement on the part of the administration - having to approve people first for the site, and then upgrading permissions through an arbitrary number of levels to do things an accepted member could do now. Seems pointless.

Get someone to write (or adapt) an extension: Extensions are written in PHP, and we have people in the user community with experience writing in PHP. Alternatively, we could try to find someone outside the community to develop it (such as a developer of an existing close-but-not-quite extension), but I don't want to have to depend on some "outsider" to implement the new wiki.

Change the method by which we rate articles and determine cutoffs for deletion: While a possibility, there doesn't seem much enthusiasm for changing our rating method. I doubt we'd be able to easily reach a consensus anyway….

Try a different wiki engine: This just seems like overkill, and may not get what we want anyway.

My preference would be to find one or more people in the community— who would already have a vested interest in the site— who could develop the rating extension and any other ones we would want. And naturally there may be some other option I haven't thought of. Comments or thoughts?

I agree strongly with the above, and I'm going to go ahead and recommend that we also see if we can move the other wikis as well under one large umbrella. Let me be more specific here. Under one website. Different subdomains as necessary.

2. I think this could be a great asset. Bright was complaining about people who join and say: "I just want to read the comments." This is an easy way to give those people that level of access. It doesn't seem like it would that difficult to request higher levels of access as well, going from: "Reader," to "Editor" (who could also vote), to "Senior Staff" (functionally the same, maybe with a visual change or something), "Moderator" (deletion powers, same visual aesthetic as SS), and Admins (different stuff overall).

3. I think it would greatly ease the transition if we stuck with what we have.

1. Because of the way MediaWiki is designed, we may not be able to have URLs in the form of scp-foundation.com/scp-173, but instead something like scp-foundation.com/scpwiki/scp-173. (At the very least, it seems like Best Practice to not have wiki pages right off the domain root— still working on determining this for sure.) So, the question is, what kind of hierarchy would we want under the scpwiki directory?

2. In MediaWiki, user permissions are governed by membership in user groups, and MediaWiki allows for finely-grained permissions for each group. This would mean that, say, a group of users could read and/or post in the forum (whatever form it takes) but not edit pages. So, we'll need to figure out what permissions to give to which groups (including anonymous users, users who have created an account but not been confirmed, staff, mods, admins, and who knows what else).

3. I've found a few different voting/rating extensions with different options for voting scales. Besides the vote for/vote against mechanism (which would need to be tested, of course), there are mechanisms for giving a page 1 to 5 stars, or a score from 1 to whatever, or a rating out of 100. I'm personally leaning toward the upvote/downvote method we have in place now, but that's something else that needs to be decided before it's implemented.

Some method for joining our specific site, and, please dear god, make sure the method is only accessible from one place. I still get a lot of people who join from wikidots 'join this site' and not our 'join' page.

Some features that would be nice but aren't critical include the top rated/lowest rated pages and the Random SCP function. Like Adam, I have no idea what features it comes preloaded with, but it'd be nice to port as many of these as possible over to the new site.

On another note, I will be out of IRC for the forseeable future. I'm starting a new engineering semester and I won't be able to spend much time online. If there is an emergency or important thing you need to tell me about, message scpfoundationsite[at]gmail.com with [IMPORTANT] or [FOR KENS] in the subject line (Take out the [at] and replace with @). I get a copy of all emails sent to that account, so I will be able to either respond or fix issues in the time I have.

I will still be working towards the move and post periodic updates here. If you see CRITICAL, please read it and - if you can - post a reply. I won't use that tag unless it's extremely important.

-Kens

Quikngrvn and I will work together to get the new site up and running.

First thing's first:

Here's what we have, 100%, right now.

• A domain at http://www.scp-foundation.com/. I need to get access to the details once I get the hosting down pat.
• A very possible candidate for the new site, keeping the wiki format. As linked above, TikiWiki and MediaWiki seems to be very viable options.
• Funds/source of funds for hosting (if needed) and for paying the domain.

Here's what we don't have, and will need.

• A final hosting server. I have free options, but I have no way of knowing how much traffic our site gets. Google analytics has not been working properly, so I need to figure out a fix for that. It's safe to say that we do account for a significant portion of bandwidth, so I'm advocating we pay for hosting, at least for a few months when we're ready. (Note, I'll use a free hosting while we work out the bugs for the installed wiki, formatting, etc. When that's finished, we can migrate the finished templates to a paid hosting for higher bandwidth limits.)
• A finalized design. I'm still working on this. We'll most likely use a default theme until it's done.
• A list of CRITICAL pages. I'm not prioritizing user-submited content, but if there's a list of pages that ABSOLUTELY MUST BE UP FIRST, I need to know. Otherwise, I'll be going by the tabs in the wiki.

I'll also need a team. Quikngrvn, since you volunteered and have a ton of experience with the backend, you're up first. I'll send you login details, hosting details, etc, as I get them and send it over. I'll gladly take anyone else with large amounts of experience with this sort of thing. I may be good, and with Quik on now better off, but having another few hands would make things better.

That seems to be everything I can answer for the moment. Also, if I could say, please, PLEASE try and remain polite when discussing things here. It's a serious thing, and being sarcastic won't help. If people have legitimate questions, they deserve straightforward and polite answers.

This is all for now, but I'll check here more often now that I have a better schedule.

• Current free hosting option: 000webhost | I've been using them for my personal domain for a while and it's been pretty reliable.
• Paid hosting options: Dreamhost, 1&1. I've used 1&1 for web hosting in the past. They've been very reliable and pricing has been relatively fair, but I've heard dreamhost is a viable option, as well. Dreamhost is also $1 USD cheaper per month.

• There are a buckload of wiki engines out there (though many are small, niche, new, or abandoned).
• Most wiki engines are open source and free under either GPL (GNU General Public License) or LGPL (Lesser General Public License), including many of the most widely used ones.
• There are a bunch of options that may (or may not) affect how the wiki is hosted and implemented, including what language the engine is written in and whether or not it uses a database back-end.

Now, because so many wiki engines are freely available, we could try out one or more engines before actually committing to one. The main non-technical criteria I used include:

• age of the engine (favoring those that have been around longer),
• frequency of software updates (those that hadn't been updated recently were excluded),
• presentation (since a site for a wiki engine would be expected to run on that engine),
• how widespread it's used (though most stats on this come from the sites themselves, so take with a grain of salt), and
• availability of support (which is also a rough measure of use).

Anyway, the first wiki engine I think we should try is Tiki Wiki, mainly because most (if not all) of the functions we want are available in the core package, as opposed to having to find, download, and install who knows how many extensions to get what we want. In case Tiki doesn't work out, we can try MediaWiki, the engine that runs Wikipedia and its sister sites. Yeah, we may have to install and maintain dozens or hundreds of extensions, but there shouldn't be much problem finding help in case we need it.

Both packages have similar requirements for the website they're hosted on:

• A web server, preferably Apache;
• 512 MB of RAM and 100 MB of disk space, in addition to space for the actual data;
• PHP 5.2 or newer;
• MySQL 5 (while MediaWiki has several options for its database, Tiki Wiki specifically needs MySQL 5); and
• root access (may not be actually necessary, but would make things a hell of a lot easier).

I volunteer to install and configure the wiki engine, whatever it ends up being, since I, um, kinda do this sort of thing for a living.

Questions, comments, thoughts?

And we're going to lose the forum and the discussion pages. We're going to lose the current ratings. We'll probably have to learn new wiki mark-up for a lot of the things we do, and we may not have modules for the things we depend on, like ratings (though it may be possible to build our own). That's unfortunate, but there's no way that I've been able to find to let us keep that. But as Yoric said, the alternative is losing the entire site down the line.

Wikidot's software would be ideal, but unfortunately, they killed the project for making their software freely distributed. There's a version available, but it's an earlier release, and it may have security issues and lack features we use.

Kens/GX-67 is currently project lead, insofar as he's been putting in work to figure out what we need in terms of hosting. Quik, if you can find decent wiki software that'll suit our purposes, that would be awesome.

I'm beginning to get the impression that we're arguing the same issue from different ends; I feel that a lot of what you're doing here is correcting my terminology. Planning these things and more is the purpose of this discussion, as of now. You've helped immensely to clarify the point.

Your new assignment, should you choose to accept it, is to begin researching wiki software options; while hosting seems to be sorted out, though I'm not absolutely certain and will be sure to badger mann about it, a suitable replacement for wikidot's setup will be critical, and I have no idea how to go about looking that sort of thing up. Thank you for volunteering, good man.

Also, you seem to be dismissing the importance of proper planning. Do you want this migration to work, or be a clusterfuck? Without a plan, it will be a clusterfuck. (Granted, with a plan, it still might be a clusterfuck, but the chances aren't so close to 100%.)

Now that that's all clarified, I suppose we can proceed with the proceeding?

Goals: Something less nebulous than "our own site". More like: A wiki that we administer, on a site that we administer, with all wiki data and meta-data transferred to the new site. The site will be world-readable, but editable only by wiki members (the same as currently). I'd like to have a system where certain meta-data can be created and edited by mods, like an "Author" field separate from a "Created By" field that can be edited if the author of a page did not create the page (such as for, say, migrated pages).

There also needs to be a forum, and the current forum needs to be migrated and/or archived.
Oh, and the site needs to have enough space to host images, and the bandwidth to handle whatever traffic we generate.

Items needed, including things we already have:

• A domain name
• A web host
• Wiki software
• Forum software, if not part of the wiki software
• An archival system, if not part of the wiki software

Considerations: Considering options for web hosting should be fairly straightforward, since that would be decided based on cost of disk space and bandwidth. But, the software for the site would be decided based on things like ease of use, available functionality, whether the software is even maintained, and, yes, cost.

Then, once the technical components are chosen, they're going to have to be tested. We will have to test the wiki before we start the migration proper to make sure it will work as we expect it to.

Also, while data is actually being migrated, will the site be locked down, either in total or in pieces? I would think so, but again, it needs to be decided before any data migration starts.

So: what did I miss? What has been considered that I don't know about?

This paragraph

Good news! Our very own drmann has recently purchased a domain under the SCP wiki name, and a donations button has been placed in the sidebar to gather funds to maintain future hosting. GX-67 is working on web design at no cost to us, which leaves more of that money free, thus ensuring us greater sustainability. Several members of staff, including myself, have stepped forward to volunteer our time and effort toward the actual copy paste copy paste physical move, and now we are prepared to discuss the logistics of exactly how to go about doing it as quickly and efficiently as possible.

exists specifically to bring you up to speed on exactly what we have planned so far and what happens now.

Is there a project manager, or a master plan, or even a mission statement?

No, because nothing has started yet.

That's, um, the whole point of a plan. To figure out what needs to be done before the migration actually starts.

Look, I appreciate the desire to take it slow. That's a good thing. But "slow" and "well-planned" are not mutually exclusive.

(N.b.: just to be clear, I have no desire to be project manager. I would be a crappy PM, and I couldn't do the job justice.)

Yes, this forum thread, for the moment. A wiki page isn't really needed right now,a s there's not a whole lot going on yet.

Are there logs of conversations about the move posted somewhere (such as, say, on a wiki page)?

No, we haven't had any kind of deep, meaningful conversations about this. We're still waiting for gpx7 to get back to us with more information.

Is there a project manager, or a master plan, or even a mission statement?

No, because nothing has started yet. At the moment, the extent of what has happened is Mann has the website, and GPX7 is taking a look at what our costs will be vis a vis traffic etc. We're taking this chill, easy, and slow.

Now, would someone care to answer the questions I actually asked?

Is there a central location where information about the move can be posted and discussed (such as, say, a wiki page)?

Sorry, but a single thread in a forum is nowhere near sufficient to handle the amount of information and discussion that should be involved in such an undertaking. I'm talking more like a page that shows what's been done, by whom, what still needs to be done, to whom these tasks have been assigned, when these are scheduled to be completed… a project plan, basically (see below).

Are there logs of conversations about the move posted somewhere (such as, say, on a wiki page)?

I keep reading about discussions involving the move. I assume that these discussions take place in the chat, during times that I'm not on (such as the middle of the night EST). I'm not (yet) complaining that I've not taken part in these discussions, but I would like to know what's been discussed (for example, if something has been ruled out by someone more knowledgeable than me, that would be nice to know). How much effort would it take for someone who was in those discussions to post logs of what was discussed?

Is there a project manager, or a master plan, or even a mission statement?

If an undertaking of this magnitude is not properly planned and executed, it will fail. There must be a plan, preferably one that is publicly available that can be commented on. There should be a project manager— one person who keeps track of what needs to be done when and who's doing what. Elsewise, it's just a few people doing their own thing, while the rest of us (who want to help, I might add) are left on the sidelines going "What the hell is going on?"

In short, we know the Why, which yoric so helpfully recapped in his post. It's the Who, What, Where, When, and How that needs to be hammered out, in a place that all interested parties can view and comment.

Kens and anyone savvy in web design, can you look into this here and see if that might work for our purposes, and if so, let us know what features we'd stand to gain/lose?

Sarcasm aside, various people have been making various posts on this very wiki for a while now; I can't help but feel as though those of you claiming to be out of the loop simply haven't been paying attention. Here's a rundown:

Recently, wikidot administration took it upon themselves to remove a section of this, the staff wiki, dealing with archived disciplinary posts regarding fekketcantenel. They did this without consultation with or permission from anyone on staff, and replied to bright's request for further information by threatening to delete the wiki entirely. You should know this. If you didn't, start paying fucking attention, because it's a big fucking deal.

Recently, the united states has begun considering legislation that will, in breif, legalize the unilateral removal from the internet of any copyrighted material, without any due process, up to and including shutting down the hosting site entirely. If you don't know about this, fucking google SOPA and stop spending time under rocks that block wifi.

Ninety some percent of images on the SCP wiki are used without permission.

Wikidot, ladies and gentlemen, does not care about us, and has made it repeatedly clear that they will not investigate complaints or honor the validity of our work. Wikidot administration has made it clear that they are not only perfectly willing but positively eager to remove user's content without real provocation; now a legal situation is evolving that will lead directly to a genuine demand for them to do so. In short, if we don't move the site, we are potentially going to lose the site.

Even if SOPA fails, God and justice willing, we still fall under the purvey of an administration who prefers to delete content at a complaint rather than rightfully investigate. Any troll could, under the guise of an 'offended user' or by claiming to be a piece's original creator, have content removed or edited, and refuse us permission to restore our work.

Hosting of our own, on the other hand, eradicates the potential for interfering administration entirely, and gives us the opportunity to deal with the legal realities of our copyright situation on a case by case basis. Caps here for emphasis, people:

THERE IS NO DOWNSIDE TO THIS.

Good news! Our very own drmann has recently purchased a domain under the SCP wiki name, and a donations button has been placed in the sidebar to gather funds to maintain future hosting. GX-67 is working on web design at no cost to us, which leaves more of that money free, thus ensuring us greater sustainability. Several members of staff, including myself, have stepped forward to volunteer our time and effort toward the actual copy paste copy paste physical move, and now we are prepared to discuss the logistics of exactly how to go about doing it as quickly and efficiently as possible.

Now I ask again, why the shit did you not know about this, and why the everliving fuck is it a problem?

Don't answer that. Instead, start thinking about how you can help. The deletion of fekket's disciplinary thread wasn't the first time wikidot has actively screwed us over, and it won't be the last. Let's get this thing moving and give the SCP universe and collection the place and recognition it deserves.

Someone who knows what the hell is going on, please create a central repository page for the move, at the very least. 'Cos I don't know what the hell's going on, and as an admin for the site, I feel I should know what the hell's going on in this little endeavor.

Normally, I would agree with bright, in that the forums and discussion threads are a fairly important if not integral part of the site community. However, the issue with wikidot unilaterally deleting fekketcantenel's discussion thread has me antsy. The ability for users to go over our heads like that is not a weapon I like the idea of some of our less responsible users having, particularly in light of all the trolling we've had recently. Personally, I'd really like to get us off of wikidot as soon as we're able, especially since mann is willing to hold the URL for us; and if that means losing the forums, it's an acceptable loss in order to make sure no offended new user starts having our content removed under false pretenses.

Now.

Theraven, making declarations like "If X that makes me unhappy is considered, we should avoid this ENTIRE LINE OF THINKING" is unnecessarily hyperbolic, and starts stupid arguments that bog us down far more than they help. At no point did anyone ever say "we're going to move a few articles, and ditch the rest". What's being discussed is whether or not we should prioritize getting certain articles up first to ensure that readers migrate to the new location as we go, instead of just dumping a whole new site on everyone and losing readers due to the jarring transition. See, no matter what we do, we're going to have to move pages one at a time, unless someone's invented a 'copy website' button while no one was looking. When you do things one at a time, you have to pick an order to do them in. If, as you say, no article is a higher priority than any other, then it doesn't matter what order we do them in, does it? We may as well start with the high rated ones. If you must be too close minded to even consider that option, please simply suggest an alternate method of transfer rather than exaggeratedly shit on the whole plan just to make a point. Making suggestions to replace points you disagree with is helpful; declaring you're too cool to play with the group is not.

Or something. I don't know. We need more discussion on this.

I'm currently browsing for some wiki code that'll work for us, given that Wikidot's open source project is dead. Not finding much and not sure I'd know if I was.

This is about all a cursory search turns up. Not sure exactly what kind of features it supports. Someone more computer savvy will need to look into it.

I'm thinking something along the lines of a non-editable "showcase"-style site, where pages are set up to let readers read the articles. The site itself will be designed with the Foundation in mind, minimalistic and professional. I'm going to have to figure out some color schemes.

Post any ideas you have here. I'll take them into artistic consideration and see which could/would work well. I'll also work on some mock-ups of the site and how it'll look like over winter break. (It ends Jan. 15th, so I'll start losing time to university again, before starting up again during summer-ish.)