LYNX-DEV Re[2]: reorganizing the lynx-archive

[Robert Bonomi]

+ Date: Fri, 8 Nov 1996 12:26:21 -0800
+ From: address@hidden (David Combs)
+ To: address@hidden
+ Subject: Re: LYNX-DEV Re: reorganizing the lynx-archive
+ 
+ More on same (reorganizing the archive):
+ 
+ Also, people like me who submit ONE email with THREE (say)
+ subjects discussed, must be convinced to submit three
+ SEPARATE emails (which will make them think, are each
+ of these really important enough to submit and subject
+ each group-mbr to).
+ 
+ QUESTION: "TRN" turns each thread, somehow, into a branching
+ tree.  On what basis does it decide on starting a new
+ branch (sub-thread).  Is it just the subject line?

TRN makes -no- use of the subject line, in point of fact.
It uses the 'article numbers', and the 'references' header line
to do its 'magic'.  Any 'folllow-up' article contains a header
with (at least) the ID number of the  =immediate=predecessor= 
article to which it is following up.  TRN merely tags that new
article as a child branch of the parent.  Thus, each -independant-
response to an original posting starts a _separate_ branch.
OTOH, a response, then a 'response to the response', and a 
reply to the response to the response, and a rejoinder to the
reply to the response to the response, string out as subsequent
elements in a single thread.

Note:  trn has a _lot_ of stuff in it to handle the situation where the
reply-to-the-response arrives before the response; what to do if an article
shows up claiming 'parentage' that trn thinks are two un-related (bastard??:)
threads, etc.   _None_ of those smarts are needed in this case, since the
re-mailer *has* an "authoritative" list, and _always_ sees the elements in
a 'thread' in order (by definition :).

+ 
+ QUESTION: would it be worthwhile to have SUB-subjects
+ down WITHIN the email (like in a book: chapters, sections,
+ etc), and maybe someone (not me) hack hypermail (or trn!!!)
+ to make it work with this?

This could be done, _relatively_ *trivially*, by hacking the re-mailer to do
some more massaging of the 'Suject:' header line.  It would need 
to do the following things:
  1) prepend  "LYNX-DEV [i.d.-number]" to the Subject line -before-
       sending it out.
  2) When a message -arrives-, with a "Re: LYNX-DEV [i.d.-number] {blah blah}"
           Subject header, *remove* the "LYNX-DEV" label that occurs to the 
_right_
           of the 'Re:' .
  3) if there is more than one 'Re:', remove all but the first one.

  4) optiion:  May want to 'prune' the 'list' of ID numbers (to keep the 
         subject line 'managable', to just the current id, and the one of the
         message being referred to.


Example:
   new article        header: LYNX-DEV [47] Trouble Compiling on MVS.

   somebody responds  header: LYNX-DEV [54] Re: [47] Trouble Compiling on MVS

   a reply to that    header: LYNX-DEV [56] Re: [54][47] Trouble Compiling ..
   (or, compressed)           LYNX-DEV [56] Re: [54] Trouble Compiling on MVS

  somebody responds to the original,
  apparently _not_ seeing the prior
  response            header:  LYNX-DEV [80] Re: [47] Trouble Compiling on MVS


It is now a 'nothing' operation to string things together into 'threads'.

+ 
+ OR: how about this idea:
+ For producing manuals, letters, etc, I use the old CMU program
+ "Scribe" (greatly enhanced by people who took it over
+ from Brian Reid), which has a nifty "index" facility,
+ to create the back-of-the-book index.
+ 
+ (Other such programs have similar facilities).
+ 
+ So, in Scribe you can create your own macros, eg @myIndex(word, description),
+ to use like this:
+   This is done by foo, a neat program.
+ becomes
+   This is done by @myIndex(word="foo", description="Here we mean the
+      foo PROGRAM, not the foo ATTRIBUTE."), a neat program.
+ 
+ Stupid example.  Anyway, the "foo"-listing in the index will
+ have that description stuck out to its right, followed by
+ the page numbers it appears on.
+ 
+ QUESTION: does the above concept lead to any IDEAS about
+ how FUTURE email could be structured (it is too late probably
+ for the EXISTING stuff -- way too much to do)?

Probably the most viable way to do this is with a 'structured' arrangement
to the *body* of the email.  This 'structure' can be automatically enforced
by the re-mailer, returning any 'non-conformant' messages to the sender,
ALONG WITH info on how to format a 'correct' submission.

I see several 'classes' of material on this list:
   1)  'configure/compile' problems -- e.g. "I'm installing on FOO v. 89.543,
                   and make dies with the following errors:  <blah blah blah> "
   2)  'design issues', or 'forward plans' -- e.g., "using GNU autoconf"
   3)  "patches" -- feature adds, bugfixes, etc.
   4)  "Anomolous behavior" reports -- e.g. "things don't display right when
                  I look at http://foo";, or "lynx crashed when I did ....."
   5)  "wish list" -- desirable features for future implementation.
   6)  Resources -- web sites, the LYNX enhanced pages, "browser.org", etc.

note: there *is* some 'blurring' between 2) and 4).  discussion of an
existing (real) problem tends to lead to 'what should we do about it'
discussions.  similarly, design issues may lead to patches. :)  One 
does -not- want to segrate by class, therefore.

Suggest that the following is relevant to any/all articles.

     LYNX version:
         Hardware, O/S:
     Message type:

'LYNX version', and "Hardware, O/S'  are critical for dealing with 'install
problems' and/or 'bug reports'.   Some design issues and/or patches are
specific to particular environments, others apply to 'any or all'.

There is an -added- benefit to requiring people to specify the -version-
in a 'machine-readable' form. If someone is filing a 'bug report', and they
are running an old version, an _auto-response_ can be generated explaining
those facts, and pointing towards location of a current version.

I'd propose the following for 'message types':
    'install problem'
        'development plans'
        'patches'
        'bug report'  and/or 'problem report'
        'resources'
        'wish list'
        'other'  and/or 'misc.'


ADDITONAL COMMENT:  *anyone*, who is -not- a subscriber to the mailing-list,
   and who SENDS MAIL *TO* it, should get an auto-response telling them about
   the archives, and that they should check _there_ for responses to their
   problem, as they *may*not*get* an individual response.  I, personally,
   know of three people who submitted problems, per the directions from
   lynx's 'fatal error' handler, and never heard so much as a 'thank you'
   for their efforts.  *NOT* good 'public relations'!  


;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;