Allegwiki

Purpose of this Wiki

1. To replace the knowledge base as a reference source for technical problems and their solutions.
2. To help new players download & install the game, and where to go to begin training.
3. Act as a repository for technical information - development history, enforcement issues, etc.
4. Act as a repository for community information - squad information, history of the community, etc.

What the Wiki is NOT

It is NOT a source of gameplay information.

Don't write 3 page essays on the finer points of dropping rescue probes. That is what the Academy is for. You put it in the Wiki and you can expect it to get deleted.

Editing old articles

If you see a mistake in an article be it a typo, broken link, or outdated (such as referring to an ex-squad leader) then feel free to correct it straight away. Or, if you don't have editing rights, report it in the Wiki forum simply by clicking on the 'Discussion' link at the top of the page.

If you come across a Stub feel free to wax lyrical on those articles. They've been stubbed because the original author needs help :).

But if you're changing things just for the sake of change ... well, it's your life. You can waste time if you want.

Creating new articles

Before you launch into creating new pages carefully think to yourself "Is this gameplay related?" If it is, don't stick it in the Wiki.

Then consider if it is really necessary. Are you writing something for the sake of writing it, or will it actually benefit the Wiki? A key point of the Wiki engine is how everything links together in a giant spiderweb, so, what other parts of the Wiki is your new article relevant to?

Finally, check and see if it isn't already on the Wiki - personally I've created a redundant page, "FAZ Beta" when "FAZ Beta Games" already existed simply because I didn't check first. Use the search engine sensibly to determine if the article already exists.

If in doubt, discuss it with the Documentation Zone Leader.

Always

• Use proper spelling
• Use the titles of positions, rather than the name of the person that holds them (no one wants to edit twenty pages when Tigereye retires and TheBored takes over Documentation Zone Lead, just to change their names).
• Don't use swear words, smart-ass commentary, etc.
• Use headers, bold, italics, etc. appropriately.
• Try and link to other wiki articles.

Improvement project

Go to that page to check out how to help improve the wiki.

Documentation Zone Guidelines

What follows are the original Doc Zone Leads thoughts on writing documentation, posted on the forums. Some concepts are applicable to the wiki.

[quote]So, I'm supposed to be making sure all of the documentation is OK. Here are some groundrules I'll make for this forum of mine.

• Technical documentation only should be discussed here, with the exception of a small handful of the most commonly-asked gameplay questions that are covered in the KB.
• Gameplay documentation is handled by the Academy, Training, and others. Not us.
• NOTHING should be published to "public locations" unless it's been reviewed by at least 2 Documentation Mods and both agree that there are no typos/mistakes/misinformation
• Everyone should feel free to propose suggestions to reword any documentation. Just post a topic here, or reply if a topic is already discussing the article you'd like to improve.
• Doc mods should feel free to post drafts in this forum, or any other "hidden" documentation they're preparing on the side. The more eyes the better. (Just make sure you have another mod sign off before publishing!)
• Write your documentation for the idiot. Sorry if that's not politically correct, but try to make your solutions understandable by 8 year olds. If you need to add technical stuff to explain it, try to organize your solution so that you give the basics of the problem/solution up top, and a disclaimer "For more detailed/technical information, see below".
• Follow similar form across documents where possible. (Don't freak out if yours is slightly different. Fix it if you have time, or leave it.) See below for an example
• Stay Classy

Enjoy documenting!!

--TE[/quote]

And here are his thoughts on writing help articles for the (obsolete) knowledge base: [quote]Subject: Try to include the exact error text seen by the user in the subject. eg: "How do I fix 'Cannot connect to lobby'?"

• At the top, include the question or error text at the top of the article so users know where they are. A good start is: "This solution covers the following error messages..."
• Underneath, include symptoms or other specific info that uniquely identifies the issue/problem. This is important because there could be 2 or more ways for a user to receive the same error text/problem. "Do you see 'Could not connect to Lobby' when clicking 'Free Games Listing'? Or do you see that error message in the middle of gameplay after being kicked out?"
  

A good example is: "You receive the error 'blahblahblah' when clicking yaddayadda after you did suchandsuch"

• (this isn't necessary but depending on problem can help) Identify the cause of the problem in a small sentence/paragraph. eg: "This problem is encountered when Allegiance cannot talk to the server; something is likely blocking it"
• Solution. This should list specific steps (as exact as possible) on how to resolve the symptoms read at the top of the article.
  • Separate multiple solutions visually. Paragraphs with bold headlines clearly separate one section of a solution from another
  • bullet points separate steps visually too
  • The solution is dependant on what's being fixed, so there's leeway here. Just make sure you cover the bases and lay out the solution in clear/easy wording (Not too technical!) and visually separate the solution from the rest of the document. Most users dart their eyes straight to a set of itemized instructions on how to fix it instead of reading your whole article. Don't be sad - it's not because of your writing.
  • format your stuff nicer than this example. I'm lazy today and didn't watch my capitals, bolds, italics, etc.
• Additional Information should be separated below the solution under its own heading. Put technical stuff here for the people who want to know specifics
• Always include a link to the helpline somewhere in the article with text like "If this didn't solve your problem, go here and post a new topic"
• Feel free to be lazy and copy/paste sections to your new articles - it'll help keep everything consistent. Just make sure you proofread what you've copied!!!!!!!11

In everything you write, try to visually separate important strings from your text. Ideally all filepaths, registry keys, and other technical strings should be in Courier New, or other monospaced font to distinguish it from text. Otherwise users may not know whether you're talking about different program files like word and excel or the program files folder. See what I did there? Annoying, ain't it?

Make it stand out. (If you can't do fonts, do bold/italics/underlines/colours/whatever is at your disposal. Don't overdo the color though)

OK that's good enough. Obviously everything can't be covered identically so use your judgement as best you can... but we should make an effort to keep things in a consistant format. If you think anything about this format sucks, propose improvements. Documentation is always changing, and if you can make it better, let's hear it!!

--TE[/quote]