My philosophy doesn't entirely match those of wikimedia's contributers, however, we seem to be working ok together, and i hope to be swayed, and sway a few people back.
I have done some edits, like moved the full file list to it's own page, because I thought it was too long. I sorta waffled on this item, but... onto my philosophy:
What should be handled by the software
The sofware should be fairly basic, with searching capablity
There should be macros for commonly done stuff. If it is done often enough, it should, without changing the wiki code, be able to added as a feature.
All wikitext should be human readable.
People should fork the pages if they have differing views. If a page is a "main page" the person who wants least stuff there should win, as long as there are links to the other stuff. One can always create a: "bob's guide to editing" where he includes tons of pages into a single manual.
Wikis should be very quick to navigate, and to develop. I mostly don't want to care about server speed... so I'm interested in creating a P2P wiki system that aleviates this problem.
Apropriateness of Wikis
I believe that a wiki should be able to take the role of CMS software, and all the other things mediawiki is listed as not being, as listed in Wiki uses
I am constantly bothered by wikimedia's case sensitivity. I think that it was choses out of development ease, and should be reserved for certain namespaces.
I think all articles should start in the main namespace, and get moved as neccissary to the "appropriate" namespace when needed. disambiguation pages are not bad things.
A wiki article for knowledge bases shouldn't be more than 3 printed pages long.
A wiki article for an encylopedia page... shouldn't be much longer.
There should be lots of pages, with little duplication. This gets inconvienient when one wishes to print an entire procedure, or guide book, so I have listed in my desired features a mechanism to take care of this common problem.
A wiki needs whitespace between paragraphs to help people sort the content of a wiki. WikiMedia also allows editing of header sections, which makes headers very important for very long lists. Very long lists also get a quick index automatically at the top! which is very helpfull for navigation
Table of Contents
The table of contents feature is very very cool. It, by default, appears at the top of the page, and allows for quick access to parts of a long page. I, however, do not like long pages, as it leads to recreation of work... but it happens, and this is a way to deal with it.
I will be editing my css style sheet to place category listings at the tops of pages. If category pages are at the top of pages, it will help people find the related article quicker, and avoid recreation of work.
For pages where it's not appropriate to place it into a category, one should place a member of:WikiLink at the top of the page, so one can get to the appropriate category. Most of the time, one should just put the page into the category, however, a problem arises when a category gets too full, and a sub category better describes the page in question.
Use summarizing headers and titles / outlines
The table of contents, of headers in this wiki are absolutely fantastic. The header should contain enough information to express your idea, or remind people instanty of your idea if it is very complex.
My account at slashdot, ( aaron_pet ), uses the signature: Please use informative/summarizing subject lines.
This includes in talk pages, and email, instead of replying with just a Re:(former topic) reply with "(summary of my answer) Re: (former topic). (note: This will NOT break properly threaded mailing lists!, as they use a specific mail header to sort, rather than the subject line!)
If the subject line gets too long, start using... abreviated language, or shorthand(leave out vowels), or just make a string fo the first letters... example: Re: (former topic) --> (something that is probably too long and should be thought about more type of reply) Re: ft