Conference vaxuum::document_ft

    Bravo! I concur with Rose. Please start a new conference. (Perhaps
    it is time to archive the old DOCUMENT (BL6) conference?)
    
    --Andrew

You've read our minds! Starting a new notes file is something we'd like to
do also. How's this for a scheme:

1. We'll archive the old DOCUMENT (BL6) conference and reappropriate the name
DOCUMENT.NOTE for our new conference.

2. We'll write-lock this conference, but keep it around.

3. When people access this conference,the notice will point them to the new
conference.

4. All of this will take place sometime over the next few weeks, 
with plenty of advance notice.

Comments?

--Brian

    Go for it!  (The sooner, the better.)
    
    	-hkc

    Given that this conference covers BL7, BL8 and (for a while) V1.0,
    there's a lot of obsolete information here.  At the same time, there's
    a lot of useful information that should be saved.

    I've participated in a number of conference that have gone thru "let's
    create a new conference because the current one is ...".  Although the
    original conference is retained as read-only, what inevitably happens is
    that the conference is instead retained as never-read.

    It usually takes a couple of months for many of the same questions to
    be asked and answered, with frequent vague pointers to the original
    conference.

    I think that the best solution would be for a moderator to clean the
    dead wood out of this conference.  I realize that would be quite labor
    intensive.

    -- Ward

    Perhaps the new conference could start with notes on:
    
    1) Known problems
    2) Known wishlist items
    3) Useful tips
    
    All extracted from the current conference (and applicable to V1.0).
    I agree with Ward that we don't want to lose this information, but
    we also don't want to confuse people by making them read notes on
    bugs that have already been fixed. Anyway, it is a suggestion...
    
    --Andrew

    The suggestions made in .5 make a lot of sense. Except that already
    very busy developers are made extra busy sorting out the goodies
    from this otherwise outdated conference.  
    
    I vote we just write-lock it. Those who care enough about the wishlist
    items can reenter them in the new DOCUMENT conference. Those who
    encounter problems with V1.0 (that are not covered in the release
    notes) should be allowed to raise them in the new conference--without
    being subjected to replies such as, "That's been discussed in old Note
    nn.n of DOCUMENT_FT." 

    Well, yes, pulling out useful hints may be time-consuming (any
    volunteers?) But the program team is going to have to make a list
    of all the known problems and wishlist items for phase #0 or #1 
    of V1.n won't they? 

    --Andrew

    I'd vote to move to a new file ONLY when the V1.0 kit is released
    over the network, so that we're all talking about the same base
    level (or at least we're not in field test).
    
    Rose,
    
    What's Ben Hur got to do with DOCUMENT?

    re: .9, Ben Hur and DOCUMENT --------- excitement!         :-)

    When the new conference is created, I suggest that the moderators set
    the administrative topics (e.g., introduction, kit location) to
    "no write" so that casual users cannot clutter the topics with
    extraneous notes.

    If you want an example of what happens when these topics are not
    write-locked, take a look at 1.* -- not a pretty introduction for
    first-time participants.

    -- Ward

    One of the main reasons that we're faced with moving to a new
    conference is that a large portion of this conference is no longer
    relevant to DOCUMENT V1.0 and no one has the time to pull the weeds and
    leave the desired plants.

    The problem of out-of-date notes can be significantly reduced by
    following the lead of other products and create two new conferences:

	DOCUMENT.NOTE      -- general discussion of DOCUMENT usage,
			      futures, ...
	DOCUMENT_BUGS.NOTE -- just bug reports

    The DOCUMENT_BUGS conference can then be periodically renamed and
    archived, leaving the general discussion conference in tact.

    This has the additional advantage of segmenting the discussion so that
    interested, but busy, participants can focus their attention on just
    one conference and catch up on the other as time permits.

    -- Ward

I had hoped to get the new notes file off the ground before leaving for
vacation, but that is not to be. Therefore, the switchover will take place
during the week of 8/24. We will be switching to a single conference for
both bugs and general discussion (rather than two separate files) with heavy
usage of keywords to label bugs and assign problems to the developers 
responsible for the relevant components. At that time, this file will be
write-locked.

In the meantime, PLEASE use keywords wherever possible.

Thanks,
Brian

Suggestions for keywords to add to the new notes file when you set it 
up:

PROFILES
REVISION_TAGS  (<update>, etc.)
CONDITIONALS
DESTINATIONS   (for generic destination problems, like things to
                to do with DESTINATIONS.DAT)
TABLES        (to be consistent with TAGS,FIGURES,GRAPHICS,etc.)
TEMPLATES     ("                "                "             )


doctype keywords:  REPORT           (so problems can be related to
                   SOFTWARE           a specific doctype)
                   SOFTWARE_SPEC
                   etc.

HEADERS_AND_FOOTERS  (because it's a popular topic)



What is the meaning of RTL?  It's a keyword I've never used...


Rose

    Is something like the following possible (or necessary, or desirable)?
    
    1. A "banner message" to the effect: Read Note NN before writing.
    2. Note NN: an index of keywords on the order of the 
       EASYNET_CONFERENCES note (1.2?) which lists updates to the
       conferences. 
    3. In addition to the keywords already suggested, <TAG_NAME> keywords
       to be added as the occasion arises, with amplification in the 
       Note/Reply title, e.g.: <TABLE> question, <TABLE> bug,
       <TABLE> help, etc.
    4. A plea for consistency in titles. "KEYWORD: clever title" is
       a lot easier to find in a DIRECTORY than "clever title KEYWORD."
    
    
    ...and no, I wouldn't want to be the moderator.
    
    Joe

Any way to implement the suggestion in .14 so that just before a person 
types in SUBJECT: he/she gets a "add a keyword" reminder?  This might be 
a wishlist item for the NOTES developers; I don't know, so I ask, eh?

And some more suggestions for new keywords:

ROUTINE_TAGS    (because rsedeflist,qualdeflist, etc., are popular
                 topics...TAGS is just too generic)


The new keywords I am suggesting are not necessarily the best ones to 
use for a particular topic; I welcome (and I'm sure the moderator 
welcomes) suggestions for better, succinct words.  



Rose

    I would like a Keyword which would point to DESIGNS which have been
    done by everyone.
    
    Maybe also, a keyword for DESIGN_QUESTIONS.
    
    How about a tutorial topic, for things like DESIGNS.