discuss: Use for mini-HOWTOs (was: revival of the weekly news)


Previous by date: 23 Apr 2003 21:33:26 -0000 Re: Debian UML mini-howto, Morgon Kanter
Next by date: 23 Apr 2003 21:33:26 -0000 Re: Use for mini-HOWTOs (was: revival of the weekly news), David Lawyer
Previous in thread: 23 Apr 2003 21:33:26 -0000 Use for mini-HOWTOs (was: revival of the weekly news), David Lawyer
Next in thread: 23 Apr 2003 21:33:26 -0000 Re: Use for mini-HOWTOs (was: revival of the weekly news), David Lawyer

Subject: Re: Use for mini-HOWTOs (was: revival of the weekly news)
From: Stein Gjoen ####@####.####
Date: 23 Apr 2003 21:33:26 -0000
Message-Id: <3EA5B1E9.9060500@mail.nyx.net>

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.


I agree a lot of (mini-)HOWTOs could be merged, the variouos
Linux plus foreign OS-HOWTOs seem numerous and like a good
collection candicate.

In designing a system with supporting HOWTOs we should make
navigation simple, preferrably not more than 2 levels deep.

> 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.

> 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.

And will the idea of "Application Notes" be used/useful here
or entirely subsumed by the tree structure itself?

> I would also like to suggest (I'm sort of ambivalent on this) the we
> permit mini-HOWTOs to be in plain text, provided that they have a table
> of contents and are not too long.  They would fit into the html package
> as .txt documents.  I guess they could be put into the other formats we
> generate.  


I had hoped the distinction could go away, again to make navigation
simple. Writing a large supporting/mini-HOWTO in plain text could
be counterproductive when it grows beyond a few pages and revisions
are needed.

Regards,
    Stein Gjoen



Previous by date: 23 Apr 2003 21:33:26 -0000 Re: Debian UML mini-howto, Morgon Kanter
Next by date: 23 Apr 2003 21:33:26 -0000 Re: Use for mini-HOWTOs (was: revival of the weekly news), David Lawyer
Previous in thread: 23 Apr 2003 21:33:26 -0000 Use for mini-HOWTOs (was: revival of the weekly news), David Lawyer
Next in thread: 23 Apr 2003 21:33:26 -0000 Re: Use for mini-HOWTOs (was: revival of the weekly news), David Lawyer


  ©The Linux Documentation Project, 2014. Listserver maintained by dr Serge Victor on ibiblio.org servers. See current spam statz.