[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cataloging LDP White Paper: Categorization
From: "Martin WHEELER" <email@example.com>
> On Fri, 17 Nov 2000, David Merrill wrote:
> > I am just going to make sure I keep both HOWTOS
> > and mini-HOWTOs cataloged in my index. And, I'm also going to add the
> > guides eventually.
> > There is a real, tangible benefit to minimizing the "splitting" of
> > It is easier to find what you want when the information is
> > consolidated based on subject area. IMHO, most of these situations are
> > better handled by relegating the "sub" information into a chapter
> > than another HOWTO.
> Umm. Aren't we thinking in terms of conventional print-technology here,
> rather than the hyper-linked text technologies now available to us and
> whose use we should now be advocating?
Partially, yes. We do encourage our materials being made available in
print as well as online.
> And at what point do we start to think about merging the old HOWTOs,
> mini-HOWTOs, Guides, white papers, green papers, odd documents, etc.,
> etc. into a single new format more adapted to distributed access?
I get your drift, but I'm not sure exactly what "single new format" we
would use. It would have to be significantly better than what we have now,
and I don't know that such a creature exists, or would be worth the effort
in any case.
> Gradually moving towards DocBook --> XML is a step in the right
> direction, I know; but as long as text-distribution technology is
> advancing more rapidly than text-production, we're going to be in a Red
> Queen situation (constantly racing to keep in the same place); so at
> what point exactly do we change up a gear, so that we can actually move
> And who makes the binding decisions in these cases?
Well, the authors/maintainers do. I encourage people who propose redundant
HOWTOs to work with existing authors rather than creating redundant
documents, but it is up to the individual authors whether or not they
actually do it.
This is related to Conway's Law:
http://www.tuxedo.org/~esr/jargon/html/entry/Conway's-Law.html "If you
have four groups working on a compiler, you'll get a 4-pass compiler".
> Just as it is inconceivable that any future dictionary or encyclopaedia
> will ever again be compiled or written by a single person, so is it
> inconceivable that the totality of Linux documentation will remain as a
> collection of isolated units, each written and maintained by a single
> person -- instead, we will have a dynamic and constantly evolving whole
> which requires new attitudes and writing methods on the part of its
> multiple authors. Shouldn't we be discussing these, perhaps?
Perhaps, but then perhaps it is getting ahead of ourselves and/or beyond
I would love to see the LDP's cvs be the canonical respository for our
authors, instead of having them each maintain the canonical version on
their own pages. In combination with a free license that allows
modification by others (e.g., me), this would allow us to do
standardizations and add index tags and that sort of thing with
significantly less overhead involved.
Here's an example. While looking at the perl scripts Greg sent me for
extracting data from our DocBook files, I noticed that there are many
lines of code used simply to parse the various date formats. I'd like to
have all our SGML files use a standard (e.g., ISO) date format. To do this
right now, I would have to write to all our authors and ask them to each
do it, and then submit their update. Hardly efficient, not worth the
effort, and so I'm not going to do it.
But is it realistic to think this could be done, or would it be a case of
jousting at windmills?
> I am aware that various efforts are currently being made to produce
> something along the lines of a `Linux Encyclopaedia' -- isn't this the
> direction the LDP should be heading, and isn't this something the LDP
> should be actively involved in promoting? And interfacing with? Rather
> than debating the future of document types which are going to disappear
> anyway? [Eventually.]
Yes, we should be involved in promoting it, as we should be involved in
promoting all efforts at providing Linux documentation. For example, I
monitor other projects, such as Scrollkeeper, but I don't have the time to
actually do anything for them.
David C. Merrill, Ph.D.
Linux Documentation Project
Collection Editor & Coordinator
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com