Hello, Am Mittwoch, 23. Dezember 2009 schrieb Frank Sundermeyer:
Purpose of namespaces: ---------------------
Namespaces allow to _separate_ between content for the _editing community_ (like howtos on writing articles, guidelines, etc) and _readers_
For openSUSE, one could also say: "... to separate between content for 'normal' users and developers". The docs on mediawiki.org base on the assumption that all "real content" lives at one level ("could be interesting for everybody" - that's valid for any wikipedia article) and has the same audience, aka "readers". OTOH, the openSUSE wiki has content on multiple levels: - documentation for "normal" users - information for development, packaging etc - project-related information (teams, meetings etc.) - ... While it might sometimes be hard to draw a line between development and project related content, it is quite easy to separate the "normal user" documentation. BTW: Wikipedia has lots of "sister projects" (wikiquote, wikispecies, wikisource, wiktionary etc.) Basically they could also handle them as namespaces - that would be somehow comparable to the content of the openSUSE wiki ;-)
How are pages outside the main namespace handled? ----------------------------------------------------
However, there are two other main differences: * a regular search will _not_ find any pages outside of the main namespace, because the default search is limited to the main namespace
And exactly this is why I recommend to have multiple namespaces. It is extremely important to be able to search in a specific "part" of the wiki. To give you an example: I don't consider myself as "normal" user, but I still sometimes have to search the documentation. Being able to limit my search to the main (user doc) namespace is very important then, because random matches in KDE meeting logs won't help me with my KMail configuration ;-) BTW: Don't get me wrong - I don't want to split the community into "users" and "developers". Those are just different roles, and people may switch between those roles as often as they want. And they should be able to search only pages that match their current role ;-)
Now my 2 cents:
* Having read the above, it IMHO should be clear that it does not make sense, to divide the content into different namespaces such as developer, news, etc. Nor does it make sense to use the existing SDB namespace in teh future.
Well, I could now start a section reading... Purpose of software documentation --------------------------------- Software documentation tells you ("the user") what the developers had in mind when they developed their software. Especially, it will tell you how to use the software. Be warned that the documentation is always written from the developer's point of view, which might not always match your situation. You should always read the documentation, but in some cases you should just ignore the documentation and do what you think is the best solution for your problem. ... but I will just tell you that you can't always trust the documentation to match everybody's situation perfectly ;-) *SCNR*
* Since the default namespaces cannot be deleted we should utilize them before introducing new namespaces - e.g. "Help" for editing instructions, describing extensions, or openSUSE (aka Meta) for guidelines, etc.
ACK, good idea.
* We do not want people searching for an article to be pointed to a portal page rather than to the article itself. Therefore I would suggest to put them into a to be created namespace Portal
ACK
* Apart from "Portal" I would not add any other namespaces, but rather delete the custom ones we now have /howtos, faqs, SDB, SDB talk
NACK, see above and the namespaces proposed by Henne and Rajko (in the "Final preparations" thread and also some weeks ago). Regards, Christian Boltz -- Nur beim Account meines Hundes (der ist mein Test-User) sind alle Desktop-Icons weg [...] Aber der geht eh nicht so oft an den Rechner. [Bernd Kloss in suse-linux] -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org