Re: Cataloging LDP

[Kevin Cullis <kevincu@orci.com>]

Randy,

When retrieving information, Process is only one attribute.  The others
are Category, Hierarchical, Index, and Time.  Each HOWTO has each of
those functions "built in" to the documentation, it's just that no one,
other than myself, have identified them.  The question that I'm working
on, via the white paper, is how to organize it.  Ultimately, the HOWTOs,
as I see them, will be rewritten (i.e. reorganized) to take into account
this cataloging of information for easier retrieval.

Does this help?

The more difficult issue is since, I"ve heard, that Info pages are to
replace man pages, how to reconcile this issue.  The other issue is some
may consider this as a "standardization" of the HOWTOs and some won't
want to participate.  But as someone who trys to reduce the time it
takes to do things, taking repeatable actions or ideas (much like icons
and menu bars are to the GUI) and "standardizing" them is a benefit.

Kevin

Randy Kramer wrote:
> 
> 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
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