Re: Cataloging LDP

[Randy Kramer <rhkramer@fast.net>]

Kevin,

If "process" is the first major heading in your catalog, what is the
second?

Randy Kramer

Kevin Cullis wrote:
> 
> 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
> 
>     ---------------------------------------------------------------
> 
>                                Name: kevincu.vcf
>               Part 1.2         Type: text/x-vcard
>                            Encoding: 7bit
>                         Description: Card for Kevin Cullis


--  
To UNSUBSCRIBE, email to ldp-discuss-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org