Allegwiki

Purpose of this Wiki

PRIMARY
The wiki is a resource for new players. It has articles: Explaining what the game is Explaining how to download and install Covering most of newbies' FAQ Links to where they can learn gameplay material
A repository of technical information, for example: Troubleshooting guide Development
A repository of community history, for example: General history Zone games Squad games
Secondary;
Community related information: Squads, Current events, enforcement issues, etc.
A repository of development information Changelogs, etc.
Guides to using Alleg-related programs Teamspeak, Map Editor, ICE, etc.
Tertiary
A basic guide to core differences*. * Tentatively added to the list only recently.

The wiki is NOT for gameplay material. That is what the Cadet, the Academy, squads' private forums, etc. are for.

Rules

1. You cannot edit if your forum post count is less than 50 (exception being people who're Supporters).
2. You cannot put gameplay material on the wiki. If you do, it will get deleted.
3. You cannot move or delete pages, or upload files. If you need any of these tasks done contact one of the wiki moderators.

Guidelines

If you're unsure about something you want to add, post in the Documentation forum explaining your dilemma. But when it comes to editing something that is already there, feel free to edit away! But please follow these guidelines:

• Use the Preview feature to make sure the page looks the way you want it before you Save the page.
  • This avoids having an excessive number of edits which have to be checked.
• If you are fixing a minor mistake (such as a typo) please check the Minor Edit checkbox.
• 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.
• Don't click the discussion button if you have nothing to discuss!
  • It creates a new, empty, thread which clutters up the forums.

Any changes made on the wiki are monitored by wiki moderators, and don't be surprised if your work gets subtly altered to meet their seal of approval (mostly just adding links to other wiki pages).

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 - what other parts of the Wiki is your new article relevant to? If it doesn't relate to anything, it's not relevant.

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.

Improvement project

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

Documentation Zone Guidelines (2007)

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]