Re: Zynot Documentation/Marketing Vision

> Zynot Documentation/Marketing Vision

First let me thank you for putting this semi-document together.  I 
personally don't have the skills to do development.  I understand 
enough of development concepts to be really dangerous, but I can help 
do things like conceptual design and identify resources needed to 
accomplish a given task.

My interest in joining the project has been looking toward 
documentation.

A major downfall of every distribution I've ever messed with is a lack 
of good documentation, especially in the area of troubleshooting guides 
and technical problem resultion assistance.

Gentoo has a pretty straight-forward installation guide, but once 
that's done, at least in terms of easy access for a new user, it seemed 
to me to be catch-as-catch-can on IRC.

Debian's installation documentation is pretty good, but again, 
explanation of things like networking configuration has always been 
hard for me, and I'm someone who's relatively educated with respect to 
Linux distributions.

I've bought the professional docs for things like RedHat and SuSE and 
again, found them lacking for problems beyond initial simple 
configuration.  ISC's dhcpd, for example, has a plethora of options 
that an intelligent administrator might find extremely useful, but I 
had a hard time deciphering the man page.  It shouldn't take me two 
hours of trial and error with dhcpd.conf when a well written doc would 
have helped me immensely.

For a well-packaged and professional distribution (which is a good 
goal for a product meant for the professional world), fix docs are 
vital to reduction of our support costs and the increase of the value 
of our product to our customers.

We need documentation of APIs.  We need documentation of install.  We 
need simplified and more complete documentation of common utilities, 
the structure and execution of /etc/init.d, the order in which various 
system services are brought up (both before and after init.d is run), 
and how to manipulate and control those services effectively.

We could use a kernel compilation troubleshooting guide, because a 
custom kernel is frequently vital to a custom implementation.  
Especially with the new problems of gcc and kernel v2.4.19, a 
comprehensible documentation consisting of more than just a Perl and 
awk/sed script fix is well warranted and will go a long way toward 
enhancing the respect with which our distribution will be viewed.

I'm ready to help find the places where we should start a ZDP, and help 
identify what we should document first, and coordinate documentation 
with development, because they go hand-in-hand.

ag