> Good Idea!
> Regards
> Vitux
>
> Error is human; complete disaster takes a computer
>
> -----Oprindelig meddelelse-----
> Fra: Carl Mummert [SMTP:[EMAIL PROTECTED]
> Sendt: 20. juli 1999 03:57
> Til: debian-user
> Cc: recipient list not shown
> Emne: Re: Suggestion for Newbie Guide Lines
>
>
> >> > I was looking in my mail dir today and noticed my debian-user
> folder
> >> > exceeds 4 Meg for this month. In reviewing the question and answers
> >> > for the last few days, it seems like there is a lot of wasted
> >> > bandwidth.
>
> >> I like the idea of less time being wasted on repeating the same answers
> >> again and again.
>
> One issue: there is already a lot of documentation out there. ( I will
> not vouch for its quality or lack thereof, but volume is something that it
> does not lack). Every package should have a manpage, and often there is
> stuff in /usr{/share}/doc/package also, as well as all the web-based
> documentation.
>
> When a new user starts using Linux, a one problem is information
> overload. Suddenly, the user is faced with 5000 pages of documentation
> (if you take the 'read the docs for every package before you use it'
> philosophy) which of course they do not have the time to read.
>
> Until something breaks.
>
> It is not reasonable to expect a new user to read all those docs
> before inserting the installation disks. Or before they start using
> the system. We don't have the magical ability to change human nature
> here.
>
> One thing that might be nice would be a document that contained:
>
> * ) a list of 'very important' documents - like some Xfree
> docs, whatever else is really needed to install the system
>
> * ) a list of (too) commonly asked questions and answers
>
> * ) a list of places to look for further documentation
> - man/apropos
> - info
> - /usr{/share}/doc/HOWTO
> - online places
>
> * ) a checklist that the user can follow to attempt to report
> (or maybe even fix...) problems as they occur
> Checklists are easy for users to follow, require no
> previous knowledge, and teach processes for fixing things.
> And they might lead to more detailed bug reports, easier to resond
> to.
>
> * ) etc
>
> If this were kept brief (say less than ten pages) then users could
> print it out (but not read it yet) before they start, for reference when
> the system breaks (when they will have the patience to sit down and look
> for help)
>
> Carl
>
>
> --
> Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] <
> /dev/null
