LYNX-DEV comment -- drowning in information

[VaX#n8]

I like Lynx -- a lot.  You folks have done a great job.
I used text-mode and lynx on my NetBSD/x86 machine for a LONG time after I had
installed XFree86, and now I'm going back to it occasionally for security 
issues.

I am amazed by the amount of information both on the web site and
in files distributed with lynx.  I think that information is better than none.
But while upgrading from Lynx 2.4.2 to 2.6, I found myself confused when trying
to decide if I needed to keep local modifications to particular files, or
if there was a new mechanism for achieving my goals that was cleaner and/or
more flexible.  Installing lynx is no small task, and if you are a perfectionist
it can be time consuming and frustrating, if not impossible.
There is a serious amount of duplication and fragmentation of information
(and alliteration) that leads to user frustration.

I can see several reasons why this has happened:
1) it is a piece of free software (lack of time resources)
2) web technologies (sorry for the marketspeak) are changing fast
3) complexity of protocol configuration
4) handoffs from one developer base to another

I can see several reasons to fix this:
1) to save developer time on changing duplicate info
2) to increase the number of pertinent bugs reported by users
3) to save developer time on erroneous bug reports caused by out-of-date
   or stale info, and on stupid questions like "where do I get FOO"
4) ease of use/installation

I see some more stuff that needs to be addressed:
0) I see http://lynx.browser.org/ as a great starting point
   (and it's easy to remember).
1) information decay
   If lynx.browser.org is the starting point to find the most recent 
information,
   and other data (documentation distributed in the tarfiles, other web sites)
   is a subset or replicate of that information, the subsets and replicates
   should be clearly marked as such, with pointers to the live versions.
2) functionally organized documentation
   Organize the documentation based on what the intended audience is,
   and what they are trying to achieve.
   This is the weak point of many a web site.
   As far as I can see, there are a few tasks involved:
   2.0) obtaining
   2.1) using
   2.2) installing
   2.3) trouble-shooting
   2.4) developing
3) duplicate elimination
   there is a rat's nest of files which give information on reporting bugs,
   finding the newest version, help files, etc.
   e.g., if the mailing lists needed to change homes from sig.net,
   about 28 files would need to be changed in the 2.6 dist.

I know, I know, put my time where my mouth is.
I don't think there is as much work to be done as this message might seem
to indicate.  I'll offer to coordinate between the various groups,
and do some of the grunt work (for example, rewriting INSTALLATION), but
I'll need at least grudging acquiesence from people with the authority
(development, web maintainers, mailing list managers) before I commit hours
to this stuff.  However, I _will_ be compiling something for installers
as I work on it tonight.

Please, don't let information entropy get to lynx the same way it did to CVS.
(CVS now has a paper or three, website, FAQ, manpages, infopages, and source 
code
which are now all way out of sync)

I am not on lynx-dev, so keep me in any replies.
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;