Code wise, I personally have found that taking apart someone else's code and reading all the related actual platform help files has always been far easier for me; you get to see it in action, and if you're a hands-on learner, that's the way to go. Generally you can't throw a rock around here without hitting code that's open for use, so that shouldn't be a problem for you.
As far as the rest of it -- ask your questions here, or message me with the sorts of things you want to know. I cannot help with the management of the site or getting that up and running, but @Glitch has a great tutorial up here.
As @Admiral said, do not do this alone. Not only do you need someone else to help with the extensive amounts of work, but you absolutely need a sounding board -- preferably two, so you can get two additional perspectives in addition to how you feel about something. Mind, I do not at all advocate approaching it in a 'we should compromise' fashion. Absolutely not. Make your decisions, but let them be made with input from others and perspectives you don't have.
There are a lot of foundational decisions that need to be made, and I highly recommend it be kept in mind for every single decision that you'll get the behavior that you reward. If you want a particular behavior from your playerbase, figure out a way to reward it.
Learn to be very clear. The job of staff is to provide the framework and tools for players to have fun within. The job of policy files is to lay out what OOC rules people have to follow, rather than just leaving it to the social contract. The job of your news files (wiki articles, whatever) in general is to lay out specifically what game you are playing, how you're playing it, and what people should be expecting playing with you. It is the best (and really, only realistic) way to communicate your vision, to make certain that everyone involved can see it.
Most games utterly fail at this, which is why there's so many problems. Nobody ever outright states: This is a game in which we will be focusing on the interpersonal drama between characters; we aren't bothering with realism, and we play fast and loose with canon. They ought to, though -- then the game is exactly what it says on the tin, and people can make educated decisions as to whether or not your place is right for them. This is an area that always involves TONS of miscommunication. Your mission, should you choose to accept it, is to make your vision so clear that everybody knows what they're getting in to.
The best resources out there are the people on this board, really. I don't know that there are many help guides out there. Amberyl's Mush Manual is actually really a helpful read. A good chunk of it is outdated and unrelated, but there is enough information there that I do recommend reading it:
http://www.groundline.net/eu-mush/mushman/
I found that link just with a search, but it does look like everything is there.
Take your time, take it slow. Don't get people hyped up too early and let them pressure you into moving forward when you're not ready.
Once you open the game, even for soft RP, kiss any thought of further game development goodbye. You will be handling day-to-day stuff so much that it will be a nightmare to continue working on any of the foundations of the game. If you then take too long to make those foundation decisions and change something that people have gotten used to, you risk alienating your playerbase in a major way. Get all the important-to-you stuff done before you open the doors to anybody but your chosen few.
http://fort.chrysalis.me/wiki/Fate's_Tithe
This is the framework of how I personally build a game. I'm no longer doing this Pern game (at least right now), but you can see how I do it. Wiki stuff means I have been able to move away from doing it with a combination of bbposts, jobs, and notepad -- it's way helpful. There are a lot of decisions that have to be made (though a lot of those on that link are specific issues that the Pern genre has, I promise most games don't have to explicitly state that PCs can't get pregnant without the consent of all involved parties OOC). What I do is make a list of what I think needs to be done. I go through and make the big sweeping decisions, write them down. Then I discuss what I feel needs to be discussed, make the rest of the decisions, make little notes. Create links with the specific items, drop more in-depth notes and discussions there, things to consider/read, places to look, whatever. Then you just start writing the files to fill in the holes and take it from framework-sketch to actual news files/wiki articles.
Last tip: Bad staff is worse than no staff. Always. It's tempting to say 'oh, they're really active, that outweighs (this negative quality)'. It does not. Ever. Down the road you will have WAY more work to do than you will have slowly addressing all the things yourself. Bad staff poison the well, and there's very rarely any coming back from that no matter how awesome you personally are.
