Re: Re^2: directory structure - 2.
Return-path: <brinkmds@localhost>
Received: from brinkmds by flora with local (Exim 1.891 #1 (Debian))
id 0yPpMp-0001Gb-00; Thu, 16 Apr 1998 16:10:19 +0200
Message-ID: <19980416161019.65312@flora>
Date: Thu, 16 Apr 1998 16:10:19 +0200
From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Marco Budde <Marco.Budde@hqsys.antar.com>, debian-doc@lists.debian.org
Subject: Re: Re^2: directory structure - 2.
References: <[🔎] 8b4_9804152220@antares.antar.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <[🔎] 8b4_9804152220@antares.antar.com>; from Marco Budde on Wed, Apr 15, 1998 at 07:10:00PM +0100
Sender: Marcus Brinkmann <brinkmds@localhost>
On Wed, Apr 15, 1998 at 07:10:00PM +0100, Marco Budde wrote:
> Am 14.04.98 schrieb Marcus.Brinkmann # ruhr-uni-bochum.de ...
>
> Moin Marcus!
>
> MB> No offense meant, but I find this sort of ordering very inefficient for
> MB> the users. If I need information about my SB AWE soundcard, where do I
> MB> look?
>
> sound and HOWTO.
It's easy if you know that it is a HOWTO and that HOWTO's even exist...
> It#s very difficult to find a good structure. This is one
> of the problems of a lot of WWW sites. Maybe some of Christians ideas (/
> users and /devel) are not bad.
It is not too difficult for me (probably because I've worked a bit in a library
and have interest in information storing). I think Christians ideas are very
good and point in the right direction.
Probably all this confusion is because you think of the implementation (how
to store the files in directories etc). I don't do this. I think how the
user will see it.
> MB> The ftp organization has absolutely no connection about finding
>
> But it shows the needed sections.
It shows just what software is available.
> MB> information. It has something to do with finding packages/software, and
> MB> even here I often guess wrong when I look for a specific package via ftp.
>
> I#ve got the same problem, but in most cases this is caused by the
> maintainer, because he uses the wrong section.
If it is not clear, where to place a package, this is a sign of how
suboptimal this structure is. However, it is enough for ftp server.
> MB> This is the wrong approach. You should know that libraries don't sort
> MB> books by publishers, size or color. They arrange them not in alphabetical
> MB> order, too (alphabetical ordering is the *last* criterium). There are
>
> Really? In most libraries they#re sorted by topic (like our section) and
> alphabetical.
Did you actually read what I wrote? The three letter system I explained in
great detail is sorting by topic in three orders of specialisation. And only
books in the same category (with all three letters equal) are sorted
alphabetically.
> MB> Algebra and so on. The third letter gives even more information. For most
> MB> books, you can say what information is in the book just by knowing the
>
> Well at our library at the TU HH there#re only numbers (10 digits) on the
> book.
Is it a university for a special subject of study? Then the usual three
letter format does not make sense, because those are intended for public
libraries with all sorts of books. If you have only a few thousand books
about mathematic, you *could* invent a similar system, but it is not really
worth it, as a lot of scientific books are very specialised in topic. In our
math library, there are a few top categories (tables, lexica, etc) and then
alphabetical ordering, which is sufficient.
The analogy is, that if you have only documentation about common unix
commands, you can make a few sections (file management, shell built-ins,
etc), but further ordering does not make sense.
But we are planning for a wider range of different documents, therefore the
structure should be carefully chosen.
> MB> The people that invent such structures take a lot care about this, and
> MB> they know why. Searching in a big library for information can be a pain.
>
> Why? You enter some interesting words and the computer finds some good
> books. I would never look on the number/code of a book.
??? I never was in a library where you enter a few interesting words in a
computer, and the computer walks away and brings me the books. YOu must have
good libraries in TU HH.
Serious: I know what I speak of (as I worked a bit in a library).
I would only waste my time with a computer in a library if I know the author
and the title of the book. I'm faster when I look for the books myself.
There is only little information the computer can give me, and dumb keyword
searching often fails to find the right books.
> MB> ordering, but it does not take into count *one* of the important things
> MB> you need to make information easy accesible.
>
> I don#t know which is the best solution. Let#s start with the structure
> itself. We could discuss the other problems later.
? Have the right structure and there are no problems. I'll make something up
(probably based on all the mails on this list) and present it here.
> MB> We should not be too picky about a structure now: It will evolve when
> MB> documents are added. However, we should have a *solid* base for a starter.
>
> That#s it. A maintainer could always add new directories (see dhelps
> <dtitle>).
You are thinking in the wrong terms here. I don't speak about directories. I
don't even speak about files. I speak about accesing information (what the
user will see).
I'll leave most implementation issues to you and other folks.
> MB> I think we have the following main levels:
> MB> Debian
> MB> Administration
> MB> Development
> MB> Using (weak word, has someone a better word?).
>
> Maybe you#re right. User, Applikation? But we need sections for something
> like FAQs, HOWTOs, books and magazines. How should we call this root
> section?
I'm not sure if I agree that we need such a section, but I haven't finished
my suggestion yet. Please have a bit patience.
> MB> For example, all X related documents could be stored in a single tree X,
> MB> but the individual documents should also be find below Administration,
> MB> Development and Using.
>
> I totally disagree. The maintainer should split the X11 documentation like
> this
>
> admin/x11
> devel/x11 or better devel/libs
> user/x11
Let's not too soon get too concrete. I was speaking about orthogonal
branches of storing the documents. I'm not sure if this is needed, but I
will explain it in my yet-to-be-posted suggestion. Maybe it will be more
clear than.
But it's good that you see the benefit of splitting the documents in a
hierarchy.
> MB> I see no problem in using several main branches: There could even be a
> MB> branch that has all Apllications (similar to the menu system), that
>
> 100 documents in one directory? A very bad idea. And I don#t like the
> system used by menu (or dwww). This will not work, if we have got hundrets
> of packages using such a system.
??? You didn't understand me at all. You have only a single depth in mind,
I have subcategories in mind (Apps/Games, Apps/Editors) etc, as it is used
currently by the menu system. And it does work. Check your local X Debian
menu.
> MB> collects the documents related to a single program. Maybe this is what
> MB> Marco has in mind?
>
> I don#t understand this. Please give an example.
Well, I will. I'm not sure how long I will need. Probably a few hours,
probably until Saturday.
> MB> However, we should have one or two such main branches (maybe the one above
> MB> and the "Application" branch that are mandatory for every document. This
> MB> would mean that every document has to register at least once in each of
>
> I don#t understand this, too.
If you prefer the documents to reside in a ftp-like organised tree, or a
tree like the menu system or however, every such model would be a "main branch".
It would be wise to keep the number of "main branches" low (one or two),
because every document has to be found in evry main branch at least once.
I'm not at all sure if this is needed at all, I'll think about it.
> MB> Note that this question is very related to the structure of the Debian
> MB> FAQ-o-Matic, and I think they could probably be build after the same model
> MB> (maybe this would give the faq-o-matic a push). Please also note that this
> MB> does not mean that we should take the structure from the faq-o-matic (I
> MB> wouldprefer the other way round ;)
>
> Could you please post the structure of this system.
Ok, I'll do send my draft as soon as I've finished it.
Marcus
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: