ECTC Task Information and Design Discussions

This document includes information about the individual ECTC tasks that don't fit in other parts of the Artemis Data Book, including design ideas and discussions extracted from mailing list traffic. Links to useful resources elsewhere on the World Wide Web are also included.

Select one of the following links to go directly to a specific section:

Web pages and related files that are associated with the ECTC itself, and not one of the following categories, should be placed in section 9.1 of the Artemis Data Book in the /adb/09/01 directory of asi.org.

The Artemis Help Desk currently consists of Nanci Brasket, the Artemis Communications and Information Center. As the volume of questions and requests to Nanci grows over time, we will need to set up a more formalized help desk that can be staffed by multiple people, with an automated method of tracking questions and answers. The following messages from Steve Jackson and Greg Bennett provide more detail about what's needed in this area:

From: sj@io.com (Steve Jackson)
Date: Sun, 14 Jan 1996 00:36:41 -0500

Managing "help desk" stuff is non-trivial when you have lots of questions and more than one answerer. Just grabbing a question from the pool and sending a note to everyone else "I got this one" breaks down really fast at high volumes of questions (trust me, I've been there).

The only way to make sure huge numbers of questions really get answered is to have a process in which

Sounds like a pain, doesn't it? It is!!!

Some of this can be automated. In fact, there is a whole industry geared to writing help-desk management software. None of which IO has, DAMMIT!!! Maybe someday.

From: grb@asi.org (Gregory R. Bennett)
Date: Sun, 14 Jan 1996 12:52:26 -0500

This is another one for the ECTC's job jar. My guess is that it won't be a problem for many months at least, though. The last time I asked Nanci she said she was not having problems keeping up with mail to Artemis.

When the traffic going to general mailboxes like artemis@asi.org or webmaster@asi.org gets too heavy, we'll need the email equivalent of a rotary phone line -- an email router that routes each incoming message to a different person on a list in a rotary fashion. It would work the same as a phone tank ("boiler room") used for PBS beg-a-thons and large government installations.

The mail-router program should keep a log of the incoming mail, who it was routed to, and what action was taken. This would look like a transaction processor used to handle mail-order requests or 1-800 order lines for mail-order companies. It should also keep track of how long a message has been ripening in someone's IN box and send it to someone else if it gets too old; that will accommodate the cases where someone's electronic connectivity goes haywire, unplanned absence, or whatever.

The program should be able to deal with temporarily putting one of the official correspondents on 'inactive' status. That takes care of planned vacations, heavy workload periods, illness, burnout. It should accept a command from its list of correspondents to do this without other human intervention. These commands must be controlled by passwords to prevent mischief. Only the lead for a given activity would be able to add a name to the list of correspondents.

If this program were able to do all these things and be user-friendly, it would be marketable. I suspect such software already exists for handling email sent to the White House and to Bill Gates's "ask-bill" address, but I've never heard of someone marketing it.

From: grb@asi.org (Gregory R. Bennett)
Date: Sun, 14 Jan 1996 14:51:12 -0500

Yeah, what Steve said! Help desk email must always have an individual human's signature.

The program I described in my previous post would be an electronic implementation of that human supervisor at IO, assigning action to a pool of individuals and tracking responses.

Tracking responses is vital. One of the major problems Nanci has as the Comm & Info Center is lack of feedback; she often doesn't know if the person she forwarded mail to even received the mail.

Add some more features to the wish list:

Working the help desks is an art form, requiring some special personal communication skills. For an excellent description of that job, check out the help-wanted advertisement from IO in the io.admin newsgroup. (You'll also see why IO is so popular with its customers.)

Help Desk web pages and related files should be placed in section 9.2 of the Artemis Data Book in the /adb/09/02 directory of asi.org.

An excellent review of most of the listservers that are available can be found in the Mailing list management software FAQ.

CREN ListProc and LISTSERV, though they seem to be the most capable listservers available, were not considered since they are commercial products with fairly hefty price tags.

A review of the two most promising listservers, ListProc v6.0c and SmartList v3.10, measuring each of them in several key areas that are important to the Artemis mailing lists, can be found in the Mailing List Server Comparison web page.

One key task in the Listserver Mailing Lists area is to set up and maintain archives of all mailing list traffic that are accessible both from anonymous ftp and from e-mail requests. Some listserver packages have built-in archive access capabilities, two (ListProc and SmartList) even have an archive search capability built in. If we use a listserver that doesn't support e-mail archive access, or the existing access is limited, we will need to install an external archive service. An excellent summary of archive access software can be found in the Mail Archive Server Software List. One external archive package is FTPMAIL.

There are also several tools available that allow basic administration of mailing lists (adding and removing users, getting information about the lists) through web pages. Two such tools are MailServ and LWGate.

With the large numbers of people participating in the Artemis Project, and the variety of different discussions that will be going on in the different mailing lists, it will be helpful to have a set of guidelines for conducting the ongoing discussions. The following messages from Dale Amon and Greg Bennett provide some background information:

From: amon@walt.music.qub.ac.uk (Dale Amon)
Date: Sat, 14 Oct 95 15:39:12 GMT

I am as qualified as anyone to discuss the use of news, mail lists and web sites for problem solving -- I've been at it since the dawn of time (well, the dawn of cyberspace at least)

There are a number of problems (and advantages) with most forms of Internet communications when they are related to real problem solving.

How do we structure information systems so that real work can be accomplished? Let's start with idea generation and progress through to a definable product.

Virtual Pub / Dorm Lounge / Student Union snack Bar - This is the open maillist or news group. "This is Liberty Hall... spit on the mat and call the cat a bastard." People come and go, dip into discussion as they feel like it. Little real work gets done here, but new ideas are generated and old truths demolished.

Ideas start from bull sessions. The ideas might pop up spontaneously, or they might be tossed into the shark tank by a "moderator" from LRC. In the former case, the ASI is feeding ideas to LRC; in the latter, LRC has a problem for which it needs ideas or an answer.

But bull sessions do not a product make. Something further has to happen. My suggestion is that an LRC or ASI bull session monitor watch the open discussions, and when an interesting idea comes up, that idea be assigned virtual office space. At this point we stop being democratic and start working. One individual is assigned as the team leader. Others who are interested in developing the idea are given the option of being a part of the team. For better or worse the team leader is boss and may fire those who are disruptive, fail to complete assigned tasks, or continuously stray from goal-directed behavior.

In turn, the team leader is assigned a deadline and milestones by LRC. The deliverable is a technical report, possibly with a minority report attached. A team that fails to meet its deadlines can be disbanded by the management. Teams are disbanded and members reassigned when they complete their projects.

Virtual Office - A place where a group with an interest in a particular topic works in a structured environment with responsibilities and accountability enforced.

When a draft report has been completed, it is then thrown open to general debate in an open "peer group" forum. This could consist of making it available to the members of the bull session and to relevant news groups.

Virtual Conference Hall - A place where reports are presented and open debate held on their content. Off-topic debate is forbidden. Only matters relating to critique of the report are allowed.

A specific time limit is placed on the comment period. When that period is ended, the team filters through the comments and generates a final report. The final report is published as part of a body of high quality *reviewed* design and research on which LRC can base its plans.

Virtual Library - A place where final reports are available for search and reference.

Now how do we go about creating a structure like this? We certainly don't want to go out and write new tools. That would delay any such efforts by years. It is also probably unnecessary. Most of it can be accomplished within the framework of existing tools, given that LRC has a professional manager to create teams and monitor results. At some point this should be a full-time professional position. If I use LRC rather than ASI, it is because I see possibilities here for real work that needs real management.

Now the mechanisms:

Nothing is static. There must always be feedback and continued debate. With this procedure we end up with quality information. Then, when a newbie debate begins, or when wizards rehash an old truth with new facts, a starting point can be pointed out which is accessible to all. With some luck that will raise the overall level of debate even in "the Pub."

From: grb@asi.org (Greg Bennett)
Date: Mon, 8 Jan 1996 21:23:40 -0600

Jeffrey Weiss brought this subject up in a private email posted while he was looking at the web site, but I think it's an important question for the whole Artemis Project community to consider. Jeff cited the example of a political listserver where they use a variation on Robert's Rules of Order to guide the conversation.

I hadn't really thought about having rules for the on-line discussions, but I don't think it's necessary to establish rules for every forum in the Artemis Project. Still, we could benefit from having some guidelines posted with the list of lists on the web site as we launch these things.

Using a variation on Robert's Rules might be appropriate for a political discussion where there are twice as many opinions as participants and a lot of diametrically opposed opinions. In that kind of environment, it's often important to level the field and ensure that no single personality dominates the deliberation.

In the engineering world, when working together in person, we're more likely to select a leader for a team and then rely on that team to define rules that will work for them. Each leader's style is a little bit different, and the people who make up each time bring their individual talents and skills.

There's a difference between engineering and politics. Especially in the Artemis Project, we're looking for the most creative problem-solving solutions people can contribute. That's not just in technical areas, either. We need creative solutions to all sorts of business and political issues as well. Politics involves a lot of problem-solving, too, but often the greatest difficulty is getting people to agree on what the problem is.

In the Artemis Project we at least pretty much agree on what our goals are, and what the problems are that we have to solve. (It shouldn't be surprising that the most disagreement and puzzlement involves defining what the political problems are, and how to deal with them.) So in this environment we should be able to leave it up to each team to adopt whatever rules will help them solve the problems.

That brings me back to posting guidelines. Rather than trying to come up with those at the beginning, let's ask each participant who is interesting in developing techniques for using the electronic forum to share learning from the sundry groups. The appropriate forum for that would be the Electronic Communication Technical Committee; though I'm getting a feeling that the ECTC might want to subdivide the ectc@asi.org mailing list as the project grows.

Listserver web pages and related files should be placed in section 9.3 of the Artemis Data Book in the /adb/09/03 directory of asi.org.

Dana Carson is the Artemis Webmaster. Maintenance of the Artemis Web Site is done by the Web Maintenance Team, which handles the responsibility for World Wide Web Server task #4 in the ECTC Task List. Anyone who has something that they want to put on the Artemis web site should send text or HTML documents or graphics to the Web Maintenance Team, who will update the documents to match the style and format of the ASI web site and put it on the web server.

With a group of people maintaining the Artemis web site, it is important to maintain a common style among all of the web pages on the site. To do this successfully, we need a web style guide that will be used for all ASI web pages. The following messages from Greg Bennett, Dana Carson, and Simon Rowland provide some of the initial ideas for the web style guide:

From: grb@asi.org (Gregory R. Bennett)
Date: Sat, 23 Dec 1995 14:52:42 -0600

The procedure for server-side includes and the definition of the Artemis Project's style for using them should go into the Internet Site Design Document, in section 9.4 of the Artemis Data Book. We want to get into the habit of recommending changes to the Data Book, and answering questions with updates to the Data Book whenever we can. Notes should at least include a reference to the document section we're talking about.

Besides making our work more efficient -- we can answer questions just by giving someone a URL -- this will make it possible for us to access the information wherever we are. For instance, I did a dumb thing: most of the email notes I have recently written are in my machine at the office, and now I'm off for more than a week for the Christmas holidays and have access only to my machine at home. I neglected to send my electronic address book home, too. Silly me; but I know several other folks have the same problem.

The Data Book ought to have a page of reference links where folks can go to learn how to do html coding in general, as well as our own tutorials specifically telling how to do a document for the Artemis Project web site. Dana's note about the UIUC tutorial on server-side processing is an example.

Is John on the ectc list? When last we discussed that subject, he volunteered to download the Internet Site Design document and code it in html; so he'd be interested in this. I don't know where he is in reworking the outline, so for now I'll try to divide these comments by subject without attempting to figure out the section numbers they'd affect.

Now for some questions and comments about the WWW site design . . .

Server-side processing

I take it the "s" in ".shtml" is a flag to the server to process a file. If we include the Nav Bar in every page, then every file would have to be .shtml, right? Will that significantly slow down delivery of a document?

What to include and what to leave out

We want pages from the Artemis Data Book to be delivered fast, keeping overhead to a minimum. So as a rule we should avoid sending decorations and peripheral information. Document titles and text headers are sufficient for what we're doing; though I suppose a tiny .gif of the half-moon logo in a header would be acceptable. It would at least provide a bit of continuing inspiration.

Access counters do not add anything to the value of the information delivered; but of course access statistics are important to acquiring sponsors for parts of the data book. Don't we have a program that counts access to each resource without having to include a counter in the document delivered to the user? If so, we should leave the access counter off the standard pages we deliver.

Backgrounds are pretty, but really slow down delivery of a document. Let's avoid them and stick with setting the background to white.

Index-building technique

If server processing is significantly slower and more cpu-intensive than just sending an html document, would we be better off having an off-line program build a bunch of plain html index files? I'm thinking we could run a program whenever we know there are changes. That's a trade-off between fully automating the index-building vs. the overhead of rebuilding the index every time someone accesses a section of the Data Book. I don't know exactly how all this works, so I don't know what to recommend. This is one for the experts.

Footers

We might want to have two versions of the Nav Bar -- one to use in general documents and one to use specifically for files in the Artemis Data Book. Code that generates links to previous section indexes and such won't make sense outside the Artemis Data Book structure. Of course, the Nav Bar might be in a file by itself, called from yet another file like "adb-footer.shtml" which automatically includes it. Can we do recursive includes? Would that slow down processing even more?

I sent a note with a design scheme for this a few days ago. Here's a small update to that thinking. Besides the index-builder, this is where server-side processing really comes into its own. The footer should look something like this . . .

 This page maintained by [name] [<address>]

[Index for this section: (x.y.z.a title)]

[Previous section: (x.y.z title)]

=====================================================================

+-----------+-----------+-----------+---------+-----------+---------+

| Artemis | Artemis | Artemis | FAQ | Reference | Catalog |

| Project | Society | Data Book | | Mission | |

+-----------+-----------+-----------+---------+-----------+---------+

=====================================================================

Artemis Data Book Section Boss: [name] [<address>]

Last update: (mod date)

Copyright and trademark notices

. . . with everything below the Nav Bar in small type. Note that I put the author's name above the footer, because the author (or maintainer) would be hard-coded into each document. The rest of the footer comes from external information with an include.

The link to the local index is just a link to whatever index.html (or index.shtml) resides in the current directory. The previous section reference is parsed from the directory tree. For example, if the document is in section 4.3.2.1, it would be in directory /adb/04/03/02/01. The previous section would be /adb/04/03/02, which of course parses to 4.3.2.

The title for each section is read from a file, "title.txt", which resides in each directory. So the title for section 4.3.2 will be found in file "/adb/04/03/02/title.txt".

Similarly, the name and email address of the section boss are found in file "section-boss.txt".

Of course, the mod date comes from that parser Dana wrote for "test.shtml", and the copyright and trademark notices are standardized.

Fun with search engines

I've noticed people are beginning to include a <!--Keywords...> declaration in their html code. We should do that, so that search engines will find our site if someone is searching for cool space stuff. How about including some general key words in every document:

 <!-- Keywords: manned space moon private space ventures future

luna lunar space travel spacecraft moon mining

lunar resources artemis project artemis society

international adventure tourism arcology ecology

science technology space business entertainment

movies television publications merchandise

ephemeris commercial lunar base moon base moonbase >

The repetition of common key words will cause a search engine to give our pages higher priority on the list of search results.

Of course, if we _really_ want to attract people to the site, we need to get someone to work up essays on zero-g and low-gravity sex, and put in some crass commercialism by building the calendar of the "Girls of Mare Nubium" or whatever. As long as there's something entertaining, folks searching for key words like "sex" or "bikini" will forgive us for attracting them to our site. And what the heck -- they're searching for adventure, so we just might provide them some interesting adventure, if not the sort of entertainment they had in mind.

As best I can tell, search engines like Lycos find web pages by following links, so the more inter-linked our site is, the more likely that someone will find us. Lycos even has my personal bio page linked now.

Status of the Artemis Data Book Directory Structure

Except for section 7.0 "Artemis Society Local Chapters and Contacts" and the appendices, I've completed building the directory structure for the whole Artemis Data Book. I got that done last night.

Each directory has a little 1K file in it giving the section number and abbreviated section title as its file name. These little files are just navigation aids for accessing the site with ftp or telnet; they show up in the filename listing so you'll know where you are. The content of those little files is just a chunk of html that explains why it's there and links back to the main index for the Artemis Data Book.

Date: Sun, 24 Dec 1995 03:38:47 -0500
From: dcarson@access.digex.net (Dana Carson)

[We should have a] short writeup of our style and pointers to sites with tutorials on HTML, and CGI.

I'd like someone who has the time to look into htgrep a program that searches web trees and returns finds on a paragraph basis. Clever.net has it but the doc is very brief. That would be useful to aim at the adb tree.

To see a huge index look at DEC's new http://www.altavista.com they have 8 billion words on 16 million pages indexed. Plus news groups.

From: grb@asi.org (Gregory R. Bennett)
Date: Wed, 17 Jan 1996 15:33:08 -0600

The idea I was discussing with Dana about a month ago was to have every directory in the Artemis Data Book contain things like:

The libraries would especially benefit from having a script that allows someone to submit new articles. It would automate assigning image or document numbers and automatically update the index files.

Most of the information in those little text files would also be used by the data book index-generator script to build index files for each directory in the tree.

From: grb@asi.org (Gregory R. Bennett)
Date: Thu, 18 Jan 1996 12:59:49 -0600

Nav Bar . . .

The "Nav Bar" is that little table at the end of each page with standard pointers to the Artemis Project, Artemis Society, etc. A couple months ago I started replacing The Lunar Resources Company link with a link to the Artemis Data Book index. There are a couple reasons for doing this.

The practical reason is to make it easy for folks to find the Data Book index, which is a window to all the details of the project.

The political reason is to let The Lunar Resources Company's presence fade into the background; that makes it easier to maintain ASI's independence and non-profit status, and lets LRC concentrate on building a business while ASI builds the organization. It does not mean LRC is taking a less active role in the Artemis Project. Quite the opposite, in fact: by separating the volunteer side of the project from the commercial side of it, we can move forward in both arenas with fewer inhibitions to progress.

Web site design thought: automated processing, the sequel . . .

If you like this one, it ought to be incorporated into the site design document and tutorials for building and maintaining the site.

Dana and Randall, when we set up that gizmo that reads little text files, we should have a field for the author of each page, and a separate one for the maintainer, with appropriate pointers to grab each individual's email address from the /bios directory. The idea of getting the email from the /bios directory is that then we only have to update it once when someone's address changes.

Here's an idea: perhaps instead of having a cgi script that runs every time someone accesses a URL, it would be better to have a script that builds the html file and updates the indexes when things change:

The idea here is to reduce server-side processing time. There's no need to assemble a page each time it's delivered, if that page will only change once a year. At the cost of a few KB to store duplicate copies of the Nav Bar all over the site, we can eliminate the need for processing every page with a script.

The tricky part will be to make the pages maintainable. We might want to split it out so that each html document has three parts: header, footer, and body. The body is the part maintained by humans, while the header and footer are maintained the machine.

We could have separate text files named "foobar.body", which get incorporated into "foobar.html" files. The indexer would only list the "foobar.html" files it finds in a given directory.

 +--------------------------------------------------------+

| Header | added

| Tags: html, doctype, keyword comments, head, body | by

| Output: page title, doc section number, doc name | machine

| author, standard decorations |

+--------------------------------------------------------+

+--------------------------------------------------------+

| Body |

| Tags: author, maintainer, title, doc name, etc. | maintained

| Output: body of document, in-lined images, internal | by

| navigation links | human

| |

| Note: Info tags don't need to be .html file, only in |

| .body file |

+--------------------------------------------------------+

+--------------------------------------------------------+

| Footer |

| Tags: /body, /html | added

| Output: navbar, author link, maintainer link, mod date | by

| copyright declaration, link to local index | machine

| |

+--------------------------------------------------------+

To make this work, we need to establish a standard format for telling the indexer the name of each document. That could be a separate file listing all the foobar.body files and the document name for each, or it could be a standard-format comment field contained in each foobar.body file. I think it would be easiest to maintain the documents if we established a standard form for putting comments in the foobar.body documents.

The standard format for tags in a .body document might be:

 <!-- asidocname="Subject of this essay" -->

<!-- asidocsection="4.6.5.3.1" -->

<!-- asiauthor="H. W. Wrotethis -->

<!-- asimaintainer="I. M. Aitchtiemell" -->

<!-- asicopyright="Mark Territory, Inc." -->

<!-- asiorigdate="mm-dd-yyyy" -->

I added "asi" to the tag names because future versions of html might add some keywords, but it's unlikely they'll use "asi" in any of them. These comments need to be in the foobar.body files, but do not need to be the foobar.html file that the indexing engine assembles.

Including the ADB section number allows us to do some interesting things:

I really like this idea because it means the guys maintaining the documents only need to worry about making the actual document content work. If we decide to change the style of headers and footers, they'll change consistently throughout the whole web site.

It also makes it easy for someone to submit a new document -- just anonymous ftp it to a holding tank, and then the ECTC webbers take over. That gives us the same control as the sysops do on GEnie. If the webmaster's apprentice isn't sure, he'll know the section boss for that part of the Data Book, and can easily ask if the document should be added (or updated) by emailing a URL pointing to the file in the holding tank.

From: simon@eagle.ca (Simon Rowland)
Date: Thu, 1 Feb 1996 20:13:13 -0500 (EST)

This is stuff to be copied and pasted into all .html files to keep a standard look. Except ADB versions, which go without the cool half-moon gif. And they have the titles centered, showing their location:

<h2 align="center">Artemis Data Book</h2>

<h2 align="center">4.1.1 Reference Mission Timeline</h2>

<h2 align="center">Timeline for Mission I</h2>

or some such.

Here's the standard Header. It may change. If anyone wants to propose a change to this, go right ahead!

<!-- DOCTYPE HTML PUBLIC \"-//W30//DTD W3 HTML 2.0//EN\" -->

<!-- V 1.0 Whatever It's Called -->

<HTML>

<HEAD>

<TITLE>Artemis Local Chapters

</TITLE>

</HEAD>

<BODY BGCOLOR="#FFFFFF" VLINK="#B20003">

<IMG SRC="/Gifs/artlogona.gif" align="top"><font size=-2>TM</font><BR>

<BODY>

<H1> THE TITLE </H1>

- or....

<H2> A Very Long Title </H2>

This is the footer. It probably won't change anytime soon. Note the 3rd item is "Artemis Data Book" this is replacing TLRC to downplay the commercial involvement, and has been going on new pages since December. Don't forget to tweak the date when you paste this into a page!

<hr size = 5>

<table align=center border=4 cellpadding = 3 cellspacing=2>

<tr>

<td align=center>

<b><a href="http://www.asi.org/"</a>Artemis Project</b>

<td align=center><b><a href="http://www.asi.org/asi_index.html"</a>

Artemis Society</b>

<td align=center><b><a href="http://www.asi.org/adb/"</a>

Artemis Data Book</b>

<td align=center><b><a href="http://www.tlrc.com/Artemis_FAQ_toc.html"</a>

FAQ</b>

<td align=center><b><a href="http://www.tlrc.com/Reference_mission.html"</a>

Reference Mission</b>

<td align=center><b><a href="http://www.tlrc.com/catalog.html"</a>

Catalog</b>

</tr>

</table>

<P>

<font size=-2>Copyright © 1996

Artemis Society International. Updated Thu,February 1, 1996<br>

- not used under normal circumstances, only if there is specialized - content, and the maintainer is whoever wrote the content

This page is maintained by <a href="http://Your Bio/">Your

Name</A>

<a href="mailto:yourname@domain.com"><yourname@domain.com></a>

"<A HREF="Artemis.html">The Artemis Project</A>" is a trademark of

<A HREF="http://www.tlrc.com/Lrc.html">The Lunar Resources Company</A>.

</font>

<hr size = 5>

</BODY>

</HTML>

Web pages and related files about the ASI Web Server should be placed in section 9.4.1 of the Artemis Data Book in the /adb/09/04/01 directory of asi.org.

One of the more popular web conversation packages is HyperNews, with its companion program, HyperMail. HyperNews apparently does not yet support bi-directional gateways to mailing lists, but such a feature is supposedly under development.

In addition to the web conversation environment, we also will need to implement a web interface to the mailing list archives, using some kind of search engine. We also need to implement a search engine for the entire web site, which may or may not be the same as the archive search capability. Two potential web search engines are Glimpse and Htgrep. Three other tools that allow access to mailing list archives from web pages are MHonArc, LWGate and ListWebber.

Web pages and related files about the WWW Conversation Pages should be placed in section 9.4.1 of the Artemis Data Book in the /adb/09/04/01 directory of asi.org.

Dale Amon is currently working on setting up a hierarchy of newsgroups for the Artemis project, most likely a top-level artemis.* hierarchy. Once the newsgroups have been established, however, they will be difficult to use without an automated gateway to the mailing lists, since any discussions would be separated between the two communication environments. Consequently, establishing an automated newsgroup to mailing list gateway environment is one of the top priorities of the ECTC.

There are several potential methods of establishing a newsgroup to mailing list gateway. The first, and easiest, is to use a listserver, such as ListProc 6.0c, that has a built-in gateway to newsgroup feature. If we are using a different listserver, however, we will need to implement an external gateway service. One such service is the software that is used to gateway the sci.space hierarchy to the Space Digest mailing list. This software is available from ftp://vacation.venari.cs.cmu.edu/usr0/anon/dig.tar.Z. Another package is called Newsgate. It is only available on request, but we have made the request and have obtained a copy of the software.

Newsgroup web pages and related files should be placed in section 9.5 of the Artemis Data Book in the /adb/09/05 directory of asi.org.

The overall plan for this area of the ECTC task list is to establish an Artemis "presence" on all of the major online services. The exact nature of that presence will vary from service to service, but hopefully will contain at least a link to the Artemis web site and a copy of the FAQ and FRO files. The ideal form of presence is a dedicated "forum" that is automatically gatewayed to the Artemis mailing lists, similar to what is currently being implemented on GEnie.

The GEnie gateway software was developed by Randall Severy and uses TTY dial-up connections to GEnie twice a day to upload all mailing list traffic to GEnie and download most forum traffic from GEnie. The GEnie gateway software consists of three Unix 'C' programs. The first program downloads any new messages from GEnie and sends them out as a mail message to the appropriate mailing list. A second program captures incoming messages from the mailing lists and saves them in special directories. The third program takes all of the files from those special directories and uploads them to GEnie in the appropriate topics. Some basic filter routines are built in to check to make sure messages from GEnie don't get re-uploaded to GEnie and messages from the mailing lists don't get sent back to the mailing lists. These filters handle basic mail loop problems, but do not check for user-generated errors. If someone sends multiple copies of a message, as has happened from time to time, they are all uploaded to GEnie, unless Randall sees them and deletes them manually before the upload program runs.

That gateway software could be readily converted to support other online services, but only if the exact nature of the protocol used for uploading and downloading online forum traffic is defined and documented.

In the short term, we need to set up information on the ASI web site that identifies where on each online service to find information about the Artemis Project and who to contact on each online service for more information. This information should be available from individual web pages, one for each service, modeled after the GEnie page written by Nanci Brasket. The GEnie page describes where to find Artemis information on GEnie, how it is organized, and how to sign up for access to GEnie.

One key issue in establishing automated gateways between on-line services and Artemis mailing lists is that many on-line services have what is known as a "compilation copyright" on all material that is posted on their service. The following message from Greg Bennett describes the issue in more detail:

From: grb@io.com (Gregory R. Bennett)
Date: Fri, 2 Feb 1996 17:38:24 -0500

In those topics where GEnie allows us to pipeline Artemis Project messages into and out of the service, they're essentially waiving the compilation copyright. If AOL or MSN, or anybody, would like to join GEnie in participating in the project, they would also have to waive compilation copyrights to any information moving through the pipeline.

There's more to this than me being a curmudgeon. The Project won't work if we can't freely archive and use the information generated by its participants.

So, when contacting commercial services about this, make sure to include in your description of the proposed service that they cannot claim compilation copyright to any Artemis Project material.

Web pages and related files about online services in general should be placed in section 9.6 of the Artemis Data Book in the /adb/09/06 directory of asi.org. Web pages and related files about individual online services should be placed in the appropriate 9.6 sub-section of the Artemis Data Book. The following subsections are currently defined:

David Brummel is currently writing a description of his existing mailing list to FidoNet gateway software, which will be posted on the ASI web site when completed.

BBS web pages and related files should be placed in section 9.7 of the Artemis Data Book in the /adb/09/07 directory of asi.org.

Several real-time meetings of the LRC board of directors have taken place using the GEnie RTC (Real-Time Chat) "meeting rooms". This ability to hold real-time meetings from remote locations will be extremely useful for many of the Artemis technical committees, but since most meeting attendees will not have GEnie access, a more common form of real-time communication is needed. One suggestion that has been raised several times is the use of a "MOO" or "Mud" (multi-user domain) for real-time meetings, but Muds and MOOs are high-maintenance projects that consume a lot of computing resources. A more easily implemented solution is to either use the existing IRC (Internet Relay Chat) services or to set up a chat server on asi.org. An excellent resource for information about IRC and chat servers is Yahoo's Internet Chatting pages. The following messages from Simon Rowland, Randall Severy, Greg Bennett, Steve Jackson, and MB contain excerpts from some of the discussions that have been going on about real-time meetings:

From: simon@eagle.ca (Simon Rowland)
Date: Thu, 23 Nov 1995 16:52:03 -0500

I'd been thinking about the problem of communications between members of tech committees who happen to be spread around the globe. So, I suggest we install some Multi User Dungeon (or at least chat) software on the lunacity server. But leave out the monsters that have a tendency to kill you.

That way, there can be real-time meetings that can be _specific_ without boring the rest of Artemis about the turbopump cabling layout. Logs can still be kept and archived, and each committee can have a separate meeting zone -- type "enter the LTV" and you're in the alternate LTV missions room.

Also, a link from the WWW site could lead to the "Houston lobby," where there is always a member explaining the project to curious space people, *interactively*. Obviously, it would have to be manned in shifts, but it would be fun to do. And Vik can do it while we Canadians are sleeping. :-)

Some boring ideas of mine: have objects like paper/computers/billboards containing Artemis propaganda, which can be read by exploring newbies. Also, monsters (aliens?) who instead of killing you explain the mission scenario when provoked (worse then death :). Boardrooms could be "rented" by some committee or group when it's not worth the trouble of programming in a new area. And the Lunacity, where people engage in meandering discussions about how great it'd be to live on the moon....

From: severy@is.ge.com (Randall Severy)
Date: Tue, 12 Dec 1995 22:29:28 EST

At work I've run a MOO based on Xerox's LambaMOO core for several years now as a virtual meeting place for field offices scattered around the world that we work with on a regular basis. Based on my experiences using such an environment for business-related activity (we cleaned up most "game"-related references in the MOO, i.e. changed "players" to "users", etc.), such an environment would be very useful for real-time meetings and conferences for the Artemis technical committees and the Artemis Society as a whole. One of the problems we ran into in our MOO was dealing with time zone differences (it was a real pain setting up U.S. and Australia conferences simultaneously, for instance), but in our case the Artemis society is not (yet) as widely spread out as the field organization at work is.

From: grb@io.com (Gregory R. Bennett)
Date: Wed, 13 Dec 1995 22:56:10 -0600

FWIW, we've had good success with on-line meetings of the LRC board of directors, using the RTC area on GEnie. That was with about a dozen people on line. The difference between our experience and Steve's, besides using different software (I've never seen Metaverse), is the type of meeting. We had an agenda mailed out ahead of time, and about 90% of the business was things we could prepare for by having largish text files ready to dump.

Another difference might be that everybody on line was either a writer or a computer wizard; hence, fast typists.

From: sj@io.com (Steve Jackson)
Date: Wed, 13 Dec 1995 23:42:10 -0600 (CST)

The Metaverse runs on MOO, which enables a lot more than chat. However, much of what it enables is distracting...

Note that if all the attendees happen to be on multitasking machines, and if they all have access to web pages, then all text files can be placed on the web before the meeting, and everyone can "chat" in one window while looking at the appropriate files in another. (I actually work across two Mac screens, but lots of people have single screens plenty big enough for this to work.)

Getting everybody to stop backspacing to fix the little typos when the meaning is clear :-) will be a big help.

So yes, I agree, done your way a meeting would be more likely to run efficiently.

From: severy@is.ge.com (Randall Severy)
Date: Thu, 14 Dec 1995 8:26:26 EST

I would definitely agree with all of your comments. From my experience with holding meetings in our MOO (as well as the occasional RTC on GEnie), it helps a huge amount if an agenda is passed out in advance, and it goes a lot more smoothly if everyone is a fast typist. To Steve's earlier comment, I also found that I would work on something else while waiting for replies in the conversation, especially when slow typists were involved. The idea of using web pages as a "shared handout" is a great one, I looked into doing that for our MOO meetings but since most of the remote sites were accessing the MOO through a dial-up TTY link they didn't have access to our web server. If we do starting using such environments for Artemis meetings, we will definitely want to plan on enhancements such as using web documents as part of the meetings.

From: MB@msn.com (MB)
Date: Thu, 4 Jan 96 04:31:24 UT

Okay, I would think IRC would be the best way to go (easiest for everybody to pick up)...MOO and MUSEs are more gaming things, however, it is possible...If we did want to do a MOO, MARE, MUD or MUSE, I think MUSE would be the best way to go...MUSE is probably the most advanced, and we could have some really fun things on it...However, I don't really know how to code in MUSE (I started to learn how to code on a MUSE. Apparently it's a lot like "C" (I used to play on one, but it started taking up too much of my time and people were taking it TOO seriously, so I quit). The other thing with a MUSE is that you have to have a "character" (I'm not saying we have to role play, but you still have to set up some sort of "person"), and it can take a while for everybody to catch onto a MUSE (while IRC is pretty easy)...So I still think IRC would be the best thing to set up...

Also, once we get on MSN, we can have a chat forum on there too...(Unfortunately, only MSN members can get onto it..)

For more info on MUSEs, MAREs, MUDs and MOOs, go to:

gopher://cyberion.bbn.com/1

From: severy@is.ge.com (Randall Severy)
Date: Thu, 4 Jan 1996 11:44:13 -0500

I've run a MOO for several years now at work that we have used from time to time for online meetings between work groups that are scattered around the world. There are various things you need to do differently in that sort of environment, but it has worked reasonably well. Most of the MOOs and MUSEs are set up as gaming environments, but that is not necessarily a fundamental part of them. We use Xerox's LambdaMOO software, which was developed initially to provide the foundation for their "AstroVR" astronomer collaboration and meeting system, so if you don't add all of the gaming stuff onto it, there isn't much problem using it for business-type stuff. The only thing we did was change all references to "player" to "user" in the database to eliminate any vestige of the gaming connotations.

Given all that, however, I agree that IRC is simpler to use for chat-style meetings. I've been having a lot of trouble recently, however, trying to find a decent way to get to IRC through a simple telnet connection (because I'm sitting behind a firewall at work, I can't use the normal IRC clients). Most of the IRC telnet servers I've found have gone commercial and now charge for access. That's why one of the first things somebody will need to do is write up some simple instructions for getting to IRC from our various environments to be able to attend Artemis meetings.

We definitely want to be able to hold chats on MSN, but unless a lot of the Artemis crowd signs up for MSN they may not happen too often...

From: Steve Jackson 
Date: Thu, 4 Jan 1996 19:31:09 -0500

I agree with Randall. IRC is the lowest common denominator, but easy to use. There are a lot of neat things that can be done with MOO/MUSH/MUD, but they all place a somewhat greater demand on users and a MUCH greater demand on someone who is going to have to keep the cranky system running. Unless we have a volunteer who is truly competent at M* wizardry AND really wants to do it AND is no good for anything else :-) I think we should stick with IRC.

If that's the case, we need someone already conversant with IRC to grab a brief set of instructions off the net, translate them to English, and keep them available to participants.

Real-time meeting web pages and related files should be placed in section 9.8 of the Artemis Data Book in the /adb/09/08 directory of asi.org.

Electronic Communication FAQ

The following messages from Greg Bennett and Randall Severy describe what is needed in the EC FAQ:

From: grb@asi.org (Gregory R. Bennett)
Date: Sun, 31 Dec 1995 11:10:52 -0500

Add: Develop and maintain an "Electronic Communications FAQ" document

The idea here is to have a nice faq in section 9.0 of the Artemis Data Book. Folks asking questions could be referred to the appropriate URL and save us lots of time answering questions.

A bunch of email autobot files might parallel that FAQ (and lots of other FAQ documents). It would be nice if they could grab text from the same files so information would only have to be updated in one place.

From: severy@is.ge.com (Randall Severy)
Date: Wed, 17 Jan 1996 9:23:50 EST

[In the EC FAQ,] I would certainly include something on joining the artemis-list mailing list, switching to digest mode, that kind of thing. Also pointers to where to find the Artemis Project on the various online services would also be helpful. Various references to the new ECTC web pages I'm currently setting up will probably be useful as well, especially the task list for when people ask what they can do to help. I guess at this point, it would be safer to include details on only those areas we currently support, which is basically the mailing lists, Web site, and GEnie. You may want to include some references to planned future additions, including Usenet newsgroups, other online services, FTP server and archives, and real-time electronic meetings. And definitely include a reference to sending general questions to Nanci.

The following message from Dana Carson describes what is needed:

From: dcarson@access.digex.net (Dana Carson)
Date: Wed, 17 Jan 1996 03:07:00 -0500

What's going on in ASI -

I'd like to get a volunteer to add something more or less weekly to something like this. Take a look at http://www.io.com/revealed/ to see something like what I'd like to see. They update almost daily but they have a full-time staff.

Web pages and related files about general Electronic Communications issues should be placed in section 9 of the Artemis Data Book in the /adb/09 directory of asi.org. All other web pages and related files should be placed in the appropriate subsection of the Artemis Data Book from the list above.