Cataloging LDP

[Kevin Cullis <kevincu@orci.com>]

Greg,

The one thing which I've seen which has not been touched is cataloging
the LDP. While I see lots of SGML, style, DTD, and other stuff, there
has been nothing which has stated how to find an answer quicker or
organize the information, or "look and feel," so that it's consistent in
finding an answer.  I'll try and tackle that in the VERY near future. 
Below is a brief outline of what I propose.  I'm expecting that this
well affect each and every HOWTO in organization ONLY, not in technical
or stylistic endeavors. Personally, I'm not too interested in that
stuff, however, the quicker I can find an answer to a problem, the
quicker I can get back to work.  Also, the easier it is to find an
answer, the more people will contribute because we've made it easier to
fix problems.  In QA parlayance, reducing cycle time (the time it takes
to complete from start to finish one task and ready to begin again a
repeatable action) means more time to devote to other things.  Reducing
cycle time means that resources can be used elsewhere within an
organization when you focus on reducing process/cycle time.

When it comes to process improvement, there is an equation which bears
watching: process = results!  Taking your eye off of either part will
cause failure.  Failure to watch results means that
competition/paralysis by analysis will eat you up.  Failure to watch
process means costs/erroneous measurements will get out of line.

I'm currently working on a white paper to be the framework of what I'm
proposing.  This is only one section of 4 or 5 that I will propose in
how to organize HOWTOs for ease of use.  My expectation is that once the
LDP has been cataloged, holes of missing or unwritten documentation will
show up and maybe someone will get motivated to contribute.  My
expectation is also that this idea will drive others, i.e. developers,
to do a better job of documenting their work because their work affects
the quality of a product because of where they are within the process. 
Think before doing!!!

1  Process
1.1  Linux Development
1.1.1  Theory/Philosophy
1.1.2  Planning: Architect Design/Requirements Gathering
1.1.3  Coding
1.1.4  Compiling
1.1.5  Testing
1.1.6  Release/Acceptance
1.1.7  Maintenance
1.2  Linux User and Administration
1.2.1  Background Information
1.2.2  Pre-installation requirements (chipset or specifications of
hardware, etc.)
1.2.3  Installation
1.2.4  Configuration
1.2.5  Maintenance/Tune-up
1.2.6  Troubleshooting
1.2.6.1  Pre- and Post-Dependencies of subject matter ( what items
affect it working correctly)
1.2.6.2  Where to go for more info (i.e. to manufacturer for specs)

The one question I have not figured out yet, is how to do a
Beginner/Intermediate/Advanced sort of subject matter.  Should we
reclassify some things to basics/intermediate/advanced?  Let me know.

For those interested in my interests and background, visit American
Society for Quality (http://www.asq.org) or look at Software Engineering
Institute's (SEI) Capability Maturity Model stuff.  You can also look
for Dr. W. Edwards Deming stuff which is the most accurate and thought
provoking stuff in management and process improvement.

I look forward to all of your comments and feedback. Dr. Deming ALWAYS
sought after feedback because he knew he was only one person in a
ocmmunity.

Kevin
begin:vcard 
n:Cullis;Kevin
tel;home:720-489-9283
x-mozilla-html:FALSE
adr:;;8285 S Poplar Way #202;Englewood;CO;80112;USA
version:2.1
email;internet:kevincu@orci.com
x-mozilla-cpt:;0
fn:Kevin Cullis
end:vcard