Hi Michael,
the NON Public Wiki makes in my mind sense to fill up the existing content in the new form and structure, until this is done i think you are right if somebody feels disturbed because of the missing content he could write it on his own (might be nice ;-) .  Another point could be, to prevent miss-information in the official Wiki the other helpers have a chance to correct and/or discuss (endorse specifics where they have better experience) the technical quests (might be nice too :-)=). Another thing is sometimes there are serious user faults (mostly mine) on the wiki code and the illustration of some wiki sites arenīt discussible, so it needs sometimes a little until somebody (mostly eXciter) helps out with his wiki knowledge. Also if someone couldnīt finish a whole theme and he needs a couple of days to finish it up, the danger that some beginners try to use an uncomplete way is in NON Public minimized. 
So for donīt messing around with these cases the NON Public Wiki can be a nice solution... thats what my thoughts about your first question. 

Your propose causing the format:
The short variation are much more suitable i agree with you but for some sections it is hard to observe causing the largeness, example can be found in her 
--> http://wiki.ipfire.org/nonpublic/de/configuration/network/proxy/configuration/settings  

so it is a little bit like a balancing act cause some areas need only a few information to get a clear knowledge transaction also to beginners, some other different areas (cache management, authentication methods, ..) needs quiet a lot more. So to handle all basic information on one Wiki site is possible, but it would be quiet large and unclear then. Also if additional informations from other user get round then, the clarity becomes more worst, what du you think about this ?

Another question is, should it be important to document every .cgi option ? Some functions are explained themselves but where is the knowledge border or in other words what should be well explained and what doesnīt need a explicitly explanation.

So iīam a little bit in a layout dilemma and quiet happy about a good example for a possible solution.


Thanks for reflection

Erik

 


Am 04.01.2012 um 15:20 schrieb Michael Tremer:

Happy New Year 2012 for you all too.

I'm excited to see what those changes are, but here some of my opinions
on it:

* Why is there this non-public area? I normally edit the wiki entries
  directly. This has advantages that you don't have to move content
  around and you can keep the history of changes.
  If you feel that users may be disturbed by the changes, I think that
  is okay. If they are bothered they should go and fix it by
  themselves. That's what a wiki is about.

* I propose a format like this:
  === General settings ===

  == Parent proxy ==

  The proxy sends all requests to the parent proxy instead of sending
  them directly to the internet.

  [[Vorgelagerter Proxy]]

  You will get an idea of what there is to find on the sub page but
  you don't have to read it completely. So I guess that would make
  the proxy page (and generally all other pages as well) more readable
  because one may find the interesting stuff faster.

Tell me what you think about it? What pages could be redesigned in this
was? Where are the big problems?

Michael

On Tue, 2012-01-03 at 22:20 +0100, Erik K. wrote:
Hi all,
i want to inform you that the new Proxy Wiki in the NON Public Wiki
section
--> http://wiki.ipfire.org/nonpublic/de/configuration/network/proxy are developed (still be in early stages) new structure and content. I will try it pretty much to arrange in the way like i did it with the OpenVPN wiki --> http://wiki.ipfire.org/de/configuration/services/openvpn .
Ideas and enhancements in knowledge, design and structure are highly
appreciated. This Wiki is not online so it is possible to be mental on
it ;-) .


I want also use this possibility to wish you all a nice and pretty
cool 2012 .


Best regards


Erik




_______________________________________________
Documentation mailing list
Documentation@lists.ipfire.org
http://lists.ipfire.org/mailman/listinfo/documentation