discuss: Use for mini-HOWTOs (was: revival of the weekly news)
Subject:
Re: Use for mini-HOWTOs (was: revival of the weekly news)
From:
David Lawyer ####@####.####
Date:
24 Apr 2003 06:23:09 -0000
Message-Id: <20030424062310.GA339@lafn.org>
> David Lawyer wrote:
>
> [snip]
>
> >In some cases where HOWTOs cover the same ground, they need to be
> >merged. But in many cases it's better not to merge but have an
> overview >HOWTO supported by a number of mini-HOWTOs for special
> situations. For >example: a mini-HOWTO about Linux support for
> certain brands of >hardware (printers, modems); how to do something
> using a particular >distribution. The overview HOWTO needs to point
> to the minis that >support it and conversely. Thus the general
> principles are elucidated >the the overview HOWTO and don't need
> repeating in the supporting minis. >Thus a beginner needs to first
> read the overview HOWTO and then the >appropriate supporting mini
> while an expert could just read the >appropriate supporting HOWTO. Of
> course our database would need to map >these supporting howtos (child)
> to the overview (parent) howto.
>
On Tue, Apr 22, 2003 at 11:19:37PM +0200, Stein Gjoen wrote:
> I agree a lot of (mini-)HOWTOs could be merged, the various Linux plus
> foreign OS-HOWTOs seem numerous and like a good collection candidate.
Yes, but instead of merging some "foreign" ones could be just shortened
by having some general information for internationalization in one
overview howto. Then each language would have a mini-HOWTO mainly for
things unique to that language. The overview howto would need to be
translated to various languages. Even with this setup, it's nicer to
have the entire topic covered in a language-specific howto which also
contains the relevant overview stuff. But this makes writing it more
difficult (it's longer). So I envision both types co-existing.
> In designing a system with supporting HOWTOs we should make
> navigation simple, preferably not more than 2 levels deep.
It's hard to know in advance how many levels deep it might get.
>
> >It would be nice if the author of the overview howto could review the
> >supporting child howtos. In some cases, "supporting" HOWTOs could be
>
> This might be a good way of getting more reviewers but might
> also be seen as a pressure. My Multi Disk HOWTO refers to a large
> number of other HOWTOs but I do not have the capacity to review
> updates of these regularly.
What about asking for help via Lampadas (which we don't have yet)?
>
> >regular long HOWTOs. For example, a network HOWTO could have long
> >"supporting" HOWTOs on various types of networks. Does anyone have a
> >better name than "supporting"? It has sort of an inferior connotation
> >to it, especially if the supporting HOWTO is longer and took more work
> >to create than it's overview (parent) HOWTO. It's a tree structure
> >where overview HOWTOs could be (at the same time) supporting HOWTOs for
> >a still more general HOWTO>
>
> Can you propose a way of letting our readers navigate these with
> ease? Perhaps this is a hobby horse of mine but I feel this is
> an important issue that is not entirely trivial.
I can't. If one is off-line and doesn't have the other doc that is
pointed to, it's impossible to "navigate". Different distributions may
arrange the docs differently and name directories differently. Minis,
regular howtos and/or guides may be in different directories. Also, the
docs on ones computer disk may be stale.
One thing we can do to improve things is to make it easier to find a doc
when one goes to a LDP mirror site. If you have the name of a doc you
want, it's not the easiest thing in the world to find it even after you
get to a LDP mirror.
>
> And will the idea of "Application Notes" be used/useful here
> or entirely subsumed by the tree structure itself?
I really shouldn't have said a tree structure. Two different parents may
claim the same child, etc. It's a tree with some cross links so it's
not really a tree.
[snip re minis in plain text]
David Lawyer
