Epilogue
From Aardappel's
post on the
cube forum.
Do not be afraid to refactor things. Sofar it seems people just ADD to the wiki, and leave what is there in place. One of the ideas behind a wiki is that its easy to reorganize the soup of data. If you add something that makes the structure of the document less than ideal, do not be afraid to restructure other peoples text into a different set of pages and links. Do not be afraid to even delete other people's text, once you conclude it has become redundant. The original structure was just me making some example pages, it may not be ideal for the current contents anymore.
Feel free to discuss in this thread if you have major restructurings in mind, or certain conventions.
Don't let pages grow to huge amounts of text, wiki's are best when they are small sections of text per page, but HEAVILY linked.
In that same way, one of the goals of the wiki is to function as a FAQ, so if we get the 1001th post on "your server did not reply to ping" we can point people to exactly one wiki page that has all the firewall tutorials you could ever wish for.
Some stuff on the wiki is straight out of the main documentation. Duplication is not good, it means if I update the main documentation the wiki instantly contains outdated information. Since the wiki is more for FAQ/tutorial kinda stuff, and the docs more for hardcore factual reference, it is good to have each section of the wiki refer to pages in the docs where the exact command reference related to the topic can be found.
If you know of topics that have been discussed on this forum before, it is really helpfull to find these threads, and make a wikipage out of the most explanatory posts. Infact, maybe I should be typing this post in the wiki rather than on the forum, it is getting rather long... :)
If additional people want editing access, apply for it on the wiki page.
I will make sure it is linked from the various web pages soon, that should ensure more traffic.
Formatting
To ensure a common text formatting on this wiki, we all should follow some basic rules.
- Create page names properly, they are the page title, and as such, should be written like one. For example: multiplayer_guide should be written as a proper title; Multiplayer Guide.
- Use headings properly, in large blocks of text, these help with the [[toc]] tag. The page name is the title, write a short introduction if need be, then use the first level heading = Like So =. Then subheadings, == Two == and === Three ===.
- Try to keep spacing through the article constistent with the layout for easy reading when, for instances where people are skimming.
- Code/script listings but also one-liners in a reference should be formatted as [[code]].
- In-text code like variables should be //italicized//.
- Directory path's and filenames should be //italicized//.
- Quotes and sauerbraten shell output should be formatted with the {{Monospaced Font}}. If possible, link to the original source.
- Do not use horizontal lines to separate text, use headings.
- Use the **bold** and __underlined__ stuff sparingly. It should be used to highlight only extremely important information; do not use it to differ some text from the rest, that's what //italics// is for.
Special Considerations
FAQ Page
Unlike the other pages on the Wiki, the
Frequently Asked Questions is intended to be a quick stop for commonly asked questions with quick simple answers. If you need more than one or two paragraphs to explain an answer, consider using a seperate page and linking to it from there. This keeps the page concise, and reduces the load on project regulars from people asking questions when they're too lazy to read a large block of text.
Prologue
I'm yet to finish this section, please try to follow the guidelines set down so far, as it will benefit everyone in the end.
- Quin