From igc.org!commem!carl Tue May  5 11:45:29 1992
X-VM-VHeader: ("Date:" "From:" "Sender:" "To:" "Apparently-To:" "Cc:" "Subject:" "Discarded-Parts:" "Reply-To:") nil
X-VM-Bookmark: 27
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Tue" "5" "May" "1992" "11:44:09" "-0700" "commem!carl@igc.org" "commem!carl@igc.org" "<9205051844.AA25093@cdp.igc.org>" "10" "DIAC '92 follow-up" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Tue, 5 May 1992 11:45:22 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11694>; Tue, 5 May 1992 11:45:06 PDT
Received: from cdp.igc.org ([192.82.108.1]) by alpha.xerox.com with SMTP id <11694>; Tue, 5 May 1992 11:43:05 PDT
Received: by cdp.igc.org (4.1/Revision: 1.65 )
	id AA25093; Tue, 5 May 92 11:44:09 PDT
X-NS-Transport-ID: 08002008D0FD001C47F2
Message-ID: <9205051844.AA25093@cdp.igc.org>
Date:	Tue, 5 May 1992 11:44:09 -0700
From:	commem!carl@igc.org
To:	asb@media-lab.media.mit.edu, blau@eff.org,
	chris@cruzio.santa-cruz.ca.us, civille@washofc.cpsr.org,
	cwhitcom@bentley.bitnet, douglas@atc.boeing.com,
	jjohnson@hplabs.hpl.hp.com, jpallen@ics.uci.edu, microx@well.sf.ca.us,
	pavel.parc@xerox.com, phoenixl@well.sf.ca.us, phyland@gwuvm.gwu.edu,
	pic@igc.org, presnick@mit.edu, ptw08@linknet.com,
	robinson@delni.dec.com, rodney@oxy.edu, rweiss@netcom.com,
	vance@mtxinu.com, vpcscll@sfsuvax1.sfsu.edu
Subject: DIAC '92 follow-up

Thank you all for your participation in the workshop on community access
to telecommunications.  I was overwhelmed by the level of interest in the
subject, and would very much like to keep the dialogue going.  I hope to 
set up a reflector for distributing mail on the subject automatically.
If anyone would like suggest a well-connected machine to host this function,
let me know.  In any event, expect to hear from me next week with an
address for submissions and some thoughts on future directions.
- Carl Farrington
cfarrington@igc.org


From igc.org!commem!carl Wed May  6 22:40:37 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Wed" "6" "May" "1992" "22:40:40" "-0700" "commem!carl@igc.org" "commem!carl@igc.org" "<9205070540.AA15753@cdp.igc.org>" "27" "mailing list" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 6 May 1992 22:40:21 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12102>; Wed, 6 May 1992 22:39:58 PDT
Received: from cdp.igc.org ([192.82.108.1]) by alpha.xerox.com with SMTP id <12102>; Wed, 6 May 1992 22:39:34 PDT
Received: by cdp.igc.org (4.1/Revision: 1.65 )
	id AA15753; Wed, 6 May 92 22:40:40 PDT
X-NS-Transport-ID: 08002008D0FD001C6386
Message-ID: <9205070540.AA15753@cdp.igc.org>
Date:	Wed, 6 May 1992 22:40:40 -0700
From:	commem!carl@igc.org
To:	pavel.parc@xerox.com
Subject: mailing list

That would be great if you could maintain the list there.  My machine
is only on the net via twice-a-day dial-up, so turn around would be
slower than most people are used to if I handled it.  The list is
currently:

Amy Bruckman	asb@media-lab.media.mit.edu
Andrew Blau	blau@eff.org
Carl Farrington	cfarrington@igc.org
Chris Neklason	chris@cruzio.santa-cruz.ca.us
Coralee Whitcomb	cwhitcom@bentley.bitnet
Doug Schuler	douglas@atc.boeing.com
Jeff Johnson	jjohnson@hplabs.hp.com
Jonathan Allen	jpallen@ics.uci.edu
Mary Eisenhart	microx@well.sf.ca.us
Paul Hyland	phyland@gwuvm.gwu.edu
Paul Resnick	presnick@mit.edu
Pavel Curtis	pavel@xerox.com
Peter Miller	ptw08@linknet.com
Richard Civille	civille@washofc.cpsr.org
Richard Weiss	rweiss@netcom.com
Rodney Hoffman	rodney@oxy.edu
Scott Luebking	phoenixl@well.sf.ca.us
Vance Vaughan	vance@mtxinu.com

with a few more to follow shortly, I hope.  Let me know what else you need.
- Carl


From pavel Fri May  8 14:04:10 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "8" "May" "1992" "14:03:19" "-0700" "Pavel Curtis" "Pavel" nil "15" "Re: mailing list" "^Date:" nil nil "5"])
Received: from lambda.parc.xerox.com ([13.2.116.36]) by lane.parc.xerox.com with SMTP id <29577>; Fri, 8 May 1992 14:03:58 -0700
Received: by lambda.parc.xerox.com id <58378>; Fri, 8 May 1992 14:03:25 -0700
Fake-Sender: pavel@parc.xerox.com
In-Reply-To: <9205070540.AA15753@cdp.igc.org>
References: <9205070540.AA15753@cdp.igc.org>
Message-Id: <92May8.140325pdt.58378@lambda.parc.xerox.com>
Date:	Fri, 8 May 1992 14:03:19 -0700
From:	Pavel Curtis <Pavel>
Sender: Pavel Curtis <pavel>
To:	commem!carl@igc.org
CC:	Pavel
Subject: Re: mailing list

The mailing list has been set up here.  Messages that are to be sent to
everyone on the list should go to
	
		community-access@parc.xerox.com

Requests to the added to or deleted from the list should be sent to

		community-access-request@parc.xerox.com

I will maintain an archive, available for anonymous FTP, of all messages sent
to the mailing list.  I'll send out details once there's something to archive.

Feel free to send out the initial welcoming message!

	Pavel

From igc.org!commem!carl Mon May 11 08:39:16 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "11" "May" "1992" "08:38:20" "-0700" "commem!carl@igc.org" "commem!carl@igc.org" nil "49" "Community Access mailing list" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 11 May 1992 08:39:07 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11573>; Mon, 11 May 1992 08:38:36 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11571>; Mon, 11 May 1992 08:37:42 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Mon, 11 May 1992 08:37:25 -0700
Received: from cdp.igc.org ([192.82.108.1]) by alpha.xerox.com with SMTP id <11565>; Mon, 11 May 1992 08:37:09 PDT
Received: by cdp.igc.org (4.1/Revision: 1.65 )
	id AA11388; Mon, 11 May 92 08:38:20 PDT
X-NS-Transport-ID: 08002008D0FD001C923C
Message-ID: <9205111538.AA11388@cdp.igc.org>
Date:	Mon, 11 May 1992 08:38:20 -0700
From:	commem!carl@igc.org
To:	community-access@parc.xerox.com
Subject: Community Access mailing list

Thanks to Pavel Curtis, we now have a community access mailing list available.
You can post items to the list by mailing them to 

	community-access@parc.xerox.com

or submit requests to add or delete names to

	community-access-request@parc.xerox.com

All items posted to the list will be archived and available via anonymous FTP.
Details for accessing these archives will follow once there's something in
them.

I have a fairly open-ended concept of what this mailing list is supposed to
be used for.  A lot of interesting issues surfaced during the workshop, and
this seems a logical place to pursue them.  I also want to encourage an
ongoing dialog between practitioners of community access telecommunications
and others concerned about these issues.  At this stage I'd like to be as
inclusive as possible, both with regards to participants and subject matter.

I have some comments on the workshop which I will try to get out this week.
I encourage everyone else to share their reactions as well.

Initial participants on the list are:

	Aaron Delwiche		pic@igc.org
	Amy Bruckman		asb@media-lab.media.mit.edu
	Andrew Blau		blau@eff.org
	Chris Neklason		chris@cruzio.santa-cruz.ca.us
	Coralee Whitcomb	cwhitcom@bentley.bitnet
	Doug Schuler		douglas@atc.boeing.com
	Jeff Johnson		jjohnson@hplabs.hp.com
	Jonathan Allen		jpallen@ics.uci.edu
	Mary Eisenhart		microx@well.sf.ca.us
	Paul Hyland		phyland@gwuvm.gwu.edu
	Paul Resnick		presnick@mit.edu
	Pavel Curtis		pavel@xerox.com
	Peter Miller		ptw08@linknet.com
	Richard Civille		civille@washofc.cpsr.org
	Richard Weiss		rweiss@netcom.com
	Rodney Hoffman		rodney@oxy.edu
	Scott Luebking		phoenixl@well.sf.ca.us
	Vance Vaughan		vance@mtxinu.com

One of the addresses on the signup sheet doesn't seem to work:
	Andrew Robinson		robinson@delni.dec.com
so I would welcome a corrected address from anyone.  I hope to have several
other people joining the list shortly.


From atc.boeing.com!douglas Mon May 11 11:41:09 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "11" "May" "1992" "11:34:31" "-0700" "douglas@atc.boeing.com" "douglas@atc.boeing.com" nil "89" "DRAFT set of principles" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 11 May 1992 11:41:08 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11627>; Mon, 11 May 1992 11:40:43 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11631>; Mon, 11 May 1992 11:40:07 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Mon, 11 May 1992 11:39:42 -0700
Received: from atc.boeing.com ([130.42.28.80]) by alpha.xerox.com with SMTP id <11626>; Mon, 11 May 1992 11:39:29 PDT
Received: by atc.boeing.com (5.57) 
	id AA28527; Mon, 11 May 92 11:31:43 PDT
Received: by cleelum.boeing.com (4.1/SMI-3.0DEV3)
	id AA04372; Mon, 11 May 92 11:34:31 PDT
X-NS-Transport-ID: 08002008D0FD001C960C
Message-ID: <9205111834.AA04372@cleelum.boeing.com>
Date:	Mon, 11 May 1992 11:34:31 -0700
From:	douglas@atc.boeing.com
To:	community-access@parc.xerox.com
Subject: DRAFT set of principles

Hello to everybody.   We're beginning to frame a project in Seattle,
initially via the CPSR chapter here.  We're going to be involving
representatives of the community very soon.  I wanted to distribute
a DRAFT of our Principles for your review and comment.  We are hoping
that these principles will help guide the project over the years.
I'd like to hear any feedback from you on this.  Thanks!

-- Doug




                 Principles of the Seattle Community Network

                CPSR/Seattle Community Networks Working Group

                               %%% DRAFT %%%

The Seattle Community Network (SCN) nominally is a public computer network.
Beyond that, however, it is a service conceived for the public good with
stated, principled intentions.  These principles, stated below, are a series
of commitments, that will guide the ongoing development and management of the
system for both the organizing committee and cooperating individuals and
organizations.

Commitment to Access -

  Access to the SCN will be free to all.

  We will strive to provide access to all groups of people, regardless of
  gender, age, national or ethnic background, socio-economic status, sexual
  preference, educational attainment, religious affiliation, or political
  beliefs.

  We will strive to provide access to people with special needs.  This
  includes both special-purpose interfaces as well as support for non-
  English speakers.

  We will strive to make the SCN accessible from public places.

Commitment to Service -

  The SCN will offer reliable service.  Response time will be within
  acceptable limits.

  We will strive to provide information that is timely and important to our
  users.

  We will provide the support for electronic information exchange between
  individuals as well as information through databases and other services.

Commitment to Democracy -

  The SCN will promote participation in government and public dialogue.
  Users will be actively involved in the ongoing development of the SCN.

  The SCN will place high value in freedom of speech and expression and in
  the free exchange of ideas.

  We will make every effort to ensure privacy of the system users, using the
  Code of Fair Information Practice as our guide.

  We will participate in ensuring and promoting the existence of democratic
  use of electronic technology.

Commitment to the World Community

  In addition to serving the local community, we will strive to become part
  of a larger national and international community.

  We will strive to build a system that can serve as a model that could be
  adopted in other communities.

Commitment to the Future -

  We will continue to evolve and improve the SCN.  In the future, this could
  include voice telephone access or graphic output.

  We will work with information providers and with groups involved in
  projects involving other media, such as public access television, to
  support our principles.

  The SCN will expand the use of community networks to include applications
  like electronic town halls for community goverance, or electronic
  encyclopedias for enhanced access to information.

  We will solicit feedback on the technology while in use, and strive to
  make it as accessible and humane as possible.


From igc.org!commem!carl Wed May 13 08:31:39 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "13" "May" "1992" "08:31:02" "-0700" "commem!carl@igc.org" "commem!carl@igc.org" nil "52" "Re: DRAFT set of principles" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Wed, 13 May 1992 08:31:38 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11943>; Wed, 13 May 1992 08:31:07 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12012>; Wed, 13 May 1992 08:30:31 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 13 May 1992 08:30:20 -0700
Received: from cdp.igc.org ([192.82.108.1]) by alpha.xerox.com with SMTP id <12012>; Wed, 13 May 1992 08:29:53 PDT
Received: by cdp.igc.org (4.1/Revision: 1.65 )
	id AA20454; Wed, 13 May 92 08:31:02 PDT
X-NS-Transport-ID: 08002008D0FD001CB4E8
Message-ID: <9205131531.AA20454@cdp.igc.org>
Date:	Wed, 13 May 1992 08:31:02 -0700
From:	commem!carl@igc.org
To:	community-access@parc.xerox.com
Subject: Re: DRAFT set of principles

Doug -
  I thought your draft contained a very good & fairly complete set of
principles.  I wanted to draw your attention to a few points, however.
This is more in the spirit of alerting you to potential problems that
handing out solutions, but maybe it will trigger ideas from some other
source.

>  Access to the SCN will be free to all.

I think the biggest problem with these types of networks is funding.  What
are your plans in this regard?  If you're planning on foundation funding,
some degree of self-financing will appeal to them.  Also, there are clearly
people in every community who could afford to pay to access these services,
and I think you'll need to tap that resource.  Maybe something like public
radio would work, where you CAN use it free but you're encouraged to support
it.

>  We will strive to provide access to all groups of people, regardless of
>  gender, age, national or ethnic background, socio-economic status, sexual
>  preference, educational attainment, religious affiliation, or political
>  beliefs.

>  We will strive to provide access to people with special needs.  This
>  includes both special-purpose interfaces as well as support for non-
>  English speakers.

>  We will strive to make the SCN accessible from public places.

I support all of the above.  In practice, you'll find that each group you try
to reach will (especially at first) be a commitment of scarce resources, and
so to some extent be competing with each other.  So it's important to have
a plan that targets a core of supporters and moves out from there, while
maintaining positive relations with communities further down the list.

>  We will provide the support for electronic information exchange between
>  individuals as well as information through databases and other services.

One of my favorite things to rant and rave about is how services which
support both databases and exchange between individuals make such obvious
distinctions between the two, which tends to preserve the power of large
information providers to establish the "official truth", while the rest
of us just get to talk about it.  Think about how you want this to look.
At the very least, databases should support some way for rank-and-file users
to respond to what they see in a way that's readily accessible to subsequent
browsers of the database.

In general, if I didn't say otherwise, I like it.  I thought the Democracy 
stuff was particularly good coverage of the issues involved.

This project sounds interesting.  Tell us more.
-Carl


From cruzio.santa-cruz.ca.us!chris Fri May 15 10:43:11 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "15" "May" "1992" "10:01:36" "-0700" "Happy Fun Ball" "chris@cruzio.santa-cruz.ca.us " nil "72" "Re: DRAFT set of principles" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29587>; Fri, 15 May 1992 10:43:09 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11777>; Fri, 15 May 1992 10:42:55 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11782>; Fri, 15 May 1992 10:42:00 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Fri, 15 May 1992 10:41:46 -0700
Received: from cdp.igc.org ([192.82.108.1]) by alpha.xerox.com with SMTP id <11755>; Fri, 15 May 1992 10:41:23 PDT
Received: from netcomsv.netcom.com by cdp.igc.org (4.1/Revision: 1.65 )
	id AA26704; Fri, 15 May 92 10:42:27 PDT
Received: from cruzio.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1)
	id AA03231; Fri, 15 May 92 10:40:24 PDT
Received: by cruzio.santa-cruz.ca.us (smail2.5)
	id AA03895; 15 May 92 10:01:36 PDT (Fri)
X-Mailer: ELM [version 2.3 PL0]
X-NS-Transport-ID: 08002008D0FD001CDAE9
In-Reply-to: "<9205131531.AA20454@cdp.igc.org>; from \"commem!carl\" at May 13, 92 8:31 ame?  "
Message-ID: <9205151001.AA03895@cruzio.santa-cruz.ca.us>
Date:	Fri, 15 May 1992 10:01:36 -0700
From:	chris@cruzio.santa-cruz.ca.us (Happy Fun Ball)
To:	commem!carl@netcom.com
cc:	commem!parc.xerox.com!community-access@netcom.com
Subject: Re: DRAFT set of principles

> 
> Doug -
>   I thought your draft contained a very good & fairly complete set of
> principles.  I wanted to draw your attention to a few points, however.
> This is more in the spirit of alerting you to potential problems that
> handing out solutions, but maybe it will trigger ideas from some other
> source.
> 
> >  Access to the SCN will be free to all.
> 
> I think the biggest problem with these types of networks is funding.  What
> are your plans in this regard?  If you're planning on foundation funding,
> some degree of self-financing will appeal to them.  Also, there are clearly
> people in every community who could afford to pay to access these services,
> and I think you'll need to tap that resource.  Maybe something like public
> radio would work, where you CAN use it free but you're encouraged to support
> it.

What he said.
Also, a different look at the services, and who provides them.
When I first started cruzio, I immediately assumed I would get a computer,
a bunch of modems and phone lines, and start a central service. In
other words, if you want access to these services, you have to call 
my machine.

This approach can be quite expensive, as Carl points out.

We (peggy and I) did that for a couple of years, then decided to stop and look
again at what we were doing. 

It turns out, our basic assumptions were getting in our way. Right
off the bat, the "we will provide the following services". It 
presupposes a centralized system controlled/provided by us ($$$).

When we change "we will..." to "the following services will be
available to the community", suddenly, a lot less (of our) cash
was involved with the proposition.

We wanted to see the following services in the community:

1. email
2. discussion forums
3. databases
	A. community calendar
	B. directory of community groups and government agencies
	...
4. public terminals

As it turns out, in our community, there are a number of message/disscussion
BBSes and public access UNIX systems which provide a platform for email 
and distributed discussions with an existing user base. 

So we decided to keep our system, cruzio, but to focus for a while
on networking the various systems, to connect the various islands
of existing users out there. With the advent of the network, 
connectivityof indivviduals and communities became the main goal, 
and services 1-3 above become distributed services across the network. 
Email is relatively easy because most unix systems and most of the 
pc flavors of unix mail support the standard email interchange format. 
So, all of us can send mail to each other. The discussion forums 
are also easy, using BNews and the pc flavors which sit on top of 
the forms of uucp. We are in process of developing distributed databases 
which will sit on top of the mail and news and uucp.

I guess what I am getting at is that one does not always need to "provide"
the services. In some cases, it might be possible to facilitate
the coming together of already existing resources in the community.
And, as someone mentioned at DIAC, computers might not be necessary
in some cases. After all, what everyone is really trying to accomplish
is people networking, not computer networking.

ccn

From igc.org!commem!carl Tue May 19 01:38:39 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "19" "May" "1992" "01:37:49" "-0700" "commem!carl@igc.org" "commem!carl@igc.org" nil "49" "Report on Workshop" "^Date:" nil nil "5"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Tue, 19 May 1992 01:38:34 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11731>; Tue, 19 May 1992 01:38:10 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11739>; Tue, 19 May 1992 01:37:28 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 19 May 1992 01:36:59 -0700
Received: from cdp.igc.org ([192.82.108.1]) by alpha.xerox.com with SMTP id <11739>; Tue, 19 May 1992 01:36:29 PDT
Received: by cdp.igc.org (4.1/Revision: 1.65 )
	id AA02518; Tue, 19 May 92 01:37:49 PDT
X-NS-Transport-ID: 08002008D0FD001CFD92
Message-ID: <9205190837.AA02518@cdp.igc.org>
Date:	Tue, 19 May 1992 01:37:49 -0700
From:	commem!carl@igc.org
To:	community-access@parc.xerox.com
Subject: Report on Workshop

This is a quick summary of some of the major points covered in the workshop
at DIAC '92 on Community Access to Telecommunications.  It is a first cut
at listing the issues raised in the disscussion, and comes from my somewhat
scanty notes.  Comments and additions are encouraged and appreciated.  Items
are in no particular order.

Models - there are lots of different approaches in use for trying to make
    telecom more accessible.  The workshop covered public terminals,
    networked BBSs, and Minitel terminals in some detail, and touched on
    other technologies, particularly telephones and audio messaging.  It
    seemed to be true that no one technology was the best for all 
    applications.  (Open issues: what other models have been tried?  what
    are the particular strengths and weaknesses of each?  which ones have
    useful synergies?  are any particularly suited to addressing the
    traditional usership biases of telecom networks such as gender
    imbalances?)

Chicken & Egg - the problem of getting an on-line community going is common
    across different models.  A variety of promotional ideas and ideas for
    developing a core usership were touched on briefly.  (Open issues: how
    do different approaches work out in practice?  what are the advantages
    and disadvantages of leaning heavily on existing networks to get things
    moving?)

Chat Services - chat services formed an important attractive element of two 
    of the networks discussed.  There was some feeling that this type of 
    service was less serious or important somehow, but immediate feedback
    on some level tends to be critical to the success of community access
    systems.  (Open issues: are prejudices against chat just prejudices, or
    are there major limitations to the form?  Can other forms of communication
    benefit from more interactivity somehow?  Does the immediate nature of
    chat work against thoughtful dialogue?)

Partnerships - all of the services relied to some extent on partneships
    with community institutions to support their networks, provide
    information or services, or attract users.  (Open issues: what kinds of
    partnerships work best?  are there dangers involved in partnerships?
    what services and information are used by which users?)

Censorship - all of the services had given a lot of thought to censorship
    policies, and all had the basic goal of nurturing a diverse and open
    environment.  There were differences in the level of involvement and
    the details of policies.  There was a lot of interest in social controls,
    where the users set their own standards and enforce them through peer
    pressure.  (Open issues: what are the legal implications of various 
    policies?  what policies result in the optimum willingness of participants
    to speak out?  what is the current state of knowledge about social
    controls?)


From uunet.uu.net!llnc!ptw08 Sun Jun  7 20:45:14 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil t nil]
	[nil "Sun" "7" "June" "1992" "05:34:11" "-0700" "Peter Miller" "ptw08@llnc.linknet.com " nil "374" "Computers&SocialChange: The Conferences" "^Date:" nil nil "6"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 7 Jun 1992 20:45:08 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12029>; Sun, 7 Jun 1992 20:44:41 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12026>; Sun, 7 Jun 1992 20:44:05 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Sun, 7 Jun 1992 20:43:38 -0700
Received: from relay2.UU.NET ([137.39.1.7]) by alpha.xerox.com with SMTP id <12028>; Sun, 7 Jun 1992 20:43:18 PDT
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA24550; Sun, 7 Jun 92 23:43:19 -0400
Received: from llnc.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 234254.2567; Sun, 7 Jun 1992 23:42:54 EDT
Received: by llnc.linknet.COM (smail 3.1.21.1)
	id <m0luR88-0000WVC@llnc.linknet.COM>; Sun, 7 Jun 92 12:34 CDT
X-NS-Transport-ID: 08002008D0FD001DF810
Message-ID: <m0luR88-0000WVC@llnc.linknet.COM>
Date:	Sun, 7 Jun 1992 05:34:11 -0700
From:	ptw08@llnc.linknet.com (Peter Miller)
Sender: llnc!ptw08@uunet.uu.net
To:	community-access@parc.xerox.com
Subject: Computers&SocialChange: The Conferences

6/7/92 - 1


6/6/92

OK, folks, here is a draft on the conference(s). It's woefully inadequate to
the task but it does have some of the orientations and sensibilities I'm trying
for even if there's still lots missing. What I'd like to do is two or three
things with your help. First, some specific feedback and suggestions to
incorporate and add-in would be welcome, just about anything you think's
important. I'm sure I needn't point out gaps and please do disagree with any
"judgments" I've made. I'd like to incorporate and expand this for the upcoming
issue of Impact with an eye towards a second revision with more stuff on DIAC
for a CPSR and/or more general audience. I'd like to incorporate stuff directly
into the piece and also include sidebars on the workshops (or other aspects),
so you can be as expansive about anything you think would be useful to let
folks know about.

Resurgamus,
Peter Miller


COMPUTERS AND SOCIAL CHANGE: THE CONFERENCES

The second annual New England Computers and Social Change Conference was
officially scheduled for Friday and Saturday, April 24 and 25, at Northeastern
University, on the second and third floors of the Ell Student Center just
behind the main quad at the Huntington Avenue MBTA stop. It got something of a
quasi-official opening two days earlier, a few blocks farther downtown, on
Clarendon Street, in the New England Life Hall where the Boston Computer
Society's General Meeting hosted a panel on the the rise of Electronic Bulletin
Boards and threats to our First Amendment freedoms. With Mike Godwin from the
Electronic Frontier Foundation, Marc Rotenberg from the Washington office of
Computer Professionals for Social Responsibility (CPSR), Tom Hemmes (Foley,
Hoag and Elio), and Harvey Silverglate (Silverglate and Good), it was as good
as any program starring four lawyers could be.

The conference proper opened Friday at noon. The tables in the Resource
Room--actually the periphery of the main ballroom where all the keynote
programs and Saturday's lunch took place--were peopled by a good range of
community and technical group reps having as good a time talking with one
another as with the conference participants. The whole conference was like that
in a sense. Elyssa Abruzzo from Gifts in Kind/United Way was right at the
entrance, meeting in person folks she had talked with for years over the phone,
chatting about their software donations program and the terrible situation with
the national office. There was a smattering of for-profit groups which assisted
community-based organizations and nonprofits, there in large part because of
active cross-over ties--the Telluride Group (its President, Jeff Behrens, is
director of NPAP, the BCS NonProfit Assistance Program), BTC (Born to Code)
with its donor and volunteer tracking software (principal Shirley Terry has
been a Boston community activist for many years), and the Trieschman Center
(which had just received a boost from the BCS Public Services Committee for its
summer Mental Heath/Informations Systems Resource conference). The Institute
for Health Policy, Research and Education under the Department of Health and
Hospitals was showing off MicroMax, designed for human service personnel to
assist in locating benefits for low-income clients (Stefanie Whaley had worked
for many years at EDC, the Education Development Center in Newton, and was a
volunteer at the Somerville Community Computing Center).  Computer technology
assistance groupsQNPAP, the Information Technology Assistance Program (NH),
NonProfit Computing (NY), the Technology Education Council of Somerville, the
East West Education Development Foundation, CPSR, PeaceNet, Global Link, the
Lotus Philanthropy Program, the Coalition on New Office TechnologyQmixed with
community groups themselves, from UMass/Boston College of Public and Community
Service (recently evicted from their downtown center campus where they had
hosted last year's founding Computers and Social Change Conference), Community
Jobs, Survival News (official newspaper of the National Welfare Rights
Organization), Haymarket People's FundQand, of course, reps from many of the 40
or 50 BCS special interest and user groups. All told, more than half of the 42
or so conference cosponsors had a lively presence.

The first overall impression pretty generally shared by the organizers lasted
through to the end: "The numbers weren't great but everything else was." The
conference directory listed 181 workshop presenters and participants; this
year's was planned well enough to accomodate twice that number.  While it
wasn't the crowded chaos and intensity of version 1.0 at the UMass/Boston CPCS
downtown center, the networking was looser, much easier and just as rewarding.

After welcomes by conference chair Coralee Whitcomb and BCS Public Service
chair Dan DiBartolomeo, the Technology at Work panel officially began the
conference program as the first of four scheduled keynotes and 27 workshops,
lead by three women, in contrast to all the white males leading off the
previous year: Elaine Bernard, Executive Director of the Harvard Trade Union
Porgram; Judy Perrolle, Professor of Sociology at Northeastern, and Barbara
Garson, author of The Electronic Sweatshop, about how computers are
transforming the office of the future into the factory of the past.  Barbara
told the story from her book about the transformation which took place in the
Boston Welfare Department when computers arrived, a move which had been
initially lobbied for by the social workers themselves but whose actual
implementation was ominously signified by the change in title from Social
Worker to Financial Assistance Worker or Eligibility Technician.  Wayne Clark,
conference program coordinator and panel moderator, introduced Judy Perrolle as
author of a book entitled Computers and Social Change (true) which was about
the same theme as the conference (false). Judy demured from explaining that her
book was really a theoretically ambitious attempt to show how to begin to think
about computers in an academic context (sociology), using Max Weber as the
visionary guide on theme. The jovial, good-natured exchange between Wayne and
Judy reflected the ambiance of the conference itself. The three panelists later
ended up in one of the afternoon workshops together. As Barbara Garson put it,
just the opportunity for the three of them to meet and talk with each other was
worth the trip.  She left an armload of her books at the registration table
when she had to leave for New York later that afternoon; they sold out quickly.
      
In contrast with the previous year, there was more active organizational
involvement from the community group sideQCPCS, Survival News, Haymarket
People's Fund, and the Mass Association of Community Development Corporations
(MACDC), in particular, though given the large number of community group
cosponsors, their more active and widespread involvement in the future would be
extremely useful. CPSR, thanks in large part to Coralee, who also serves as
president of the Boston chapter, was much more involved this year with
organizers, workshop leaders and participants. CPSR's presence was also strong
because of Gary Chapman's work with the 21st Century Project and the
substantial Rockefeller grant to support this effort for redirecting research
and development efforts towards civilian and peacetime needs.  Although the
Massachusetts Environmental Lobby has not come as far along as its promise of
last year and the active presence of SEIU and other unions from last year was
absent this time, the workshop "Toward a Responsible National Technologhy
Policy: Redirecting U.S. Industrial Policy Toward Rebuilding Communities,"
jointly presented by Gary and Rand Wilson, who is with the Campaign for
Responsible Technology and the Labor Resource Center indicated the growing
environmental and labor involvement and alliance with computer technology
progressives concerned with its democratic use and development.

There were some organizational losses, to be sure.  The BCS handicapped special
interest groups which had both conference planners and workshops the previous
year couldn't manage either this time. Last year BCS President Tracy Licklider
was a vocal leader in calling for the delivery of good technical assistance and
support to the community; in his place this year was a somewhat less
substantial, about-to-be-announced new BCS president. Nonetheless, overall the
BCS itself has actually become much more involved. The board and staff are much
more supportive of the conference being an important part of BCS Public Service
identity. The BCS Mac Group--thanks to Pete Smith and Ken Sargent--and the BCS
PC group, thanks largely to its president Bill Claff as well as the active
presence of the BCS Women's Group which sprang from its IBM-PC users, are now
much more integrated not only into the conference but also into BCS public
services in general. NPAP, the Non-Profit Assistance Program, has grown since
last year and was active in the workshops as well as the Resource Room. BCS was
not only about to get a new President but also its first public service staff
coordinator.

The afternoon workshops were sparse in places and, interestingly, the one that
drew the most interest was on electronic networks, the way in which electronic
mail and resources help communities of common interest organize themselves, how
the Internet, the network of networks, is evolving, and how Mass On-Line, an
effort to make Internet access available for public interest use, is coming
along.  Since Ed Markey, chair of the House Subcommittee on Telecommunications,
was rescheduled from Friday to Saturday morning, the afternoon was open to end
fairly casually and upbeat in the Resource Room. No formal evening event was
planned, and Friday night found the conference organizers all celebrating at
Skipjack's on Route 9 in Brookline, hosted with spur-of-the-moment graciousness
by Andy Shapiro and the Interface Group.

Conference planners already knew that Ed Markey, who had been rescheduled to
Saturday morning a few weeks previously, would not be coming nor would any
representative from his office, the last of whom called two days before the
conference to ask for travel money. This was the week which began with word of
Markey's involvement with the bounced checks in the House of Representatives.
In his place the conference had already arranged for Geoff Sears, President of
the Institute for Global Communcations, parent organization for PeaceNet and
EcoNet.

Geoff Sears signified both the growing IGC/PeaceNet presence in the Boston area
as well as the general growth in Boston/Bay Area community computing ties
which, despite the commonalities and shared culture between the 128 Belt and
Silicon Valley, are very recent as far as the technology and social change
movement goes (with the exception of CPSR). Last year Howard Frederick,
National Director of PeaceNet, keynoted the first New England Conference (BCS
Update, November 1991) and, as one result, keynoted the New York conference a
few months later (Impact, January 1992), a conference, incidentally, which did
not take place this year. Charlie Rosenberg was introduced as the official
PeaceNet rep in the area (617/524-6273, crosenberg@igc.org).

As to the wider ties, Tom White, circulation director for the Whole Earth
Review, sent a box of the winter '91 Questioning Technology issue as an
expression of solidarity and best wishes for the conference. Copies were given
to conference organizers with the remainder distributed by an announced drawing
open to any conference participant.

Geoff is modest. Upon being asked for a biographical blurb for intro purposes,
he sent the following:

Born in California 6/15/61.  degrees in mechanical & civil engineering from
stanford U.  studied russian at Leningrad State U; used to speak Russian very
well; now it's pretty rusty.  built & tested solar heating equipment for small
engineering company. lived 2 years in Philippines as VIA volunteer; traveled
extensively in Philippines, Indonesia.  worked at IGC since April, 1988;
director of IGC since July 1988.  discovered use of modems for social action
while in Philippines.

hope that's enough!
- geoff

I was involved in two workshops on Saturday--on the Community Computer Center
Movement in the morning, Assisting Nonprofits with Computer Technology in the
afternoon. Both were incredibly well attended by panelist/presenters as well as
participants, though I have yet to see any of the evaluations. Mel King's
keynote closing was refreshing for his awesome presence and suddenly the
audience was as integrated as any community technology group I've ever seen, a
fitting close.

The organizers will be getting together sometime soon for a criticism/
self-cricism good time review and in preparation for next year.

One Week Later: Computers and Social Change Conference II, Berkeley, CA

"DIAC" or the "Directions and Implications in Advanced Computing" Conference is
by no means a "Computers and Social Change" West.  It's sponsored by Computer
Professionals for Social Responsibility and cosponsored by a number of other
organizations, some with a lot of vowels in their acronyms, like IEEE, AAAI,
ACM SIGCHI, ACM SIGCAS, and the BCS Social Impact group, so the social change
emphasis comes squarely from the side of the professionals.

This was DIAC #4. It's grown in stature and prominence over the years as has
CPSR. Originally begun as the scientific/technological opposition to Star Wars
in the early 80's, in 1984 CPSR/Boston organized a demonstration outside a
local seminar on "Battlefield/AI (Artificial Intelligence) Robotics" which
attracted national media attention because of the inclusion among the marchers
of a rented R2-D2 robot with a sign reading: "Don't worry--nothing can possible
go worng."

Through the 80's, CPSR chapters formed across the country and the organization
developed. CPSR became involved with groups like International Physicians for
the Prevention of Nuclear War and undertook numerous anti-SDI research, writing
and demonstration projects with CPSR/Seattle member Jon Jacky publishing "Star
Wars Defense Won't Compete" in the Atlantic Monthly in 1985. Other programs
were developed--in Civil Liberties and Privacy, leading to the establishment of
a Washington office headed by Marc Rotenberg (brother of BCS founder John); on
computers and the workplace, leading to a recurring national conference on
Participatory Design (think of what would have happened had those Boston Social
Workers been able to help design the system there were to use); and examining
federal funding for scientific research which led to the 21st Century Project.
CPSR has developed programs in computers and education, women in computer
science, and initiated DIAC as a biannual national gathering.

Actually, it's not quite true to say that the social change orientation of this
year's conference came solely from the side of the professionals.  The Los
Angeles riots sparked by the Rodney King decision began Wednesday night. There
was a massive demonstration and bust of hundreds of demonstrators at Glide
Memorial Church in San Francisco. Just south of the Berkeley campus, the stores
on Telegraph and Dwight were boarded up for many blocks and on Saturday noon
there was a growing gathering at People's Park, eerily reminiscent for those
who had been in Berkeley in earlier decades.

"The current federal R&D budget is a welfare program for computer scientists,"
said Gary Chapman, speaking for himself, in one of the more dramatic moments of
the conference. Saturday was a solid day of keynotes which all 80 or so of us
went through together except for lunch.

One of the major things I learned was that when you say "community computing"
or "computers and social change" in the Bay Area and in certain other circles,
it's inevitably an on-line project of some sort (though within a certain
community computing karass Glide Memorial does present a project of major
interest). That was clear from the opening address, "Innkeeping in Cyberspace,"
on building communities with online tools, with John Coate, well-known
Community Builder at the WELL (Whole Earth 'Lectronic Link), now Director of
Interactive Services for 101 OnLine.

The 225 page book of DIAC proceedings, with summaries and papers from all the
keynoters and workshop presenters, is an incredibly useful resouce.  While the
second keynote, "Computer Networks in the Workplace: Factors Affecting the Use
of Electronic Communications," reiterated the preoccupation with online
resources, it also pointed up the weaknesses of CPSR's academic orientation
("Faculty who are given on orientation to on-line systems tend to use them more
than those who don't.") The presentation by Hal Sackman from Cal State
University at LA, on "Computer Workstations: The Occupational Hazard of the
21st Century" demanded comparison with Karen Van Kooy's Coalition for a New
Office Technology workshop on "Computers and Repetitive Strain Injury" a week
earlier in Boston. Sackman's paper and presentation were expansive and
definitive--key words, musculoskeletal and repetitive motion illness, visual
morbidity at the VDT, potential workstation hazards with eletromagnetic fields,
psychoneuroimmunological stress syndromes, references. The CNOT workshop was
presented in a context of groups actively involved in the struggle against new
office technology and trying to define and shape that technology in more
liberating ways.

Pavel Curtis, Xerox PARC, gave the first of his three presentations before
lunch. As an individual (as well as showman), he defined this conference as
much as anyone, beginning here with a presentation on MUDDING: the social
phenomena in text-based virtual realities. According to the abstract: "A MUD
(Multi-User Dungeon or, sometimes, Multi-User Dimension) is a
network-accessible, multi-participant, user-extensible virtual reality whose
user interface is entirely textual. Participants (usually called players) have
the appearance of being situated in an artificially-constructed place that also
contains those other players who are connected at the same time.  Players can
communicate easily with each other in real time. This virtual gathering place
has many of the social attributes of other places, and many of the usual social
mechanisms operate there. Certain attributes of this virtual place, however,
tend to have significant effects on social phenomena, leading to new mechanisms
and modes of behavior not usually seen 'IRL' (in real life)."

The paper and the presentation relate Pavel's experiences and observations from
having created and maintained a MUD for over a year.

So much on telecommunications seemed quite a distance from Computers and Social
Change, the most extended presentation and discussion part of the session
revolved around the whys, combinations, and permutations of male and female
players taking male, female and gender-neutral names and identities. Much of
the MUDDING/virtual reality discussions which took place throughout the
conference after this returned to those who spend 20, 40, 70 hours a week
hooked to fanciful, online worlds. The occasional points about on-line
pathology gave an interesting perspective on the conference and its
participants.

Gary Chapman's comment about "Funding Computer Science R&D" being a form of
welfare came during the afternoon panel and put the unsuspecting Joel Yudken on
the defensive for his defense-funded project on regional and industrial
economics at Rutgers, and one sensed that many in the audience had only
infrequent occasion to direct their anger at any individual in particular. The
first day ended with a panel discussion on, of course, Virtual Society and
Virtual Community, closing remarks by CPSR President Eric Roberts, and a
cocktail party to welcome Evelyn Pine to her new position as Managing Director
of CPSR, over at the International House, on Piedmont on the other side of the
campus, giving those who chose to walk another (or a first) opportunity to see
the boarded up store fronts south of campus.

There were six or eight or so of us at DIAC from Boston. I had received a
mailing during the week before to elect CPSR national board members for the
coming year, and was pleased to see a ballot sheet for Steve Miller, formerly
with the media project at Urban Planning Aid, at the UMass/Boston School of
Continuing Education, later with the Lotus Development Corporation where he was
founding editor of Lotus Magazine, later at the Kennedy School of Government,
now with the Commonwealth of Massachusetts' Office of Technology Planning.
Steve organized last year's Computers and Social Change workshop on Getting
Access to Public Information. I was invited to DIAC to do a workshop proposal
on "Defining the Community Computing Movement: Some projects in and around
Boston" and got officially sent by the Technology Education Council of
Somerville as Director of the Somerville Community Computing Center and by the
BCS as a Public Service Activist.

Sunday consisted of three parallel workshop sessions with four or five
concurrent offerings and a closing panel of special interest to computer
professionals of all sorts on what's happening with the jobs.

The early afternoon workshop on "Examining Different Approaches to Community
Access to Telecommunications Systems" was listed as being given by Evelyn Pine,
up until recently Director of Community Memory, with terminals in laundromats,
libraries and throughout town to promote community dialogue, bartering, job
searches and other services. The workshop ended up including a presentation on
Community Memory (see page ____), CruzIO in Santa Cruz which has tied together
people who are on different electronic networks, SFNet which has home
subscribers and terminals in local bars and coffee houses with quarter slots,
and the I-Tel 101 OnLine project which gives people an easy-to-use, portable,
toaster-size terminal which attaches to their phone jacks when they purchase
information, education, and recreational services and is based on a similar
system in France.  It's not surprising that an electronic discussion
group/mailing "community-access" list/conference has emerged from this
workshop.

After the what is happening with computer jobs panel, DIAC was closed by
Coralee Whitcomb, who had opened Computers and Social Change conference eight
days earlier on the other side of the country. She gave a moving and eloquent
statement of the timeliness and opportunities at hand, both personally and for
the movement. Two years ago the idea of virtual reality, the theme of the last
DIAC Conference, was academic esoterica--recently the Boston Computer Museum
was flooded by visitors to its day-long virtual reality exhibit.  Three years
ago Coralee wasn't even a member of CPSR; now she was on its national board.
Within two weeks she would be the first BCS Public Service program coordinator.

As for me, I got to extend my stay and visit IGC/PeaceNet, the Whole Earth
Review/WELL, and Daniel Ben-Horin, who's the director of CompuMentor, which the
BCS NonProfit Assistance Program is affiliated with and which helps programs
across the country match up and manage technically-skilled computerists with
nonprofits and community groups which need assistance. I got to talk with
people at Apple Community Affairs and HandsNet. My workshop had gone modestly
well and I gave another version farther south a few days later.  There's some
interest in extending/developing conferences for social change constituencies;
there's interest in setting up community computing centers in Santa Cruz, East
Palo Alto and Toronto. I've learned about new publications resources, and
Impact now has a west coast editor. Local activity is on the rise and people
are communicating with one another over vast distances. There's a true "Think
Globally, Act Locally" movement going on. The infrastructure is being built and
the new Committees of Correspondence are forming. All this talk about the
electronic frontier and the early days is really true--the laws have yet to be
established. Yes, it's a time of opportunity indeed.


From xerox.com!parc.xerox.com.PARC Wed Jun 10 15:05:30 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "10" "June" "1992" "15:01:00" "-0700" "Paul Hyland" "PHYLAND@gwuvm.gwu.edu" nil "32" "New List - CPSR" "^Date:" nil nil "6"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Wed, 10 Jun 1992 15:05:22 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12007>; Wed, 10 Jun 1992 15:05:00 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12017>; Wed, 10 Jun 1992 15:04:23 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Wed, 10 Jun 1992 15:02:31 -0700
Received: from gwuvm.gwu.edu ([128.164.129.1]) by alpha.xerox.com with SMTP id <12017>; Wed, 10 Jun 1992 15:02:11 PDT
Received: from GWUVM.GWU.EDU by gwuvm.gwu.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 5769; Wed, 10 Jun 92 18:01:21 EDT
Received: from GWUVM (PHYLAND) by GWUVM.GWU.EDU (Mailer R2.08) with BSMTP id
 2595; Wed, 10 Jun 92 18:01:20 EDT
X-NS-Transport-ID: 08002008D0FD001E2566
Message-ID: <92Jun10.150211pdt.12017@alpha.xerox.com>
Date:	Wed, 10 Jun 1992 15:01:00 -0700
From:	Paul Hyland <PHYLAND@gwuvm.gwu.edu>
Sender: parc.xerox.com.PARC@xerox.com
To:	Community Access Mailing List <community-access@parc.xerox.com>
Subject: New List - CPSR

Computer Professionals for Social Responsibility (CPSR) has set up a list
server to (1) archive CPSR-related materials and make them available on
request, and (2) disseminate relatively official, short, CPSR-related
announcements (e.g., press releases, conference announcements, and project
updates).  It is accessible via Internet and Bitnet e-mail.  Mail traffic
will be light; the list is set up so that only the CPSR Board and staff
can post to it.  Because it is self-subscribing, it easily makes material
available to a wide audience.

We encourage you to subscribe to the list server and publicize it widely,
to anyone interested in CPSR's areas of work.

To subscribe, send mail to:

        listserv@gwuvm.gwu.edu (Internet) OR
        listserv@gwuvm (Bitnet)

Your message needs to contain only one line:

        subscribe cpsr <your first name> <your last name>

You will get a message that confirms your subscription.  The message also
explains how to use the list server to request archived materials (including
an index of everything in CPSR's archive), and how to request more information
about the list server.

Please continue to send any CPSR queries to cpsr@csli.stanford.edu.

If you have a problem with the list server, please contact the administrator,
Paul Hyland (phyland@gwuvm.gwu.edu or phyland@gwuvm).

We hope you enjoy this new service.

From xerox.com!parc.xerox.com.PARC Wed Jun 10 15:12:11 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "10" "June" "1992" "15:01:38" "-0700" "Paul Hyland" "PHYLAND@gwuvm.gwu.edu" nil "16" "Network Policies" "^Date:" nil nil "6"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Wed, 10 Jun 1992 15:12:09 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12013>; Wed, 10 Jun 1992 15:11:45 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12016>; Wed, 10 Jun 1992 15:11:13 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 10 Jun 1992 15:09:41 -0700
Received: from gwuvm.gwu.edu ([128.164.129.1]) by alpha.xerox.com with SMTP id <12033>; Wed, 10 Jun 1992 15:09:08 PDT
Received: from GWUVM.GWU.EDU by gwuvm.gwu.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 5780; Wed, 10 Jun 92 18:08:36 EDT
Received: from GWUVM (PHYLAND) by GWUVM.GWU.EDU (Mailer R2.08) with BSMTP id
 2685; Wed, 10 Jun 92 18:08:35 EDT
X-NS-Transport-ID: 08002008D0FD001E2585
Message-ID: <92Jun10.150908pdt.12033@alpha.xerox.com>
Date:	Wed, 10 Jun 1992 15:01:38 -0700
From:	Paul Hyland <PHYLAND@gwuvm.gwu.edu>
Sender: parc.xerox.com.PARC@xerox.com
To:	Community Access Mailing List <community-access@parc.xerox.com>
Subject: Network Policies

I am working with Cap Access here in DC, on the committee developing
Policies and Procedures for our net.  We have many examples already --
particularly from Freenet sites -- but want some more varied examples.

I would appreciate copies of network policy statements from any network
out there that has them written down -- everything from registration of
users (and guest access) and time limits, to unacceptable speech, to
procedures for starting new topics or groups, whatever.

Please send them to me directly, particularly if they are long.
I can summarize our results, as well as our process, for the list.

Thanks,

Paul Hyland
phyland@gwuvm.gwu.edu

From xerox.com!parc.xerox.com.PARC Tue Jun 16 09:31:55 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "15" "June" "1992" "19:14:04" "-0700" "John B Harlan" "JBHARLAN%INDYVAX.IUPUI.EDU@gwuvm.gwu.edu" nil "148" "NEW LISTS: SBNnet - South Bend [IN USA] area lists" "^Date:" nil nil "6"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Tue, 16 Jun 1992 09:31:54 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11909>; Tue, 16 Jun 1992 09:31:20 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11902>; Tue, 16 Jun 1992 09:29:25 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58371>; Tue, 16 Jun 1992 09:29:06 -0700
Received: from gwuvm.gwu.edu ([128.164.129.1]) by alpha.xerox.com with SMTP id <11843>; Tue, 16 Jun 1992 09:28:02 PDT
Received: from GWUVM.GWU.EDU by gwuvm.gwu.edu (IBM VM SMTP R1.2.2MX) with BSMTP id 0406; Tue, 16 Jun 92 12:27:19 EDT
Received: from GWUVM (PHYLAND) by GWUVM.GWU.EDU (Mailer R2.08) with BSMTP id
 8430; Tue, 16 Jun 92 12:27:17 EDT
Resent-Date: Tue, 16 Jun 1992 09:26:33 -0700
Resent-From: Paul Hyland <PHYLAND@gwuvm.gwu.edu>
Resent-To: Community Access Mailing List <community-access@parc.xerox.com>
Received: by GWUVM (Mailer R2.08) id 0540; Mon, 15 Jun 92 22:27:01 EDT
Resent-Message-Id: <92Jun16.092802pdt.11843@alpha.xerox.com>
X-NS-Transport-ID: 08002008D0FD001E6E03
XNS-Originator: parc.xerox.com.PARC@Xerox.com
Errors-to: parc.xerox.com.PARC@xerox.com
Date:	Mon, 15 Jun 1992 19:14:04 -0700
From:	John B Harlan <JBHARLAN%INDYVAX.IUPUI.EDU@gwuvm.gwu.edu>
Sender: NEW-LIST%NDSUVM1.BITNET@gwuvm.gwu.edu
To:	PAUL HYLAND <PHYLAND@GWUVM.bitnet>
Subject: NEW LISTS: SBNnet - South Bend [IN USA] area lists
Reply-to: JBHARLAN%INDYVAX.IUPUI.EDU@gwuvm.gwu.edu

Here's a new twist...
Paul
----------------------------Original message----------------------------
SBN on LISTSERV@IndyCMS          South Bend [IN USA] area lists
    or LISTSERV@IndyCMS.IUPUI.EDU

                               SBNnet

   SBNnet is an experiment in human networking for computer users in
   north central Indiana and southwest lower Michigan USA.  (SBN is the
   standard, three character aviation designation for South Bend,
   Indiana USA, the area's approximate geographic center.)

   The South Bend area community possesses a significant pool of talent
   in a wide variety of fields and academic disciplines.  SBNnet is an
   attempt to link that talent pool (making it more accessible to the
   area's computer-using community at large) and to foster a sense of
   community as electronic neighbors.  It is hoped SBNnet will include
   participants from area business and industry, higher education, non-
   profit organizations, and private individuals, joining in from home
   and work, to help their electronically connected neighbors.

   SBNnet is a network without dedicated hardware.  It uses electronic
   mail lists to disseminate information of local interest and to
   facilitate voluntary communication, assistance and cooperation
   between its participants.  Its only requirement for participation is
   some form of access to e-mail -- connection to academic / research
   networks such as BITNET / CREN / EARN / NetNorth et al, commercial
   services such as CompuServe and MCI Mail, uucp mail, etc -- in order
   to receive and reply to messages from other participants.  There is
   absolutely no cost for participating in SBNnet.  The only potential
   cost is that of an individual's access to electronic mail itself,
   since that is the medium through which SBNnet operates.

   SBNnet presently consists of eight distinct components, each a
   separate e-mail list available by free subscription from
   ListServ@IndyCMS / ListServ@IndyCMS.IUPUI.Edu:

            o  SBNbirds     South Bend area birds

                            SBNbirds is for news and discussion of
                            birds living in and/or flying through
                            our community.

            o  SBNchat      South Bend area conversation

                            SBNchat is for neighborly conversation
                            about news, sports, weather, etc., of
                            interest in our community.

            o  SBNevent     South Bend area events

                            SBNevent is for listings and notices of
                            events of interest in our community.

            o  SBNhelp      South Bend area help

                            SBNhelp is an electronic cross between a
                            library reference desk, a community
                            information and referral center, and a
                            computing center help desk -- with the
                            twist that all SBNnet participants are
                            potential service providers as well as
                            service users (i.e., "from each
                            according to his abilities, to each
                            according to his needs")

                            SBNhelp is intended to provide a forum
                            for informal information and referral,
                            and reference;  it is not limited in
                            subject matter (except that its use for
                            any type of commercial promotion or
                            transaction is strictly prohibited).

                            The modus operandi for the help
                            component is that a participant with a
                            question or need posts an e-mail message
                            to the SBNhelp list (address:
                            SBNhelp@IndyCMS.IUPUI.Edu), which is
                            then automatically redistributed to all
                            other participants.  Any participant who
                            has an idea to help answer the question
                            or address the need (or even suggest
                            another possible resource for doing
                            same) then posts an e-mail message back
                            to the SBNhelp list in reply, and that
                            reply is automatically redistributed to
                            the list.

                            In order to succeed and provide a
                            valuable service to our community's
                            computer users, the help component only
                            needs its participants to read SBNhelp
                            e-mail traffic and to respond to those
                            messages with which they may be able to
                            help.

            o  SBNjobs      South Bend area jobs

                            SBNjobs is for announcements of
                            positions available in the South Bend
                            area, and for statements of
                            qualifications and interests of those
                            persons seeking employment in our
                            community.

            o  SBNnews      South Bend area news

                            SBNnews is for the distribution of local
                            and regional news of interest in our
                            community.

            o  SBNsport     South Bend area sports

                            SBNsport is for the distribution of
                            sports information and scores of
                            interest in our community.

            o  SBNwx        South Bend area weather

                            SBNwx is for the distribution of
                            weather information of interest in our
                            community.

   A ninth list, SBN, is a superlist which automatically adds the
   subscriber to seven of the eight separate components described above.
   SBNwx is available only by separate subscription.

   A tenth list, SBNnet-L, is used to discuss the design, implementation
   and management of SBNnet, South Bend's human/e computing network.

   SBNnet is a network of good will and neighborliness, a dedicated
   service for the computer users of our community, computer users from
   all walks of life, at home and at work.  Having dealt with ListServ
   lists extensively over the past two to three years, I know personally
   the impact this technology can have on communication on a national
   and international scale;  I believe it can also be applied closer to
   home to facilitate the dissemination and exchange of information
   locally.

   If you are interested in participating in or observing this project,
   please contact me at the e-mail address or telephone number below.  I
   hope you will choose to be a part of SBNnet, South Bend's human/e
   computing network.

                            John B Harlan
                          JBHarlan@IndyVAX
                     JBHarlan@IndyVAX.IUPUI.Edu

From atc.boeing.com!douglas Tue Jul 28 11:15:16 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "28" "July" "1992" "11:09:46" "-0700" "Douglas Schuler" "douglas@atc.boeing.com" nil "72" "Template for community access computer systems" "^Date:" nil nil "7"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Tue, 28 Jul 1992 11:15:13 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11803>; Tue, 28 Jul 1992 11:14:00 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11799>; Tue, 28 Jul 1992 11:12:23 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 28 Jul 1992 11:11:56 -0700
Received: from atc.boeing.com ([130.42.28.80]) by alpha.xerox.com with SMTP id <11795>; Tue, 28 Jul 1992 11:11:24 PDT
Received: by atc.boeing.com (5.57) 
	id AA20998; Tue, 28 Jul 92 11:01:13 PDT
Received: by cleelum.boeing.com (4.1/SMI-3.0DEV3)
	id AA07813; Tue, 28 Jul 92 11:09:46 PDT
X-NS-Transport-ID: 08002008D0FD0020A2C4
Message-ID: <9207281809.AA07813@cleelum.boeing.com>
Date:	Tue, 28 Jul 1992 11:09:46 -0700
From:	Douglas Schuler <douglas@atc.boeing.com>
To:	community-access@parc.xerox.com
Subject: Template for community access computer systems


This suggestion is just one part of an idea that Richard Civille has
kicked around about a "handbook" for community access computer systems.
This is a template for describing moribund, existing, and planned
systems.  This template is a rough guide only because systems probably 
won't fit into the mold so nicely.

If people are willing to take a look at this proposed template and suggest
changes I'll be glad to change it around.  If people will fill this out
and return it to me, I'll be glad to act as a resource and to summarize
the results.

Sound reasonable??

--=-=  Doug



****  Please forward to community access computer systems people  *****


     -----------------------------------------------------
     FIRST CUT AT A TEMPLATE FOR COMMUNITY ACCESS NETWORKS
     -----------------------------------------------------

Current as of ________________, 1992.


System Name:

System Description and/or Charter:

Organization Name:

Organization type: [non-profit educational, etc.]

Organization description: [committee names & tasks, decision-making
processes]

Status: [planned, prototype, operational, etc.]

Internet address:

Dial-up phone number(s):

How accessed: [public terminals, dial-up, etc.(usage percentages would be
valuable!)]

Contact person info: [address, phone, FAX, e-mail, etc.]

Materials available: [published or on-line]

Usage fee policy:

Information policy info [e.g. profanity, copywrites, etc.]:

User demographics:

Number of accounts:

Average number of logins per day:

System hardware and software:

Staff: [volunteers and paid, titles, job descriptions, hours worked per week,
etc.]

Other notes:


------
Please return this as well as suggestions to douglas@atc.boeing.com.

From atc.boeing.com!douglas Wed Aug  5 08:49:18 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "5" "August" "1992" "08:44:52" "-0700" "Douglas Schuler" "douglas@atc.boeing.com" nil "70" "CapAccess Committees (FYI)" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Wed, 5 Aug 1992 08:49:15 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11910>; Wed, 5 Aug 1992 08:48:37 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11905>; Wed, 5 Aug 1992 08:47:24 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 5 Aug 1992 08:47:04 -0700
Received: from atc.boeing.com ([130.42.28.80]) by alpha.xerox.com with SMTP id <11916>; Wed, 5 Aug 1992 08:46:32 PDT
Received: by atc.boeing.com (5.57) 
	id AA13085; Wed, 5 Aug 92 07:54:29 PDT
Received: by cleelum.boeing.com (4.1/SMI-3.0DEV3)
	id AA18775; Wed, 5 Aug 92 08:44:52 PDT
X-NS-Transport-ID: 08002008D0FD002120C4
Message-ID: <9208051544.AA18775@cleelum.boeing.com>
Date:	Wed, 5 Aug 1992 08:44:52 -0700
From:	Douglas Schuler <douglas@atc.boeing.com>
To:	community-access@parc.xerox.com
Subject: CapAccess Committees (FYI)


In case any of you are interested, here is a list of committees that
the CapAccess group in Washington DC have put together.  CapAccess is
an amibitious effort similar to ours that is being developed slightly
differently.  

Richard Civille, CPSR staff, and Paul Hyland of the CPSR board are
both working on this project.  CapAccess is currently becoming a
501.c.3 (non-profit) entity.

-- Doug


>From washofc!civille@uu.psi.com Mon Aug  3 15:31:19 1992
From: Richard Civille <civille@washofc.cpsr.org>
To: Doug Schuler <douglas@atc.boeing.com>
Date: Mon, 3 Aug 1992 17:28:14 EDT
Subject: CapAccess Committees 

  CapAccess Committees

Doug:

CapAccess committees are:

Information services:  Develop the menu structure for the system, provide a
forum for potential information service providers to come into the project. 
Get to figure out the the freenet/feenet balance and how to cross-subsidize
fee-based services to support free public access.

User services:  Develop the "help-desk", both online and voice mail. 
Develop base of volunteer "mentors" to help others use the system.  Develop
two test user groups, one to hack the system and the other group to bring in
representative "constituencies" such as homeless shelters, K-12, reference
librarians, etc.  Serve as a "advocate" for users and  promote ease and
convenience of use.

Ways and Means:  Coordinates fund-raising.  Collects budgets and task
timelines from each of the committees to develop a master budget and project
timeline for the whole effort.  Works with committees in helping to seek
particular funding for committee assignments.

Policies and Procedures:  Evaluates administrative policy and develops
procedures.  Reviews sysop and online system administrative policy from
other systems, identifies issues, organizes meetings to review policy issues
and formulate recommendations.

Governance:  Composes and recommends articles of incorporation, bylaws,
responsible for creating governance structure and proposing membership
"lines of interest" which will be used to determine categories of
representation on the Membership Council, the primary governing body below
the Board of Directors, half of whom are drawn from the Council.

Public Relations:  logo, letterhead, puts out a little newsletter 10 days
after each membership meeting, plans system "innauguration" when it goes
public, coordinates closely with Ways and Means.

Technical Advisory Committee:  Oversees system operation, acts as liason
between George Wash. Univ. computer center and CapAccess.  Develops
functional requirements specifications.  Evaluates the software, looks at
development needs and options.

Steering Committee:  The provisional board of directors.  Comprised of two
representatives from each standing committee.  Oversees general direction of
the CapAccess project.


Richard Civille



From cruzio.santa-cruz.ca.us!chris Mon Aug 24 21:39:43 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "24" "August" "1992" "21:19:39" "-0700" "the piano has been drinking" "chris@cruzio.santa-cruz.ca.us " nil "35" "Note about MUDs and Chat" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 24 Aug 1992 21:39:37 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11713>; Mon, 24 Aug 1992 21:39:25 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11674>; Mon, 24 Aug 1992 21:32:52 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58378>; Mon, 24 Aug 1992 21:32:26 -0700
Received: from netcomsv.netcom.com ([192.100.81.101]) by alpha.xerox.com with SMTP id <11674>; Mon, 24 Aug 1992 21:32:04 PDT
Received: from cruzio.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1)
	id AA15096; Mon, 24 Aug 92 21:30:59 PDT
Received: by cruzio.santa-cruz.ca.us (smail2.5)
	id AA13218; 24 Aug 92 21:19:39 PDT (Mon)
X-Mailer: ELM [version 2.3 PL0]
X-NS-Transport-ID: 08002008D0FD00224BC8
Message-ID: <9208242119.AA13218@cruzio.santa-cruz.ca.us>
Date:	Mon, 24 Aug 1992 21:19:39 -0700
From:	chris@cruzio.santa-cruz.ca.us (the piano has been drinking)
To:	community-access@cruzio.santa-cruz.ca.us
Subject: Note about MUDs and Chat

This is just a note that we installed a MUD on Cruzio a couple of
weeks ago, and some impressions on MUDs and Chatting for community
access systems.

One thing Carl noted about the DIAC conference was that Chat was
sort of looked down upon, or seen as somehow "less serious" or
"less useful" for community networking systems.

MUD stands for "Multi-User Dimension", and was the subject of at least
one DIAC talk. A MUD is essentially a text based virtual reality 
implemented  around a map topology database and a form of extended Chat.
Users navigate through rooms, manipulate objects and can intereract
with other users.

Well, one of the things I did with our MUD right away was create a
basic topology consisting of some rooms inside a social club. One
of the rooms is the sysop's office, and I keep regular "office hours"
where folks can "drop in" for help or to shoot the breeze. So far,
without exception, every single time someone drops in we have a blast
conversing, messing around with objects in the MUD and otherwise
interacting in a way that is totally unlike anything I have ever
experienced in my zillions of years as a net dino using email and
Bnews.

Count this as a hearty thumbs up for Chat and MUDs in community networks.
More info about MUDs can be found in the rec.games.mud.misc newsgroup on
USENET, where MUD FAQ files are posted once a month. These FAQs are an
excellent introduction to MUDs for those who wonder what the heck they are.

chris
-- 
		"If life were easy, everybody'd want to do it."
		       -Knuckle Buckalo

	             chris@cruzio.santa-cruz.ca.us

From access.digex.com!hecker Mon Aug 31 10:51:46 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "30" "August" "1992" "18:03:59" "-0700" "Frank Hecker" "hecker@access.digex.com" nil "64" "Re: Note about MUDs and Chat" "^Date:" nil nil "8"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Mon, 31 Aug 1992 10:51:43 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12439>; Mon, 31 Aug 1992 10:33:41 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <13399>; Sun, 30 Aug 1992 19:31:47 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 30 Aug 1992 19:31:23 -0700
Received: from relay2.UU.NET ([137.39.1.7]) by alpha.xerox.com with SMTP id <13235>; Sun, 30 Aug 1992 18:04:22 PDT
Received: from access.digex.com (via uunet.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA04172; Sun, 30 Aug 92 21:04:15 -0400
Received: by access.digex.com id AA19924
  (5.65b/IDA-1.4.3 for community-access@parc.xerox.com); Sun, 30 Aug 92 21:04:03 -0400
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002B5CAB
In-Reply-to: "<9208242119.AA13218@cruzio.santa-cruz.ca.us>; from \"the piano has been drinking\" at Aug 24, 92 9:19 pm"
Message-ID: <9208310104.AA19924@access.digex.com>
Date:	Sun, 30 Aug 1992 18:03:59 -0700
From:	Frank Hecker <hecker@access.digex.com>
To:	community-access@parc.xerox.com
Subject: Re: Note about MUDs and Chat

chris@cruzio.santa-cruz.ca.us (the piano has been drinking) writes:
> This is just a note that we installed a MUD on Cruzio a couple of
> weeks ago, and some impressions on MUDs and Chatting for community
> access systems.

I'm glad to see this come up as a topic.  One of the reasons I
subscribed to the community-access and social-vr mailing lists was to
discuss new technologies that might be appropriate for community
access systems, beyond traditional mechanisms like email, passive
information files, online databases, and conferencing.

> One thing Carl noted about the DIAC conference was that Chat was
> sort of looked down upon, or seen as somehow "less serious" or
> "less useful" for community networking systems.

And not just for community systems, I might add.  Richard Bartle,
"father of MUD," seems to be quite put out by the thought of chat
intruding into the world of MUDs (which are really supposed to be
games, don't you know).

> [MUD defined, and description of positive effects of MUD being used
> as social club area in community system]

Chat is obviously the first service you can imagine being provided by
a MUD in a community access system, and I agree that it can be a
useful one.  In particular, I would guess that it would increase
people's sense of participation in the system and to some degree lower
the "barrier to entry" for those who are not computer experts,
somewhat analogous to the role CB radio played vis-a-vis traditional
amateur radio.  (Of course, some might not find that to be a
flattering comparison :-)

I think a second possible use for MUDs in community access system is
as a way to offer online assistance in using the system, provided by a
real person rather than by a "help system."  After all, in a MUD the
helper can converse directly with a user, see their actions, see the
virtual space they share, and offer immediate feedback in the event of
problems.

Of course, taking full advantage of this requires that the "MUDness"
be extended outside a special area into the entire system, so that
rather than interacting with traditional menus, mail systems, and so
on, the users interact with each other and with spaces and objects
that subsume the functions of the current system services.

Whether this can be done successfully in a real working system (with a
real-world budget!) is to me one of the most interesting challenges
for those designing, building, and operating community access systems.

> Count this as a hearty thumbs up for Chat and MUDs in community networks.
> More info about MUDs can be found in the rec.games.mud.misc newsgroup on
> USENET, where MUD FAQ files are posted once a month. These FAQs are an
> excellent introduction to MUDs for those who wonder what the heck they are.

I would recommend that people also take a look at the papers that
Pavel Curtis has put online for anonymous FTP at parcftp.xerox.com in
pub/MOO/papers (I believe), including his DIAC paper, Bartle's MUD
survey paper, and Elizabeth Reid's paper on Internet Relay Chat.

Frank

-- 
Frank Hecker
hecker@access.digex.com

From igc.apc.org!commem!carl Tue Sep  1 09:13:27 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "1" "September" "1992" "00:05:32" "-0700" "carl%commem@igc.apc.org" "carl%commem@igc.apc.org" nil "11" "MUDs, etc." "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Tue, 1 Sep 1992 09:13:23 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11703>; Tue, 1 Sep 1992 09:12:18 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11702>; Tue, 1 Sep 1992 09:10:30 PDT
Received: by lambda.parc.xerox.com via suspension id <58373>; Tue, 1 Sep 1992 09:10:08 -0700
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 1 Sep 1992 00:04:12 -0700
Received: from cdp.igc.org ([192.82.108.1]) by alpha.xerox.com with SMTP id <11664>; Tue, 1 Sep 1992 00:03:43 PDT
Received: by igc.apc.org (4.1/Revision: 1.22 )
	id AA05011; Tue, 1 Sep 92 00:05:32 PDT
X-NS-Transport-ID: 08002008D0FD002BA001
Message-ID: <9209010705.AA05011@igc.apc.org>
Date:	Tue, 1 Sep 1992 00:05:32 -0700
From:	carl%commem@igc.apc.org
To:	community-access@parc.xerox.com
Subject: MUDs, etc.

Regarding the recent postings about MUDs:  I'm the first to admit my lack of
experience in the subject, but to me it seems like MUDs basically ARE chat,
with some geographical structure to them.  I've heard references to the
ability to construct objects, but no concrete examples of what objects have
actually been constructed.  If such objects are at all easy to manage, why
can't MUDs subsume other computer-assisted communications functions (e-mail,
database, etc.)?  Are there examples of systems that do this?
I hope my tone doesn't come off as hostile.  I like the idea of MUDs as an
overall architecture for computer communication.  I'd just like to know of
some applications of the idea.


From cruzio.santa-cruz.ca.us!chris Tue Sep  1 17:22:18 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "1" "September" "1992" "13:23:17" "-0700" "the piano has been drinking" "chris@cruzio.santa-cruz.ca.us " nil "79" "Re: MUDs, etc." "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Tue, 1 Sep 1992 17:22:07 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11789>; Tue, 1 Sep 1992 17:21:36 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11762>; Tue, 1 Sep 1992 17:20:24 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 1 Sep 1992 17:19:46 -0700
Received: from cdp.igc.org ([192.82.108.1]) by alpha.xerox.com with SMTP id <11762>; Tue, 1 Sep 1992 17:19:12 PDT
Received: from netcomsv.netcom.com by igc.apc.org (4.1/Revision: 1.22 )
	id AA23460; Tue, 1 Sep 92 17:20:55 PDT
Received: from cruzio.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1)
	id AA25335; Tue, 1 Sep 92 17:18:33 PDT
Received: by cruzio.santa-cruz.ca.us (smail2.5)
	id AA05158; 1 Sep 92 13:23:18 PDT (Tue)
X-Mailer: ELM [version 2.3 PL0]
X-NS-Transport-ID: 08002008D0FD002BAA74
In-Reply-to: "<9209010705.AA05011@igc.apc.org>; from \"igc.apc.org!carl@commem\" at Sep 1, 92 12:05 am basical"
Message-ID: <9209011323.AA05158@cruzio.santa-cruz.ca.us>
Date:	Tue, 1 Sep 1992 13:23:17 -0700
From:	chris@cruzio.santa-cruz.ca.us (the piano has been drinking)
To:	carl%commem@netcom.com
cc:	parc.xerox.com!community-access@netcom.com
Subject: Re: MUDs, etc.

> 
> Regarding the recent postings about MUDs:  I'm the first to admit my lack of
> experience in the subject, but to me it seems like MUDs basically ARE chat,
> with some geographical structure to them.  

This is basically true about the _implementation_ of MUD systems. Very
basic, wrap a growable database around chat.

The thing that makes MUDs stand out IMO is their _usage_ by users, who
infuse the system and their environments with their personalities. I
don't know of any other shell environment, from /bin/sh to any X desktop
I've ever seen which so accomodates the user.

> I've heard references to the
> ability to construct objects, but no concrete examples of what objects have
> actually been constructed.  

Well, how about an object called "change purse", which a user uses to
carry "coin" objects. The change purse can have a physical description,
a function (to act as a container for coin objects) and certain actions
associated with it ('remove' as in "remove a nickle from the change purse").
(necessary in TinyMUCK, which doesn't have built in interfaces for handling
containers very well...)

Another example is one I am working on right now, which I call a "silly 
bomb". The silly bomb looks like a hand grenade. There is a "pin" to pull
to prime the bomb, there is a "fuse" which ticks off the seconds till the
bomb "explodes". When the fuse activates, the silly bomb goes off. What 
the silly explosion does is go through and twiddle the descriptions of
all players and objects in the room exposed to the "blast". For instance,
a person carrying a flashlight will discover they are now carrying a
banana. A person whose description of themselves says, "Blah blah is
about 6 feet tall, male, wearing blue jeans and an old long sleeve shirt
rolled up at the sleeves" will now appear to the others in the room as
"a somewhat dazed gerbil like creature with pink stripes down the length of
the body."

These are rather frivolous examples, but the intent of objects is that
anything that can exist in RL can also be modeled in VR. (although one
never reads about "silly bombs" going off in Lebanon...

> If such objects are at all easy to manage, why
> can't MUDs subsume other computer-assisted communications functions (e-mail,
> database, etc.)?  

They can. And they will.

> Are there examples of systems that do this?

Yes. I already described a MUF/TinyMU* implementation of a full blown
BBS and e-mail system inside the MUD. I would actually implement it
differently myself, and create new kinds of MU* commands specifically
meant to interface with RFC822 documents in mail or news spool files,
but such things will come to pass sooner or later.

> I hope my tone doesn't come off as hostile.  I like the idea of MUDs as an
> overall architecture for computer communication.  I'd just like to know of
> some applications of the idea.
> 

Not hostile at all. Basically, we are all in the job of networking
people. MUDs are able to model 3D RL and able to provide a user
environment which some users, particularly the newbies our system (cruzio)
is trying to reach out to, seem to find less threatening and easier to
utilize than something like A> C> or $ or # or % or tcl> or whatever
else, including menus (believe it or not..).

Aside from all that, there is something else, the ability to create
and move and sing and dance and smile and look funny and be oneself, 
which really attracts folks to MUDs as communications interfaces.  
And that's what this is all about.

ccn

-- 
		"If life were easy, everybody'd want to do it."
		       -Knuckle Buckalo

	             chris@cruzio.santa-cruz.ca.us

From cruzio.santa-cruz.ca.us!chris Sun Sep  6 10:09:35 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "6" "September" "1992" "09:55:20" "-0700" "the piano has been drinking" "chris@cruzio.santa-cruz.ca.us " nil "71" "Re: MUDs, etc." "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 6 Sep 1992 10:09:28 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11870>; Sun, 6 Sep 1992 10:09:17 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11869>; Sun, 6 Sep 1992 10:08:29 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 6 Sep 1992 10:05:36 -0700
Received: from cdp.igc.org ([192.82.108.1]) by alpha.xerox.com with SMTP id <11854>; Sun, 6 Sep 1992 10:05:12 PDT
Received: from netcomsv.netcom.com (uucp2.netcom.com) by igc.apc.org (4.1/Revision: 1.23 )
	id AA13175; Sun, 6 Sep 92 10:06:56 PDT
Received: from cruzio.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1)
	id AA07861; Sun, 6 Sep 92 10:03:41 PDT
Received: by cruzio.santa-cruz.ca.us (smail2.5)
	id AA02977; 6 Sep 92 09:55:21 PDT (Sun)
X-Mailer: ELM [version 2.3 PL0]
X-NS-Transport-ID: 08002008D0FD002BF113
In-Reply-to: "<9209010705.AA05011@igc.apc.org>; from \"igc.apc.org!carl@commem\" at Sep 1, 92 12:05 am"
Message-ID: <9209060955.AA02977@cruzio.santa-cruz.ca.us>
Date:	Sun, 6 Sep 1992 09:55:20 -0700
From:	chris@cruzio.santa-cruz.ca.us (the piano has been drinking)
To:	carl%commem@netcom.com
cc:	parc.xerox.com!community-access@netcom.com
Subject: Re: MUDs, etc.

> In response (again) to Carl's ponderings...
> Regarding the recent postings about MUDs:  

More on MUDs, and specific examples of how they can be used for community
access systems for computer aided human <-> human networking...

The ability to specify actions (also called "exits", i.e. an exit 
takes you from one room to another) is the same as the ability to
create menu hierarchies. For instance, the same capability in describing 
a room as so:

The Lobby Of Club MUD
+
You are standing in the lobby of Club MUD. There is an open door to the
west leading to the Sysop's Office, a door to the south which goes into 
the Library, and a sliding glass door to the east leading out to the garden.
+

Can also create a menu interface as so:

Main Menu

(s)ysop
(l)ibrary
(g)arden

Enter your choice or (h)elp:


In looking through quite a bit of the TinyMU* strain of MUD code, it
appears that the MUD server is basically a socket and database manager.
Therefore, with a small amount of effort (if it hasn't already been
done) it would be possible to extend the @commands to provide a generic
@exec capability, or, maybe better, to create a certain kind of object
for external processes, i.e. mail or rn, and provide a way to link an
exit to it. Thus, the interface would be completely moldable using standard 
MUD commands to either a common MUD interface (what we used to call the
"Adventure Shell" at SCO, i.e. "throw file at printer") _or_ a menu interface
as shown above.

Those who have used the conferencing software called "Caucus" are 
familiar with this concept, as the Caucus software provides a message and
conferencing engine with an excellent capability to mold the user inteface
in much the same way, albeit not dynamically as a MUD does. (and not as
RFC822 networkable as one would want without the Pandora extensions...)

Connecting sockets to external processes is sort of a kludge, because the
MUD can't really be said to subsume the extra services. For instance,
I as sysop would not be able to "follow" someone into mail and "watch"
them as they "show" me some problem they are having with the mail engine
or interface, "conversing" with them or "coaching" them as we cooperate
in solving the problem. Since our system is actively trying to bring more
"clueless newbies" onto the Internet, and I as an individual have to 
work a day job and help raise a child, this kind of approach to "outreach"
is very valuable. I can "meet" the user, "converse" with them, "show" them
how to do things, then "look over their shoulder" as they get the hang of
it, without leaving the kitchen at home where I am looking over my 5 month
old. In our MUD, I am able to do this. So far, I've had some folks stumble
into my "office" during "office hours" and have been able to "coach" them
in ways far superiour to the normal e-mail or even voice over phone 
communication (remembering that most folks only have one phone line at
home, so can't modem in and have a voice conversation at the same time).

All the "" above is meant to signify where real world abstractions are 
modeled by the MUD.

So, just more blather about using MUDs as platforms for community access
systems. I really do think they are the neatest thing since cheap RAM,
of which they seem to require a lot...

ccn

From access.digex.com!hecker Mon Sep  7 12:33:56 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "7" "September" "1992" "12:30:23" "-0700" "Frank Hecker" "hecker@access.digex.com" nil "114" "Re: MUDs, etc." "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 7 Sep 1992 12:33:49 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11587>; Mon, 7 Sep 1992 12:33:23 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11553>; Mon, 7 Sep 1992 12:32:46 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 7 Sep 1992 12:32:14 -0700
Received: from relay2.UU.NET ([137.39.1.7]) by alpha.xerox.com with SMTP id <11537>; Mon, 7 Sep 1992 12:31:47 PDT
Received: from access.digex.com (via uunet.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA05103; Mon, 7 Sep 92 15:30:47 -0400
Received: by access.digex.com id AA04247
  (5.65b/IDA-1.4.3 for community-access@parc.xerox.com); Mon, 7 Sep 92 15:30:25 -0400
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002BFA1C
In-Reply-to: "<9209060955.AA02977@cruzio.santa-cruz.ca.us>; from \"the piano has been drinking\" at Sep 6, 92 9:55 ami"
Message-ID: <9209071930.AA04247@access.digex.com>
Date:	Mon, 7 Sep 1992 12:30:23 -0700
From:	Frank Hecker <hecker@access.digex.com>
To:	chris@cruzio.santa-cruz.ca.us (the piano has been drinking)
cc:	community-access@parc.xerox.com
Subject: Re: MUDs, etc.

chris@cruzio.santa-cruz.ca.us (the piano has been drinking) writes:
> The ability to specify actions (also called "exits", i.e. an exit 
> takes you from one room to another) is the same as the ability to
> create menu hierarchies. For instance, the same capability in describing 
> a room as so:
> 
> The Lobby Of Club MUD
> +
> You are standing in the lobby of Club MUD...
> 
> can also create a menu interface as so:
> 
> Main Menu
> 
> (s)ysop
> (l)ibrary
> (g)arden
> 
> Enter your choice or (h)elp:

This is an excellent point, and deserves further expansion.  Suppose
we start with a conventional menu-oriented public access system like
the FreePort software used in the Cleveland Freenet.  We then emulate
this menu structure in a MUD as described above.  (In fact, Cleveland
Freenet already attempts to provide a surface impression that it is
based on a geographic structure, so this is not as big a jump as it
might be.)

What have we gained thereby in terms of new functions?  At a minimum,
the ability of users to detect the presence of others when they are in
the same area (e.g., in the "library" system) and the ability of users
to converse with each other in a natural way, thus allowing a basic
chat capability between users whose presence in the common area would
indicate they might have something to talk about.

Going further, you could create new areas/menus using the MUD
facilities, although actually creating new functions would require
both MUD programming and a way of accessing the "outside world" as
discussed below.

> In looking through quite a bit of the TinyMU* strain of MUD code, it
> appears that the MUD server is basically a socket and database manager.
> Therefore, with a small amount of effort (if it hasn't already been
> done) it would be possible to extend the @commands to provide a generic
> @exec capability, or, maybe better, to create a certain kind of object
> for external processes, i.e. mail or rn, and provide a way to link an
> exit to it. Thus, the interface would be completely moldable using standard 
> MUD commands to either a common MUD interface (what we used to call the
> "Adventure Shell" at SCO, i.e. "throw file at printer") _or_ a menu interface
> as shown above.

I am a little confused by exactly what you are proposing here.  It is
true that a simple @exec capability would allow a non-MUD _non-
interactive_ command to be seen as a MUD command; e.g., "throw file at
printer" might map to "pr file | lp" for a UNIX system.  However as
you note below, this would not solve the more general problem of
providing a full MUD interface to an interactive program such as mail
or rn; you could enter into the program in a MUD-like way, but once
into it you would be thrown back into the native command structure,
and moreover would lose the MUD chat capability.

> Connecting sockets to external processes is sort of a kludge, because the
> MUD can't really be said to subsume the extra services. For instance,
> I as sysop would not be able to "follow" someone into mail and "watch"
> them as they "show" me some problem they are having with the mail engine
> or interface, "conversing" with them or "coaching" them as we cooperate
> in solving the problem.

There is at least a theoretical way to do what you want to do here.
What you would do is have the interactive program run in an external
process, and then create an intermediate program which "talks" to the
interactive program as if it were a "real" interactive user.  (Public
domain code to do this in a general way is available in the expect
software created by Don Libes of NIST.  This is similar to the Remote
Terminal Emulators many computer vendors use for benchmarks.)

This intermediate program would accept MUD commands and translate them
into the appropriate commands for the interactive program, so that the
user would never see the underlying command set; it would also
translate output into MUD terms.  In effect it would put a MUD object
layer over the program, with MUD chat and related capabilities still
available.

Of course, whether this scheme is actually practical in real life is
an open question.  The mapping may prove to be so difficult that it
may be easier to provide a true MUD-based implementation of the
function. 

> Since our system is actively trying to bring more
> "clueless newbies" onto the Internet, and I as an individual have to 
> work a day job and help raise a child, this kind of approach to "outreach"
> is very valuable. I can "meet" the user, "converse" with them, "show" them
> how to do things, then "look over their shoulder" as they get the hang of
> it, without leaving the kitchen at home where I am looking over my 5 month
> old. In our MUD, I am able to do this. So far, I've had some folks stumble
> into my "office" during "office hours" and have been able to "coach" them
> in ways far superiour to the normal e-mail or even voice over phone 
> communication (remembering that most folks only have one phone line at
> home, so can't modem in and have a voice conversation at the same time).

Exactly.  I would add that in theory one user could help another
rather than a sysop helping a user.  However, since this depends on
the one user being able to note another user's actions and whereabouts
in the system, there are significant privacy issues that arise.  One
compromise would be to only allow sysops to "eavesdrop" in this way,
and only at the user's invitation.  Another would be to allow
unrestricted interaction in social areas and limited or no interaction
in other areas.

Frank

-- 
Frank Hecker
hecker@access.digex.com

From access.digex.com!hecker Mon Sep  7 12:35:07 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "7" "September" "1992" "11:24:17" "-0700" "Frank Hecker" "hecker@access.digex.com" nil "45" "Re: Note about MUDs and Chat" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 7 Sep 1992 12:35:05 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11580>; Mon, 7 Sep 1992 12:34:43 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11537>; Mon, 7 Sep 1992 12:33:55 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 7 Sep 1992 12:33:36 -0700
Received: from relay2.UU.NET ([137.39.1.7]) by alpha.xerox.com with SMTP id <11580>; Mon, 7 Sep 1992 12:32:53 PDT
Received: from access.digex.com (via uunet.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA05319; Mon, 7 Sep 92 15:32:51 -0400
Received: by access.digex.com id AA02753
  (5.65b/IDA-1.4.3 for community-access@parc.xerox.com); Mon, 7 Sep 92 14:24:18 -0400
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002BFA1F
In-Reply-to: "<9208310857.AA25734@cruzio.santa-cruz.ca.us>; from \"the piano has been drinking\" at Aug 31, 92 8:57 amthe hang"
Message-ID: <9209071824.AA02753@access.digex.com>
Date:	Mon, 7 Sep 1992 11:24:17 -0700
From:	Frank Hecker <hecker@access.digex.com>
To:	chris@cruzio.santa-cruz.ca.us (the piano has been drinking)
cc:	community-access@parc.xerox.com
Subject: Re: Note about MUDs and Chat

[Pardon my delay in replying to this; I've been away on business.]

chris@cruzio.santa-cruz.ca.us (the piano has been drinking) writes:
> There are some moves toward bringing more services "inside the MUD",
> and using it as the total online environment shell. I am running
> TinyMUCK, which supports an internal programming language called
> 'MUF' for Multi User Forth (erg...). Whilst poking around the Internet
> looking for MUF archive sites, I found a huge implementation of an
> e-mail system and BBS in MUF.

I have been playing around with a version of LambdaMOO that Pavel
Curtis of Xerox PARC put out.  It has a minimal integrated email
facility, but nothing fancy.  Is the MUF-based email/bbs system well
integrated into the MUD virtuality, or is it basically a bolt-on
(i.e., you invoke it as a command, go into a totally different mode,
and then return to full MUD functionality only on exit)?

> There are also developments in graphic
> MUDs which look promising, so krusty folks like me can have the menus
> and accelerators we need and not have to resort to natural language,
> which can be very cumbersome when interfacing with a computer (as 
> opposed to interfacing with a human).

I'm curious as to which developments you're referring.  The book
_Cyberspace_ (edited by Michael Benedikt) has a good paper on the
Lucasfilm Habitat project, which is a MUD-like commercial system
intended for entertainment.  The Habitat system uses Commodore-64s as
graphical front-ends, with the graphics information being generated on
the C-64s are opposed to being downloaded from the host on each screen
(e.g., as does Prodigy), thus in theory allowing a range of graphical
interfaces depending on the capabilities of the front-end system.

> I have been getting some email from a couple of people who are interested
> in MUDs for educational purposes. Is there anyone out there who can
> point to any existing MUDs existing in classrooms or schools?
> Any papers written on the subject?

None that I've seen.  The paper mentioned above and the papers I noted
in my original posting are the only MUD-related papers I've found.

Frank

-- 
Frank Hecker
hecker@access.digex.com

From cruzio.santa-cruz.ca.us!chris Mon Sep  7 16:18:21 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "7" "September" "1992" "13:35:46" "-0700" "the piano has been drinking" "chris@cruzio.santa-cruz.ca.us " nil "47" "Re: MUDs, etc." "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 7 Sep 1992 16:18:15 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11729>; Mon, 7 Sep 1992 16:17:59 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11556>; Mon, 7 Sep 1992 16:17:10 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 7 Sep 1992 16:16:32 -0700
Received: from relay2.UU.NET ([137.39.1.7]) by alpha.xerox.com with SMTP id <11556>; Mon, 7 Sep 1992 16:16:10 PDT
Received: from access.digex.com (via uunet.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA03327; Mon, 7 Sep 92 19:16:04 -0400
Received: from uucp2.netcom.com by access.digex.com with SMTP id AA21250
  (5.65b/IDA-1.4.3 for community-access@parc.xerox.com); Mon, 7 Sep 92 19:15:34 -0400
Received: from cruzio.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1)
	id AA27428; Mon, 7 Sep 92 16:14:12 PDT
Received: by cruzio.santa-cruz.ca.us (smail2.5)
	id AA11726; 7 Sep 92 13:35:46 PDT (Mon)
X-Mailer: ELM [version 2.3 PL0]
X-NS-Transport-ID: 08002008D0FD002BFC45
In-Reply-to: "<9209071930.AA04247@access.digex.com>; from \"Frank Hecker\" at Sep 7, 92 12:30 pm NewZM"
Message-ID: <9209071335.AA11726@cruzio.santa-cruz.ca.us>
Date:	Mon, 7 Sep 1992 13:35:46 -0700
From:	chris@cruzio.santa-cruz.ca.us (the piano has been drinking)
To:	hecker@access.digex.com (Frank Hecker)
cc:	community-access@parc.xerox.com
Subject: Re: MUDs, etc.

> 
> There is at least a theoretical way to do what you want to do here.
> What you would do is have the interactive program run in an external
> process, and then create an intermediate program which "talks" to the
> interactive program as if it were a "real" interactive user.  (Public
> domain code to do this in a general way is available in the expect
> software created by Don Libes of NIST.  This is similar to the Remote
> Terminal Emulators many computer vendors use for benchmarks.)
> 
> This intermediate program would accept MUD commands and translate them
> into the appropriate commands for the interactive program, so that the
> user would never see the underlying command set; it would also
> translate output into MUD terms.  In effect it would put a MUD object
> layer over the program, with MUD chat and related capabilities still
> available.
> 
> Of course, whether this scheme is actually practical in real life is
> an open question.  The mapping may prove to be so difficult that it
> may be easier to provide a true MUD-based implementation of the
> function. 

I think I found a way to do this.
There are several MUD source code depositories on the Internet, and
I just got back from a jack with some code for MUD robots. One of the
ideas I had was for a robot I call the "weather god" which would connect
to a MUD as a player with wizard/god privs, and just keep watch of the 
time. At certain specific times, it would then race through the MUD 
database changing the descriptions of things relative to the "weather",
i.e. position of sun or moon, is it raining, etc.

An extension of this would be a "mail god" or "news god" which would
monitor user MUD commands in the "post office" or at the "news stand",
and go out to the correct mail and spool files and programs in the way 
you describe above. 

Thus, the robot would supply the MUD like interface to both the MUD
server and the user it would be interacting with, and have a backend
which manages the mail and news files.

Since the user is in a "room" during the entire transaction, they
can chat with others during the entire time, as they are composing
and addressing or reading and browsing news and mail.

Eh?


ccn

From access.digex.com!hecker Mon Sep  7 17:00:53 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "7" "September" "1992" "16:58:01" "-0700" "Frank Hecker" "hecker@access.digex.com" nil "58" "Thoughts on Community Access Systems, Preface" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 7 Sep 1992 17:00:47 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11556>; Mon, 7 Sep 1992 17:00:27 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11729>; Mon, 7 Sep 1992 16:59:13 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 7 Sep 1992 16:59:00 -0700
Received: from relay2.UU.NET ([137.39.1.7]) by alpha.xerox.com with SMTP id <11729>; Mon, 7 Sep 1992 16:58:33 PDT
Received: from access.digex.com (via uunet.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA07482; Mon, 7 Sep 92 19:58:25 -0400
Received: by access.digex.com id AA23622
  (5.65b/IDA-1.4.3 for community-access@parc.xerox.com); Mon, 7 Sep 92 19:58:02 -0400
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002BFC7D
Message-ID: <9209072358.AA23622@access.digex.com>
Date:	Mon, 7 Sep 1992 16:58:01 -0700
From:	Frank Hecker <hecker@access.digex.com>
To:	community-access@parc.xerox.com
Subject: Thoughts on Community Access Systems, Preface

This begins a series of postings I'll be making to the community
access mailing list, and before I start filling up your mailboxes I
wanted to take a moment to briefly introduce myself and explain what
I'm doing here.

I'm a computer professional and have recently begun volunteering to
help with the CapAccess community access system being developed for
the Washington, D.C., area; in particular, I'm a member of the
technical advisory committee concerned with the specific hardware and
software used to build the system now and in the future.

In doing this I've been seized by a sense of frustration over the
long-term task ahead of us.  On the one hand, I want to help provide
broader public access to the types of facilities it's been my
privilege to be able to use: electronic mail, conferencing systems,
remote services and databases, and so on.  On the other hand I feel
that the types of systems I've used are a pale shadow of what they
could be, and to some degree it pains me to offer them to the general
public in their current state of development.

I've read a lot about the benefits that will flow from public access
to computing resources, and a lot about the wonderful technology that
will make it all happen now and in the future.  However I've read very
little that is truly helpful as to how to actually design and build a
real system that addresses the real needs and desires of those who use
it.

For now at CapAccess we are muddling through using the software and
hardware we have at hand.  In the future I would like for us to do
better, and I believe that we can do better.  To that end as a
personal project I am trying to come up with a vision of what
CapAccess could be in the future, together with a workable plan on how
we might get there--in effect, a design for a next-generation
community access system.  Even though our limited resources may
prevent us from ever building such a system ourselves, I believe that
having a well-thought-out design will help guide us in enhancing or
replacing our initial system, and may even serve as an inspiration to
others designing and building their own systems.

Of course my abilities alone are inadequate for this task, but I want
to at least get it started.  Therefore I'm inviting you to comment and
contribute to the documents I'm writing, if you have an interest in
doing so.  I'm going to try and work from first principles, starting
with the goals of a community access system, the various people who
might use it, and what specific tasks they might wish to use it for.
I'll also try to lay out all my assumptions for public view, to be
agreed with or argued with as you please.

Immediately after this message I'll send out the first section, on
goals, with further sections to follow as I complete initial drafts.

Thanks in advance for any comments and contributions.

Frank

-- 
Frank Hecker
hecker@access.digex.com

From access.digex.com!hecker Mon Sep  7 17:10:04 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "7" "September" "1992" "17:07:15" "-0700" "Frank Hecker" "hecker@access.digex.com" nil "102" "Thoughts on Community Access Systems, Part 1: Goals" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 7 Sep 1992 17:10:03 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11556>; Mon, 7 Sep 1992 17:09:50 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11636>; Mon, 7 Sep 1992 17:09:14 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 7 Sep 1992 17:08:54 -0700
Received: from relay1.UU.NET ([137.39.1.5]) by alpha.xerox.com with SMTP id <11636>; Mon, 7 Sep 1992 17:08:41 PDT
Received: from access.digex.com (via uunet.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA05785; Mon, 7 Sep 92 20:07:56 -0400
Received: by access.digex.com id AA25292
  (5.65b/IDA-1.4.3 for community-access@parc.xerox.com); Mon, 7 Sep 92 20:07:19 -0400
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002BFC85
Message-ID: <9209080007.AA25292@access.digex.com>
Date:	Mon, 7 Sep 1992 17:07:15 -0700
From:	Frank Hecker <hecker@access.digex.com>
To:	community-access@parc.xerox.com
Subject: Thoughts on Community Access Systems, Part 1: Goals

This is the first in a series of brief informal papers outlining my
thoughts on the proper goals, functions, and design of community
access computer systems.  Although I am a member of the technical
advisory committee of one such (nascent) system, the National Capital
Area Public Access Network (CapAccess), these papers represent only my
personal opinions and do not represent official positions of
CapAccess.

As a prelude to the other papers, I want to briefly discuss the
appropriate goals of a community access system and how those goals
should constrain the tasks that a community access system sets for
itself.

I believe that the primary goal of a community access computer system
should be to help people more fully and positively participate in the
public life of their community, including (for example) the activities
of government, educational institutions, and voluntary associations.
In the CapAccess statement of principles this goal is embodied in the
commitments to "provide open access to public and civic information to
anyone in the community" and to "promote community awareness of and
involvement in public issues and programs."

Other secondary goals follow immediately from this primary goal.  For
example, since a community consists of all the people living in it,
the creators of a system should strive to make it as accessible as
possible to anyone in the community who wishes to use it, e.g., by
minimizing the cost to access the system, maximizing the availability
of access points, and accomodating access by people with varying
technical expertise or physical abilities.

As another example, since the system is to promote public life, its
structure and operation should respect the legally established and
commonly accepted rights of its users, including the rights of free
speech and personal privacy.  Turning from rights to responsibilities,
the system should provide encouragement to and opportunities for its
users to give of themselves through volunteer activities both within
and without the context of the system itself.

The above goals are not novel; they can be found in the statements of
principles of many community access systems.  On the other hand, I
believe that some goals proposed for community access systems, while
desirable, are not necessarily directly relevant to the primary goal
of promoting public life in the community, and are of lesser
importance than the secondary goals above.

For example, I do not believe that promoting the knowledge and use of
computer technology should necessarily be a primary goal of community
access systems.  Basic knowledge of computer use stands in relation to
a community access system as literacy does to a public library: a
means to derive the benefits thereof, and not an end in itself.
Community access systems should be directed to the common citizen and
not computer aficianados (professional or amateur), just as public
libraries are established primarily to benefit the "common reader" as
opposed to writers, editors, and publishers.

In a related example, projects such as the National Research and
Education Network (NREN) have been promoted as potentially benefiting
the U.S. economy by upgrading the "high-tech" skills of workers and
encouraging new ventures by U.S. corporations.  Again, while this may
be an indirect benefit of having a community access system, I do not
believe it should be a primary goal.  As one consequence it should not
be a integral purpose of such a system either to serve or compete with
private companies; commercial involvement is appropriate only to the
extent that it serves the community as a whole.

Finally, many people have promoted the ability of public access
systems to create worldwide "virtual communities" of people physically
separated but united by common interests.  Whether one believes that
this is a desirable trend or not (and there are cogent arguments for
either position), I believe that the first priority of a community
access system should be to serve its local community.

It is true that a community access system will often make use of
resources made freely available to it by other systems, and in fact
providing local access to these resources can be an important function
of the system.  As a consequence I believe that a community access
system does have a responsibility to "return the favor" and make a
contribution to the larger world outside the local community.

However, we can distinguish between access to the system's facilities
and access to the information contained within the system.  Access to
the information should be as unrestricted as possible, and can be
provided by, for example, supplying the information to organizations
or services which will redistribute it.  (Real-life examples include
the Usenet network or the National Public Telecomputing Network.)

On the other hand, the system's facilities (e.g., hardware and
communications links) are limited resources, and it is appropriate to
restrict access to them.  (In Garrett Hardin's terminology they would
be "socialized" rather than "commonized.")  Thus, for example, local
citizens should be given preference in accessing the system over
others not in the area.

Given the goals described above, the next papers in this series will
consider what types of people might use a community access system and
what specific tasks they might want to use it for.

Frank

-- 
Frank Hecker
hecker@access.digex.com

From access.digex.com!hecker Tue Sep  8 19:51:55 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Tue" "8" "September" "1992" "18:46:27" "-0700" "Frank Hecker" "hecker@access.digex.com" nil "47" "Re: MUDs, etc." "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Tue, 8 Sep 1992 19:51:52 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12223>; Tue, 8 Sep 1992 19:51:08 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12216>; Tue, 8 Sep 1992 19:50:25 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Tue, 8 Sep 1992 19:50:01 -0700
Received: from relay2.UU.NET ([137.39.1.7]) by alpha.xerox.com with SMTP id <12210>; Tue, 8 Sep 1992 19:49:20 PDT
Received: from access.digex.com (via uunet.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA07180; Tue, 8 Sep 92 22:49:11 -0400
Received: by access.digex.com id AA26732
  (5.65b/IDA-1.4.3 for community-access@parc.xerox.com); Tue, 8 Sep 92 21:46:32 -0400
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002C102E
In-Reply-to: "<9209071335.AA11726@cruzio.santa-cruz.ca.us>; from \"the piano has been drinking\" at Sep 7, 92 1:35 pm"
Message-ID: <9209090146.AA26732@access.digex.com>
Date:	Tue, 8 Sep 1992 18:46:27 -0700
From:	Frank Hecker <hecker@access.digex.com>
To:	community-access@parc.xerox.com
Subject: Re: MUDs, etc.

chris@cruzio.santa-cruz.ca.us (the piano has been drinking) writes:
> There are several MUD source code depositories on the Internet, and
> I just got back from a jack with some code for MUD robots. One of the
> ideas I had was for a robot I call the "weather god" which would connect
> to a MUD as a player with wizard/god privs, and just keep watch of the 
> time. At certain specific times, it would then race through the MUD 
> database changing the descriptions of things relative to the "weather",
> i.e. position of sun or moon, is it raining, etc.

Neat idea, and of course extensible to monitoring any type of event
outside the world of the MUD, given the appropriate external
interface, and then causing things to happen in the MUD as a
consequence.

> An extension of this would be a "mail god" or "news god" which would
> monitor user MUD commands in the "post office" or at the "news stand",
> and go out to the correct mail and spool files and programs in the way 
> you describe above. 
> 
> Thus, the robot would supply the MUD like interface to both the MUD
> server and the user it would be interacting with, and have a backend
> which manages the mail and news files.

I can see where a "mail god" or "news god" could autonomously monitor
incoming mail or news and make it available within the MUD as it
arrived, analogous to what the "weather god" does.  Do you see this
same agent as handling user requests in the MUD itself?  Or would it
make more sense to have a different type of object doing this?

> Since the user is in a "room" during the entire transaction, they
> can chat with others during the entire time, as they are composing
> and addressing or reading and browsing news and mail.

Yes, this is an advantage.  I would extend this though: is it still
too restrictive to require someone to go to a special room to read or
send mail?  Would it be preferable to implement a portable object
(i.e., which people could "carry" around the MUD) which could be used
to compose, send, and receive messages?

You're right; fun stuff this is, thinking about how to make best use
of this new medium.

Frank

-- 
Frank Hecker
hecker@access.digex.com

From access.digex.com!hecker Fri Sep 11 03:17:51 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "11" "September" "1992" "03:14:06" "-0700" "Frank Hecker" "hecker@access.digex.com" nil "47" "Re: MUDs, etc." "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29578>; Fri, 11 Sep 1992 03:17:50 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11532>; Fri, 11 Sep 1992 03:17:36 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11521>; Fri, 11 Sep 1992 03:16:45 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Fri, 11 Sep 1992 03:15:50 -0700
Received: from relay2.UU.NET ([137.39.1.7]) by alpha.xerox.com with SMTP id <11532>; Fri, 11 Sep 1992 03:15:10 PDT
Received: from access.digex.com by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA09137; Fri, 11 Sep 92 06:14:24 -0400
Received: by access.digex.com id AA09077
  (5.65b/IDA-1.4.3 for community-access@parc.xerox.com); Fri, 11 Sep 92 06:14:07 -0400
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002C478C
In-Reply-to: "<9209082344.AA22197@cruzio.santa-cruz.ca.us>; from \"the piano has been drinking\" at Sep 8, 92 11:44 pm"
Message-ID: <9209111014.AA09077@access.digex.com>
Date:	Fri, 11 Sep 1992 03:14:06 -0700
From:	Frank Hecker <hecker@access.digex.com>
To:	chris@cruzio.santa-cruz.ca.us (the piano has been drinking)
cc:	community-access@parc.xerox.com
Subject: Re: MUDs, etc.

chris@cruzio.santa-cruz.ca.us (the piano has been drinking) writes:
> [proposed design for MUD mail/news object]

Good example.  It is clear that the tools are there to implement a
wide variety of schemes; a lot of the work will be in deciding how
best to design the service to do what users actually want to do.

> Yep. One key aspect to the complete moldability of the medium is that it 
> tends to be, or act like, an object oriented system. For instance, every
> object has a parent, commands in the parent are inherited by the child,
> the child posesses local override of like named parent commands, etc etc.
> This is probably true of most of the different MUD strains out in the world,
> especially the more recent ones.

I would add that the object orientation is probably essential to any
hope of giving users non-trivial abilities to modify the system
themselves.  It also offers a path to designing a better frontend to
the system, as Morningstar and Farmer point out in their Habitat
paper.

> I am very excited about MUDs, especially the combo of MUDs and robots.
> It is also very interesting that MUDs have developed without any real
> corporate or university sponsorship. The fact that they were implemented
> by people with a root requirement that they be fun, interesting, and 
> basically designed for the purpose of human <-> human interaction indicates
> they should be a good tool for community  access systems.
> 
> It definitely feels like new territory, and it feels right.

I might add that MUDs have the supreme advantage for a community
system of being freely available code.  Given our relative lack of
resources, there is no way we are going to be able to develop software
for community access systems from scratch; we're going to have to
identify promising technologies that can be relatively easily adapted
to our needs, and I agree that MUDs can be an important component of a
total solution.

I'm off on vacation now for a week, and in any case I've probably made
all of my general comments worth making.  Thanks for sharing the
information on your work with MUDs in Santa Cruz; I look forward to
future reports.

Frank

-- 
Frank Hecker
hecker@access.digex.com

From parc.xerox.com!pavel Sat Sep 12 15:36:49 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	[nil "Sat" "12" "September" "1992" "15:35:17" "-0700" "Pavel Curtis" "pavel@parc.xerox.com" "<92Sep12.153520pdt.58372@lambda.parc.xerox.com>" "39" "Another style of community access..." "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Sat, 12 Sep 1992 15:36:46 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11765>; Sat, 12 Sep 1992 15:36:16 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11759>; Sat, 12 Sep 1992 15:35:38 PDT
Received: by lambda.parc.xerox.com id <58372>; Sat, 12 Sep 1992 15:35:20 -0700
X-NS-Transport-ID: 08002008D0FD002C5CB9
Message-ID: <92Sep12.153520pdt.58372@lambda.parc.xerox.com>
Date:	Sat, 12 Sep 1992 15:35:17 -0700
From:	Pavel Curtis <pavel@parc.xerox.com>
To:	Community-Access@parc.xerox.com
Subject: Another style of community access...

Reprinted without permission from page 1B of the Peninsula section of the
11 September 1992 San Jose Mercury News:

Computer matchmaker finds a ready clientele

By Sue Hutchinson

The newest attraction at the 42nd Street bar in Palo Alto lures patrons with a
"tropical, sexy-love theme," according to marketing man Bob Baker.  No, it's
not an exotic dance troupe.  The hot draw at the Bryant Street watering hole is
a computer, decked out with pictures of inviting palm fronds and such.

And it purports to end loneliness for a mere five bucks.

DaterBASE, manufactured by Redwood City-based Exidy Inc., made its debut last
month as a kind of electronic bulletin board for singles who want to meet their
match.  Prospective daters pay from $2 to $5 for a computerized file complete
with a photo taken on the spot and a personal-profile questionaire.

The information, devoid of last names and addresses, is swapped via computer
message with other singles.  Vital information is exchanged only if daters and
mutually interested.

Baker said that at least 200 daters have used the system since it was set up
three weeks ago.  "Dating services change between $2,000-$3,000," Baker said.
"But to use DaterBASE you only need pocket change."

Several coupoles have reported to Baker personally that they met "great dates"
on DaterBASE.  He said it especially has been received enthusiastically in the
gay community.

Sure DaterBASE can't screen date mates, Baker said, but "using a dating service
or meeting at a nightclub means you can't screen people either."  Plus, there
are a few common-sense safeguards against getting a dud DaterBASE date.  "If a
girl says she weighs 107 pounds and you can see in the picture that her cheeks
are puffed out, you can guess that she's probably lying," Baker warned.

"No one's gotten married in the three weeks that (DaterBASE) has been on the
market," he said, "but you never know."

From atc.boeing.com!douglas Mon Sep 21 13:16:16 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "21" "September" "1992" "11:51:56" "-0700" "Douglas Schuler" "douglas@atc.boeing.com" nil "40" "African Connection?" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Mon, 21 Sep 1992 13:16:14 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <11743>; Mon, 21 Sep 1992 13:15:39 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11740>; Mon, 21 Sep 1992 13:14:35 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Mon, 21 Sep 1992 13:14:01 -0700
Received: from atc.boeing.com ([130.42.28.80]) by alpha.xerox.com with SMTP id <11600>; Mon, 21 Sep 1992 13:13:34 PDT
Received: by atc.boeing.com (5.57) 
	id AA21119; Mon, 21 Sep 92 11:50:19 PDT
Received: by cleelum.boeing.com (4.1/SMI-3.0DEV3)
	id AA17211; Mon, 21 Sep 92 11:51:56 PDT
X-NS-Transport-ID: 08002008D0FD002CDBF7
Message-ID: <9209211851.AA17211@cleelum.boeing.com>
Date:	Mon, 21 Sep 1992 11:51:56 -0700
From:	Douglas Schuler <douglas@atc.boeing.com>
To:	community-access@parc.xerox.com,
	community-networks@zeus.ce.washington.edu
cc:	civille@washofc.cpsr.org, philip@concave.cs.wits.ac.za,
	pine@csli.stanford.edu
Subject: African Connection?

I'm sending this to the local Seattle network list and also to the
(inter?)national community-access list as it may be of interest to both.

Following is a note from Philip Machanik, a faculty member in CS at the
University of the Witwatersrand in South Africa.  I mentioned our Seattle
project to him and also the strong interest in international work that
exists in Seattle and he sent this note.  

It may be too early to start a project with him but it's probably not to 
early to start talking about possibilities....

Thanks!

-- Doug


> From @shannon.ee.wits.ac.za:philip@concave.cs.wits.ac.za Mon Sep 21 10:02:51 1992
From: philip@concave.cs.wits.ac.za (Philip Machanick)
To: dschuler@cs.washington.edu
Subject: future activity
Cc: philip@concave.cs.wits.ac.za

I recently had a visitor from Zimbabwe. Now that contacts with South African
universities are acceptable, we are likely to become their frontline to
outside technology etc. Do you think CPSR members would be interested in
short technology-transfer visits which would be aimed at helping to build a
Southern African network? South African universities are already on the
internet, but there is little experise in debugging and performance
problems. Other universities in the region may have links through public
domain fidonet nodes, but need to get linked properly.

I would appreciate your thoughts on this.

Philip Machanick                   philip@concave.cs.wits.ac.za
Department of Computer Science, University of the Witwatersrand
2050 Wits, South Africa
phone 27(11)716-3759 fax 27(11)403-1926




From access.digex.com!hecker Sun Sep 27 19:27:44 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "27" "September" "1992" "19:22:54" "-0700" "Frank Hecker" "hecker@access.digex.com" nil "90" "Thoughts on Community Access Systems, Part 2: Participants" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Sun, 27 Sep 1992 19:27:36 -0700
Received: from Mercury.PARC.Xerox.xns by alpha.xerox.com via XNS id <12080>; Sun, 27 Sep 1992 19:27:08 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12079>; Sun, 27 Sep 1992 19:26:25 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 27 Sep 1992 19:26:06 -0700
Received: from relay2.UU.NET ([137.39.1.7]) by alpha.xerox.com with SMTP id <12079>; Sun, 27 Sep 1992 19:25:47 PDT
Received: from access.digex.com by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA17692; Sun, 27 Sep 92 22:24:20 -0400
Received: by access.digex.com id AA11077
  (5.65b/IDA-1.4.3 for community-access@parc.xerox.com); Sun, 27 Sep 92 22:22:55 -0400
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002D3E0B
Message-ID: <9209280222.AA11077@access.digex.com>
Date:	Sun, 27 Sep 1992 19:22:54 -0700
From:	Frank Hecker <hecker@access.digex.com>
To:	community-access@parc.xerox.com
Subject: Thoughts on Community Access Systems, Part 2: Participants

The previous paper in this series set forth the primary goal of a
community access system to be promoting people's participation in the
public life of the community.  This paper discusses those people's
place within the context of the system itself.

Those who develop community access systems often invest significant
effort in identifying groups of people who might be potential users of
the system--students, teachers, citizen activists, the disadvantaged,
small businesspeople, etc.  This work is very important both in
tightening the focus of the system (in the sense of knowing who its
customers and constituencies are) and in designing the system itself
(in the sense of knowing which tasks are important).

However in this brief discussion I want to step back a bit and discuss
some issues that are relevant no matter what groups the system is
directed towards.

First, I want to deemphasize the idea that community access systems
exist to "serve" people, with its implication that we can divide the
community into those who serve ("us" in this case) and those who are
being served ("them").  This idea is embodied in systems that are
designed primarily or exclusively to "provide information," in
particular information that "we" have and that "they" don't (but are
presumed to want).

But those cast in the passive role of "being served" are not
necessarily thereby motivated to cooperate with those who wish to
serve them.  In addition, the unfamilarity of using a computer system
is still a barrier sufficient to discourage those who are not strongly
motivated to do so.  Thus we run the risk of inadvertently creating a
system with more "servers" than "servees."

We also have to consider from whence comes the value of a community
access system.  For example, if by some magic all the people but one
were to disappear from a public library, the remaining person would
most probably still be able to make productive use of the library's
facilities.  On the other hand, if all people but one were to leave a
town meeting then it would be pointless for that person to remain
there.

Given the stated goal of promoting participation in public life, I see
a community access system as being as much analogous to a town meeting
as to a library, with the people using the system collectively adding
value to it and with every person (at least in theory) able to
contribute to that value.

Thus I would rather speak solely of "participants" in a community
access computer system, similarly to the way we speak of "citizens" in
the political sphere; in essence we assume an a priori equality among
all those who use the system.

Of course, in actuality some participants will exercise authority that
others do not.  In some areas this authority will reflect authority
exercised in the public world outside the system, and its legitimacy
within the system will proceed from its legitimacy outside.  Thus a
superintendent of education or a school principal would speak from a
privileged position in an area of the system concerned with the public
schools, and would have power within that area that others do not, e.g.,
to make authoritative pronouncements regarding policy.

In other areas authority may be acquired within the context of the
system itself--for example, as the moderator of an online interest
group or as a volunteer administrator--and in this case the legitimacy
of this authority must be supplied by mechanisms inherent in the
system as a whole.

To put it more simply, if a community access computer system is to be
a mirror of the larger public realm (and this is what the goal of
promoting participation in public life implies), then it should be
based on the same principles.  In particular, a community access
system in a representative democracy should itself have a governance
structure in which the participants in the system have ultimate
control of its structure and operation, as expressed through
appropriate mechanisms.

At a more day-to-day level the system should provide participants the
power to "make the system their own" by enhancing and adding to system
facilities and functions within their area of interest (e.g., adding a
new discussion group or starting a new information repository).  This
power need not be unlimited; however any non-technological limits
should be imposed only through the governance structures mentioned
above.

At this point we come back to the question of what tasks people are
actually going to be using the system for.  This question is taken up
in the next paper.

-- 
Frank Hecker
hecker@access.digex.com

From access.digex.com!hecker Sun Sep 27 20:11:26 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "27" "September" "1992" "19:25:17" "-0700" "Frank Hecker" "hecker@access.digex.com" nil "142" "Thoughts on Community Access Systems, Part 3: Tasks" "^Date:" nil nil "9"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29577>; Sun, 27 Sep 1992 20:11:23 -0700
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12086>; Sun, 27 Sep 1992 20:11:10 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12085>; Sun, 27 Sep 1992 20:10:28 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 27 Sep 1992 20:10:08 -0700
Received: from relay2.UU.NET ([137.39.1.7]) by alpha.xerox.com with SMTP id <12085>; Sun, 27 Sep 1992 20:09:42 PDT
Received: from access.digex.com by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20759; Sun, 27 Sep 92 23:09:13 -0400
Received: by access.digex.com id AA11210
  (5.65b/IDA-1.4.3 for community-access@parc.xerox.com); Sun, 27 Sep 92 22:25:20 -0400
X-Mailer: ELM [version 2.3 PL11]
X-NS-Transport-ID: 08002008D0FD002D3E3E
Message-ID: <9209280225.AA11210@access.digex.com>
Date:	Sun, 27 Sep 1992 19:25:17 -0700
From:	Frank Hecker <hecker@access.digex.com>
To:	community-access@parc.xerox.com
Subject: Thoughts on Community Access Systems, Part 3: Tasks

Thus far we have envisioned a community access computer system as
providing a way for participants to come together as equals, each in
their own way, to enrich the public life of their community.  This
paper looks at the types of things that people might want to do in
such a system.

We start with two qualities that every task should have, one important
to the participant and one to the system.  (Here I use the word
"system" broadly, to mean not only the computer hardware and software
but also the people involved with it, including its sponsors and
administrators.)

>From a participant's point of view it is important that each task they
undertake be completed successfully, with a proper resolution and
sense of closure.  This means more than just that system operations be
carried out without error; the issue is that the system operations
possible may not exactly reflect what the participant actually wishes
to do, and thus an operation may complete successfully without the
participant's intent being carried out.

For example, suppose that a person wishes to obtain and read a book
from their local library.  They go to the library, find the book on
the shelf (assuming it's there), check it out, and go home with it.
At that point their initial goal has been achieved, and the task
completed to their satisfaction.

On the other hand, suppose that the book is not present but can be
found in another library somewhere, so that it must be specially
requested as an inter-library loan and sent to this library.  In this
case even though the system might have successfully completed its
operations (e.g., finding the book and initiating a loan request), the
person's task is left uncomplete and additional actions are still
required on their part, i.e., to come back to the library when the
book arrives and check it out.

It would be possible to partially remedy this deficiency by, e.g.,
enhancing the system so that when requesting a book the person could
have it sent directly to their home via overnight delivery (e.g., by
charging this service to a credit card).  Then even though the person
wouldn't yet have the book, still they would have completed all the
actions they need to take, so that the task from their point of view
would be essentially complete.

Turning now to the system's point of view, given that we wish to
promote as much participation as possible it is important that
completion of one task should in turn encourage the participant to
begin additional tasks, with each completed task linking to the next.
These other tasks might be repetitions of the original task or might
be new related or unrelated tasks.

Returning to the example above, once the person finishes reading the
book they go back to the library to return it.  This in turn puts them
in a situation where they are likely to find additional books that
they wish to check out, thus beginning the cycle again and increasing
their participation in the library system.

On the other hand, suppose that the library could print out a
brand-new copy of a book for each person requesting it, which the
person could keep or discard when they finished reading.  As with the
original example, this would satisfy the person's basic goal to get
and read the book; in fact, it might even be a better outcome since
they would not have to worry about returning the book.  However in one
sense it would be an inferior solution from the library's point of
view, since it would eliminate one factor encouraging people to visit
libraries.

In the original example I claimed that a library system should not
force a person to return to the library to pick up a requested book.
Why is it "bad" to have the person come back to the library in that
case, and "good" in this case?  Because the return visit to pick up a
book occurs at an unnatural point in the cycle of tasks: the person is
less likely to check out a new book when they have just received the
one they originally wanted.  Thus the benefits to the library of
having them visit are small relative to the inconvenience suffered by
the person.

In designing a community access system we therefore need to pursue
these twin aims of ensuring that participants' tasks be completed to
their satisfaction and that each completed task lead to another being
started, balancing one goal against the other when they are in
conflict.

At this point it's appropriate to try and categorize the particular
types of tasks that participants in a community access system might
want to undertake.  For now I'll be discussing these at a rather
abstract level.

Given that the essence of a community access system is participation,
it seems natural to characterize tasks according to how many people
participate in them, starting with tasks in which only one person
participates.  There are at least two general types of tasks here,
which I will call online grazing and document creation.  (Better
shorthand names are welcome; I'm not totally happy with any of those
I've used.)

By online grazing I mean a relatively undirected activity in which a
person moves through the system looking at new items, reading
documents that interest them, browsing through indices, trying out new
operations, etc.  In contrast document creation is more directed; the
person is trying to create some type of work, be it small or large.

The next group of tasks are those that are primarily one-to-one, one
person participating with another; this group includes such things as
having a conversation, one-on-one assistance or instruction, and
debate or argument, distinguished roughly as follows:  Conversation
assumes status equality between participants, with increased
interpersonal connection the goal.  Instruction assumes status
inequality (i.e., teacher-student) between participants, with learning
the goal.  Debate assumes a contested and fluid relative status
between participants, with enhanced status the goal.  (Thus debate
often includes the presence of an audience which does not participate
directly but can judge status claims.)

Tasks which can be one-to-many include asking questions, requesting
actions, and information sharing or publication.  Asking questions
involves one person asking for information (which may be a matter of
fact or of judgement), where that information may be supplied by any
of a number of different people.  On the other hand, when a person
requests an action to be performed typically only one or at most a
few people can perform that action, but the person making the request
has limited prior knowledge as to who to ask.  Information sharing
means one person disseminating information (which may be an entire
created work) for use, appreciation, or comments by others.

Finally, many-to-many tasks are those in which several people can
participate as roughly equal partners.  Common types include
collaboration and joint exercises, which I distinguish on the basis of
goals: the point of collaboration is to produce a created work (e.g.,
a document), while the goal of a joint exercise is to effect some
outcome.  Examples of joint exercises are voting and multi-person
simulation "games" (which are often not games per se but a way of
learning about complex systems and exploring possible solutions to
problems).

The next set of papers in this series will attempt to further
characterize these tasks and to explore how a community access system
might be designed to facilitate their completion, keeping in mind the
desired principles of task closure and linkage discussed above.

-- 
Frank Hecker
hecker@access.digex.com

From parc.xerox.com!pavel Mon Oct  5 23:21:03 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "5" "October" "1992" "23:14:00" "-0700" "Pavel Curtis" "Pavel@parc.xerox.com" nil "76" "Re: Another style of community access..." "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29580>; Mon, 5 Oct 1992 23:21:01 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11731>; Mon, 5 Oct 1992 23:20:46 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11729>; Mon, 5 Oct 1992 23:19:48 PDT
Received: by lambda.parc.xerox.com id <58374>; Mon, 5 Oct 1992 23:19:16 -0700
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002DC17D
Message-ID: <92Oct5.231916pdt.58374@lambda.parc.xerox.com>
References: <92Sep12.153520pdt.58372@lambda.parc.xerox.com>
Date:	Mon, 5 Oct 1992 23:14:00 -0700
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	Community-Access@parc.xerox.com
Subject: Re: Another style of community access...

As a follow-up to the article I posted a month ago, about a computerized
match-making system placed in singles bars, this article appeared on page 1B of
the Peninsula section of the 5 October 1992 edition of the San Jose Mercury
News and is reprinted here without permission:
				       
		  Singles take a fancy to new dating machine
				       
			       by Sue Hutchinson

Kent was looking for a date last week.  Well, no, back up.  He wasn't
*looking* for a date because it's not like he doesn't have girls calling him.
But he thought it would be nice to meet someone new.

Kent, who wouldn't give his real name for fear that "girls will think I'm a
pathetic doofus," was having a beer at the Farm House in Redwood City when
something by the bar caught his eye.  It looked like one of those machines that
judge your sex drive by measuring your heartbeat---but it had a picture of a
grass hut surrounded by palm trees.

It was DaterBASE.

"I've heard that there are lots of girls who sign on to this thing," Kent said.
"What the hell."

So he paid the five bucks, looked into the camera lens that snapped his picture
and followed the directions on the computer screen.  He answered a battery of
questions, including what he does for a living, whether he is a risk-taker, how
he feels about feminism.  Next time he signs on, Kent will be able to review
his messages and see the women who are interested in dating him.

"I figure I've got to get at least a couple of answers because, you know, I'm a
door-opener but I still believe in women's rights," Kent said.  "And I think
that'll come across in my answers."

Kent is one of hundreds of intrepid daters who have used DaterBASE since it was
marketed last month by Exidy Inc., a Redwood City-based coin-op machine
manufacturer.  According to Exidy marketing man Bob Baker, the beauty of
DaterBASE is that it does what dating services do, without the $500 price tag.
And it's better than personals ads because daters get more information about
each other, *plus* a photo.

Baker said DaterBASE is the "talk of the floor" at the annual national coin-op
convention in Nashville, Tenn.  "Oh yeah, there's a lot of interest here,"
Baker said.  "I think the (machines) are going to start cropping up
everywhere."

DaterBASE made its Peninsula debut at the 42nd Street bar in Palo Alto.  It's
been temporarily out of service there, but a new machine took up residence in
the Farm House a few weeks ago.

Baker claims that lots of lovelorn singles have found great dates through
DaterBASE.  OK, so no one's married yet, but you never can tell.  "I was
talking to a guy who works at 42nd Street, and he said he matched up with
someone who he'd seen around a lot, but they didn't realize they had the same
interests," Baker said.

Hammond Ku, manager at the Farm House, said the DaterBASE has become a hot
attraction.  "It's really popular here," Ku said.  "People are always crowded
around it."

The Farm House, a barnlike structure with a satelite dish, is, by Exidy's
standards, the perfect test market for DaterBASE.  Perched off Highway 101, it
is filled with the kind of downwardly mobile and eternally hopeful singles who
stand to make DaterBASE a national bonanza.

Thursday night at the Farm House, the DaterBASE wasn't even plugged in.  But
once it was, it shone like a beacon to end loneliness.

As is the case with almost all DaterBASE machines, more men at the Farm House
use it than women.  "You know, the girls like using it because they think it's
kind of funny," said waitress Diana Hernandez.  "But the guys, uh, they take it
more seriously."

Just then, Robert Palmer came blasting over the stereo system: "You might as
well face it, you're addicted to love."  And a woman who had been eyeing Kent
put down her drink and stole up to take a look at the DaterBASE.

From atc.boeing.com!douglas Wed Oct 14 09:16:35 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "14" "October" "1992" "09:10:11" "-0700" "Douglas Schuler" "douglas@atc.boeing.com" nil "40" "Community networks to assist in *planning* ?!?!?" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29578>; Wed, 14 Oct 1992 09:16:22 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12673>; Wed, 14 Oct 1992 09:15:24 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12655>; Wed, 14 Oct 1992 09:14:18 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 14 Oct 1992 09:13:16 -0700
Received: from atc.boeing.com ([130.42.28.80]) by alpha.xerox.com with SMTP id <12655>; Wed, 14 Oct 1992 09:12:41 PDT
Received: by atc.boeing.com (5.57) 
	id AA02968; Wed, 14 Oct 92 09:12:44 PDT
Received: by cleelum.boeing.com (4.1/SMI-3.0DEV3)
	id AA04791; Wed, 14 Oct 92 09:10:11 PDT
X-NS-Transport-ID: 08002008D0FD002E5286
Message-ID: <9210141610.AA04791@cleelum.boeing.com>
Date:	Wed, 14 Oct 1992 09:10:11 -0700
From:	Douglas Schuler <douglas@atc.boeing.com>
To:	community-access@parc.xerox.com, community-networks@ce.washington.edu
Subject: Community networks to assist in *planning* ?!?!?




Here is an angle that I think we ought to be exploring in relation
to community access to computers and to local civic networks.  

The following quote is from "ARCADE", the "Northwest Journal of 
Architecture and Design" from an article called "Busting the Land 
Use Rut: Visioning and the Role of Education in Community Planning."


   THE GROWTH MANAGEMENT ACT

   The Washington State Growth Management Act requires procedures
   for "early and continuous public participation in the development
   and amendment of comprehensive land-use plans and development
   regulations implementing such plans."  (Section 14, SHB 2929)
   While the Act explicitly states the provision for

      "...broad dissemination of proposals and alternatives, 
      opportunity for written comments, public meetings after
      effective notice, provision for open discussion, communication
      programs, information services, and consideration of and 
      response to public comments..."

   It leaves it up to the local planners to come up with a specific
   program for participation.....


It seems like many opportunities exist for a local civic network to
promote this process.

This problem is important, challenging, and topical.  Can we begin to
design and implement systems that would enable citizens to enter into 
and effectively have an impact on these policy issues??

Does anybody have any thoughts on these possibilities?

---- Doug


From media-lab.media.mit.edu!asb Wed Oct 14 09:37:56 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "14" "October" "1992" "09:35:21" "-0700" "asb@media-lab.media.mit.edu" "asb@media-lab.media.mit.edu" nil "17" "network access for kids" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29578>; Wed, 14 Oct 1992 09:37:46 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12685>; Wed, 14 Oct 1992 09:37:19 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12683>; Wed, 14 Oct 1992 09:36:20 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 14 Oct 1992 09:35:42 -0700
Received: from media-lab.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <12683>; Wed, 14 Oct 1992 09:35:23 PDT
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA11135; Wed, 14 Oct 92 12:35:21 -0400
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD002E530F
Message-ID: <9210141635.AA11135@media-lab.mit.edu>
Date:	Wed, 14 Oct 1992 09:35:21 -0700
From:	asb@media-lab.media.mit.edu
To:	community-access@parc.xerox.com, community-networks@ce.washington.edu,
	asb@media-lab.media.mit.edu
Subject: network access for kids


I'm beginning work on a project to use the network (specifically,
MUDs) as an educational environment for kids.  I'd like to
get as large and broad a community of kids involved as possible.
It takes quite a few people to make a community.

Some questions:
How many kids have access to Internet?  
How and from where?
Is anyone working on getting more of the K-12 crowd online?

I am considering the possibility of making this a kids-only place.
I suppose I could just ask people how old they are and take their
word for it... or is there a better approach?

-- Amy Bruckman
	asb@media-lab.media.mit.edu

From u.washington.edu!kaliyuga Thu Oct 15 02:34:16 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "15" "October" "1992" "01:09:21" "-0700" "kaliyuga@u.washington.edu" "kaliyuga@u.washington.edu" nil "76" "Re: Community networks to assist in *planning* ?!?!?" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Thu, 15 Oct 1992 02:34:02 -0700
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11558>; Thu, 15 Oct 1992 02:33:41 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11556>; Thu, 15 Oct 1992 02:33:10 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 15 Oct 1992 02:32:36 -0700
Received: from carson.u.washington.edu ([140.142.52.11]) by alpha.xerox.com with SMTP id <11562>; Thu, 15 Oct 1992 02:32:04 PDT
Received: by carson.u.washington.edu
	(5.65/UW-NDC Revision: 2.22 ) id AA16468; Thu, 15 Oct 92 02:31:40 -0700
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=us-ascii
X-NS-Transport-ID: 08002008D0FD002E62DB
Errors-to: kaliyuga@u.washington.edu
In-Reply-to: <9210141610.AA04791@cleelum.boeing.com>
Message-ID: <Pine.3.05.9210150216.A14204-c100000@carson.u.washington.edu>
Date:	Thu, 15 Oct 1992 01:09:21 -0700
From:	kaliyuga@u.washington.edu
Sender: kaliyuga@carson.u.washington.edu
To:	Douglas Schuler <douglas@atc.boeing.com>
cc:	community-access@parc.xerox.com, community-networks@ce.washington.edu
Subject: Re: Community networks to assist in *planning* ?!?!?



On Wed, 14 Oct 1992, Douglas Schuler wrote:

> Here is an angle that I think we ought to be exploring in relation
> to community access to computers and to local civic networks.  
> 
> The following quote is from "ARCADE", the "Northwest Journal of 
> Architecture and Design" from an article called "Busting the Land 
> Use Rut: Visioning and the Role of Education in Community Planning."
> 
>    THE GROWTH MANAGEMENT ACT
> 
>    The Washington State Growth Management Act requires procedures
>    for "early and continuous public participation in the development
>    and amendment of comprehensive land-use plans and development
>    regulations implementing such plans."  (Section 14, SHB 2929)
>    While the Act explicitly states the provision for
> 
>       "...broad dissemination of proposals and alternatives, 
>       opportunity for written comments, public meetings after
>       effective notice, provision for open discussion, communication
>       programs, information services, and consideration of and 
>       response to public comments..."
> 
>    It leaves it up to the local planners to come up with a specific
>    program for participation.....
> 
> It seems like many opportunities exist for a local civic network to
> promote this process.
> 
> This problem is important, challenging, and topical.  Can we begin to
> design and implement systems that would enable citizens to enter into 
> and effectively have an impact on these policy issues??
> 
> Does anybody have any thoughts on these possibilities?
> 
> ---- Doug

That could certainly be a section on SCN, and would enable those
responsible for the "broad dissemination...." to reach another audience
than whoever they are addressing now (I have no idea where they publish
now, those big signs at sites stating there is a master plan on file?), I
think I have read some information like that in the notices section of the
classifieds, but it is not usually the first section of the paper I turn
to, so I probably usually miss it. A section of SCN entitled "Public Input
Needed" or something like that might help get that information out. Also
the smaller area newspapers and magazines would probably be willing to
both reprint an article each week or month from their publication on SCN
and use other areas as an information source for stuff that needs more
public participation that they could expand on in their publications.

Perhaps publishing those notices could be a source of funding for us? If
they are required by law, maybe the state makes some provision for
funding, or it is figured into the cost of the contract and by being a
regular place, we could get a grant from the contractors association or
whoever to do it? 

Just ideas. Too many for me to follow up on right now however. 

Seanews is willing to give email accounts to people who want to work on
SCN and be on our email lists so they will "be in the loop" so to speak
and know when and where meetings and etc are. Anyone reading this who
knows someone who has not been able to participate because they cannot
afford compuserve or another commercial service, tell them to use their
computer to call 937-9529 and sign on. Mention that they are part of SCN
and Bill McCormick will attempt to validate their account within a day.
The mailer is ELM. (Maybe others, I found that one and stopped looking.)
So please put out the word to those who want to participate.

Thanks, 

-sharma




From halcyon.halcyon.com!tsparks Thu Oct 15 22:33:44 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "15" "October" "1992" "22:29:56" "-0700" "thomas sparks" "tsparks@halcyon.halcyon.com" nil "2" "Re:  network access for kids" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29581>; Thu, 15 Oct 1992 22:33:43 -0700
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <13071>; Thu, 15 Oct 1992 22:33:00 PDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <13064>; Thu, 15 Oct 1992 22:32:28 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Thu, 15 Oct 1992 22:31:59 -0700
Received: from halcyon.com ([192.135.191.2]) by alpha.xerox.com with SMTP id <13068>; Thu, 15 Oct 1992 22:31:30 PDT
Received: by halcyon.com id AA01077
  (5.65c/IDA-1.4.4 for community-access@parc.xerox.com); Thu, 15 Oct 1992 22:29:56 -0700
X-NS-Transport-ID: 08002008D0FD002E7739
Message-ID: <199210160529.AA01077@halcyon.com>
Date:	Thu, 15 Oct 1992 22:29:56 -0700
From:	thomas sparks <tsparks@halcyon.halcyon.com>
To:	asb@media-lab.media.mit.edu, community-access@parc.xerox.com,
	community-networks@ce.washington.edu
Subject: Re:  network access for kids

please keep me informed of your progress
thank you................Tom Sparks (father of two children)

From parc.xerox.com!pavel Fri Oct 30 09:27:54 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "30" "October" "1992" "09:25:51" "-0800" "Pavel Curtis" "Pavel@parc.xerox.com" nil "58" "forwarded message from Gary Chapman" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Fri, 30 Oct 1992 09:27:53 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <11743>; Fri, 30 Oct 1992 09:27:22 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11789>; Fri, 30 Oct 1992 09:26:10 PST
Received: by lambda.parc.xerox.com id <58373>; Fri, 30 Oct 1992 09:25:51 -0800
Fake-Sender: pavel@parc.xerox.com
X-NS-Transport-ID: 08002008D0FD002F6D0B
Message-ID: <92Oct30.092551pst.58373@lambda.parc.xerox.com>
Date:	Fri, 30 Oct 1992 09:25:51 -0800
From:	Pavel Curtis <Pavel@parc.xerox.com>
To:	Community-Access@parc.xerox.com
Subject: forwarded message from Gary Chapman

I don't know how many of you are also on the CPSR mailing list, but this seemed
of interest to this list...

	Pavel

------- Start of forwarded message -------
Date:	Fri, 30 Oct 1992 05:43:39 -0800
From:	"(Gary Chapman)" <chapman@silver.lcs.mit.edu>
To:	Multiple recipients of list CPSR <CPSR%GWUVM.BITNET@pucc.princeton.edu>
Subject:      Local Civic Network in Wisconsin

Computer Professionals for Social Responsibility is trying to help
promote Local Civic Networks around the country.  There are projects
going on in Washington, D.C., Boston, Seattle, Vermont, Portland, and
Madison, Wisconsin.  The following is a call for participation and help
for the Madison project.

For more information about CPSR, the nation's first public interest
organization of people in the computing field, write for more
information at cpsr-staff@csli.stanford.edu or call (415) 322-3778.  For
 more information on CPSR's Local Civic Networks activity, write CPSR
staff member Richard Civille at civille@washofc.cpsr.org.

  ----------------------------------------------------------------------

A team of people based at the Universiy of Wisconsin-Madison is
developing a Public Communication System (PCS), a non-profit network
which will be available to the academic community and to the general
public, and which will operate over the Internet.  We would welcome any
comments or suggestions which you might have, and we would like to
invite anyone who's interested in this project and would like to get
involved.

The goal is to develop a large public forum where people can present
information, ideas, and questions, and where it will be easy for people
to read and respond.  The hardware will consist of a central server, PCS
 computers at universities with connections to the Internet, and PCS
computers in public libraries.  The public will be able to get access by
 dialing in from home or via the PCS computers at public libraries.
People will be able to read for free.  The system will be supported by
subscription fees and by fees charged to SIGs for publishing articles
and newsletters, conducting conferences,etc.  For software, we're
modifying Gopher (a program developed at the University of Minnesota) to
 have enhanced interactive capabilities and security.  We hope to be
ready to test a prototype by this coming summer.

We've already gotten a lot of valuable help from CPSR members. We hope
the PCS will be another example of a public-access network which
develops up from the grass-roots.  Let us know if you have any
suggestions, if you'd like more detailed information, and if you'd like
to get involved.

          John Jordan
          PCS Project Directo
          University of Wisconsin-Madison
          jordan@macc.wisc.edu
          (608) 233-9535
------- End of forwarded message -------

From uunet.uu.net!llnc!ptw08 Fri Oct 30 12:03:05 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "30" "October" "1992" "05:19:24" "-0800" "Peter Miller" "ptw08@llnc.linknet.com " nil "164" "September MacWorld follow-up" "^Date:" nil nil "10"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29586>; Fri, 30 Oct 1992 12:02:57 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11793>; Fri, 30 Oct 1992 12:02:22 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <11810>; Fri, 30 Oct 1992 12:01:12 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Fri, 30 Oct 1992 12:00:42 -0800
Received: from uunet.UU.NET ([137.39.1.2]) by alpha.xerox.com with SMTP id <11809>; Fri, 30 Oct 1992 12:00:07 PST
Received: from llnc.UUCP by uunet.UU.NET with UUCP 
	(5.61/UUNET-uucp-primary) id AA15135; Fri, 30 Oct 92 15:00:01 -0500
Received: by llnc.linknet.COM (smail 3.1.21.1)
	id <m0ml1sU-0003zBC@llnc.linknet.COM>; Fri, 30 Oct 92 13:19 CST
X-NS-Transport-ID: 08002008D0FD002F706B
Message-ID: <m0ml1sU-0003zBC@llnc.linknet.COM>
Date:	Fri, 30 Oct 1992 05:19:24 -0800
From:	ptw08@llnc.linknet.com (Peter Miller)
Sender: llnc!ptw08@uunet.uu.net
To:	community-access@parc.xerox.com
Subject: September MacWorld follow-up

Community Computing Folks, 
 
We want to commend Macworld for its unflinching 
treatment of "America's Shame--The Creation of the 
Technological Underclass in America's Public Schools--
How We Abandoned Our Children's Future" in the 
September issue and for giving this the kind of attention 
that is unusual to find on the front cover of a technology 
magazine.
 
We invite you to join in with this letter writing response, 
one which can also give us an opportunity, to paraphrase 
Playing to Win Executive Director Ramon Morales, to 
increase awareness of the issues of the appropriate uses 
of technology to address the need for sweeping 
educational reform, to enhance our collaborative work in 
advocacy for technology access and equity, and to 
develop ties with innovators who are grappling with the 
same issues and desire to reach out and form linkages 
that can strengthen us all.
 
If you'd like to sign onto this letter which will ultimately 
be sent to Macworld, please send your name, 
organizational affiliation, address, phone number and 
email address to:   ptw08@linknet.com
We'll send you a list of everyone if you want one. If you'd 
like to write your own letter to Macworld, which we 
heartily encourage, please send us a copy, too. You can 
send letters to Macworld Editor Jerry Borrell to:
macworld1@applelink.apple.com (that's macworld#1)
as well as by traditional mail to:  Macworld 
Communications, Editorial Department, 5th Floor, 501 
Second St., San Francisco, CA 94107.
 
Please distribute this letter as widely as possible.
 
An Open Letter to Macworld
-- ---- ------ -- --------
 
We want to commend you for your unflinching treatment 
of "America's Shame--The Creation of the Technological 
Underclass in America's Public Schools--How We 
Abandoned Our Children's Future" in the September issue 
and for giving this the kind of attention that is unusual to 
find on the front cover of a technology magazine.
 
The five articles on this theme are an important 
contribution to both our understanding and to doing 
something about the problem.
 
It is sad and ironic to find that the problem of the 
technological underclass and those who are alienated 
from modern society's basic tools is growing worse while 
computer access itself has become more widespread and 
that, despite a growing equity in hardware distribution 
Jerry Burrell's team findings reveal "a false dependence 
on statistical analysis and a reality so discouraging that it 
made us question how this situation has remained 
unremarked on for so long. Antiquated computers; 
unused computers; computers used for games and not for 
teaching; schools and teachers unprepared to use 
computers that they own; mismanaged or misdirected 
policies; and unknown hundres of millions of dollars 
spent over the last decade for little return." 
 
When we think about it, of course, it makes sense that 
the problem goes well beyond simply having more 
hardware available. Your articles all reinforce each other 
in driving home the basic need:  As Charles Pillers writes 
in his piece on "Separate Realities," "Computer-based 
education in poor schools is in deep trouble... These 
districts lack the training and social support to use 
computers effectively. In most cases, computers simply 
perpetuate a two-tier system of education for rich and 
poor."  In her contribution "Educators Need Support to 
Make Computing Meaningful," Deborah Branscum sums it 
up well with her very title: "it all boils down to 
inadequate or insufficient support, training, research, 
money, and will--or leadership, if you prefer." 
 
Macworld has done a very useful service with this issue 
and we hope you continue to build upon this series and 
publicize more of the experiments, promising programs 
and pilot projects which are attempting to offer 
corrections and alternatives to this frightening situation.
 
Gerri Abrams, Co-Director
Boston Computer Society Education Director
1 Kendall Sq.
Cambridge, MA 02139
617/252-0600
 
Anita Kron Bachrach, Supervisor
Computer Resource Center
United South End Settlements
566 Columbus Ave.
Boston, MA 02118
617/536-8610
ptw12@linknet.com
 
Peg Buckman, President
Technology Education Council of Somerville
167 Holland St.
Somerville, MA 02144
625-6600 x6970
 
Bob Grenoble, President
Boston Computer Society
1 Kendall Sq.
Cambridge, MA 02139
617/252-0600
bcspresident@world.std.com
 
Peter Miller, Director
Somerville Community Computing Center
167 Holland St.
Somerville, MA 02144
617/625-6600 x 6948
Internet: ptw08@linknet.com
 
Michael Roberts
Special Assistant to the President
for Education and Technology
Freedom House
14 Crawford
Dorchester, MA 02121
617/445-3700
 
Ken Sargent
Boston Computer Society
Mac Resource Center
1972 Mass Avenue
Cambridge, MA 02140
617/864-1700
BCS Mac BBS: 617/864-0712
 
Coralee Whitcomb
New England Regional Director,
Computer Professionals for Social Responsibility
Public Service Coordinator
Boston Computer Society
1 Kendall Sq.
Cambridge, MA 02139
617/252-0600 x3312

Copies sent to: 
plee@pearl.tufts.edu
vwright@world.std.com
lwellrab@world.std.com
melanie@hstbme2.mit.edu
pstott@pearl.tufts.edu
aperrin1@cc.swarthmore.edu
cmm@ileat.com
lieberman@lab.media.mit.edu
hhochhei@jade.tufts.edu
williams@lcs.mit.edu
hn0128@dcjcon.das.net
phyland@gwuvm.gwu.edu
madavis@igc.org
fig@eff.org
roberts10@applelink.apple.com
jill_blanchard@crd.lotus.com
community-access@parc.xerox.com


From igc.apc.org!commem!carl Sun Nov  1 08:55:43 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "1" "November" "1992" "08:54:09" "-0800" "carl%commem@igc.apc.org" "carl%commem@igc.apc.org" nil "8" "Re: forwarded message" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 1 Nov 1992 08:55:37 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12031>; Sun, 1 Nov 1992 08:55:15 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12030>; Sun, 1 Nov 1992 08:54:16 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 1 Nov 1992 08:53:49 -0800
Received: from cdp.igc.org ([192.82.108.1]) by alpha.xerox.com with SMTP id <12028>; Sun, 1 Nov 1992 08:53:34 PST
Received: by igc.apc.org (4.1/Revision: 1.38 )
	id AA06800; Sun, 1 Nov 92 08:54:09 PST
X-NS-Transport-ID: 08002008D0FD002F8570
Message-ID: <9211011654.AA06800@igc.apc.org>
Date:	Sun, 1 Nov 1992 08:54:09 -0800
From:	carl%commem@igc.apc.org
To:	community-access@parc.xerox.com
Subject: Re: forwarded message

I wrote to John Jordan informing him about the community access list and
suggesting he join.  I'm particularly interested in their choice of Gopher
and the Internet as a platform.  It seems to have a lot of advantages from
the "chicken-and-egg" standpoint -- you have a lot of interesting stuff
available from day 1 in order to attract users.  Also, it makes connecting
such community systems together almost trivial.  Anyone have any experience
with or comments on this software?


From igc.apc.org!commem!carl Sun Nov  1 09:13:44 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "1" "November" "1992" "09:12:22" "-0800" "carl%commem@igc.apc.org" "carl%commem@igc.apc.org" nil "24" "public policy" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sun, 1 Nov 1992 09:13:39 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12035>; Sun, 1 Nov 1992 09:13:17 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12032>; Sun, 1 Nov 1992 09:12:36 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Sun, 1 Nov 1992 09:12:10 -0800
Received: from cdp.igc.org ([192.82.108.1]) by alpha.xerox.com with SMTP id <12032>; Sun, 1 Nov 1992 09:11:47 PST
Received: by igc.apc.org (4.1/Revision: 1.38 )
	id AA07914; Sun, 1 Nov 92 09:12:22 PST
X-NS-Transport-ID: 08002008D0FD002F8591
Message-ID: <9211011712.AA07914@igc.apc.org>
Date:	Sun, 1 Nov 1992 09:12:22 -0800
From:	carl%commem@igc.apc.org
To:	community-access@parc.xerox.com
Subject: public policy

Doug Schuler points out:
	
>   The Washington State Growth Management Act requires procedures
>   for "early and continuous public participation in the development
>   and amendment of comprehensive land-use plans and development
>   regulations implementing such plans."  (Section 14, SHB 2929)
>   While the Act explicitly states the provision for
>
>      "...broad dissemination of proposals and alternatives, 
>      opportunity for written comments, public meetings after
>      effective notice, provision for open discussion, communication
>      programs, information services, and consideration of and 
>      response to public comments..."
>
>   It leaves it up to the local planners to come up with a specific
>   program for participation.....

I concur that it would be a great thing to look into, particularly because
such legislation is one of the few places where the government and/or
private parties are mandated to spend money to encourage people to express
themselves.  If we have a cost-effective way of doing that, it could be
a source of badly needed seed money for such systems.
- Carl


From tosh.uucp!rich Wed Nov  4 13:39:09 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "4" "November" "1992" "15:16:00" "-0800" "rich@tosh.wcc.govt.nz" "rich@tosh.wcc.govt.nz" nil "36" "Re: forwarded message" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29579>; Wed, 4 Nov 1992 13:39:05 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <12220>; Wed, 4 Nov 1992 13:38:42 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12226>; Wed, 4 Nov 1992 13:37:41 PST
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58372>; Wed, 4 Nov 1992 13:36:44 -0800
Received: from kosmos.wcc.govt.nz ([192.54.130.39]) by alpha.xerox.com with SMTP id <12220>; Wed, 4 Nov 1992 13:36:18 PST
Received: from tosh by kosmos.wcc.govt.nz (MX V3.1C) with UUCP; Thu, 05 Nov
          1992 07:31:47 +1200
Received: by tosh.wcc.govt.nz (1.64/waf) via UUCP; Wed, 04 Nov 92 23:16:02 GMT
          for community-access@parc.xerox.com
Organization: City Net -  Wellington City Council's Community Computer Network
X-NS-Transport-ID: 08002008D0FD002FC70D
In-Reply-to: <9211011654.AA06800@igc.apc.org>
Message-ID: <D6oPTB26w164w@tosh.wcc.govt.nz>
Date:	Wed, 4 Nov 1992 15:16:00 -0800
From:	rich@tosh.wcc.govt.nz
Sender: rich@tosh.uucp
To:	community-access@parc.xerox.com
Subject: Re: forwarded message

23:12:38
 4-Nov-1992

carl%commem@igc.apc.org writes:

> I wrote to John Jordan informing him about the community access list and
> suggesting he join.  I'm particularly interested in their choice of Gopher
> and the Internet as a platform.  It seems to have a lot of advantages from
> the "chicken-and-egg" standpoint -- you have a lot of interesting stuff
> available from day 1 in order to attract users.  Also, it makes connecting
> such community systems together almost trivial.  Anyone have any experience
> with or comments on this software?
>

We use gopher at WCC CityNet. We currently have the Council
By-Laws and District Planning Ordinances in gopher, as well as
Council Policy Manual. We are now investigating adding Council
Minutes, Standing Orders, etc.

We have succeeded in getting images in and working, so I'm going
to try and get some images from the Art Gallery, or maps from teh
scheme/ordinances.

Currently we have 1000+ public access users and expect more. We
typically get 100 a month.

You can look at our gopher on gopher.wcc.govt.nz

Richard Naylor
IT Manager
Wellington City Council
New Zealand


--
rich@tosh.wcc.govt.nz (Richard Naylor )

From media-lab.media.mit.edu!asb Sat Nov  7 07:13:27 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "7" "November" "1992" "07:10:45" "-0800" "asb@media-lab.media.mit.edu" "asb@media-lab.media.mit.edu" nil "27" "planning a community-access system for kids" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sat, 7 Nov 1992 07:13:15 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12042>; Sat, 7 Nov 1992 07:12:56 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12041>; Sat, 7 Nov 1992 07:12:13 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by mu.parc.xerox.com with SMTP id <58372>; Sat, 7 Nov 1992 07:11:36 -0800
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <93>; Sat, 7 Nov 1992 07:11:13 -0800
Received: from media-lab.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <12041>; Sat, 7 Nov 1992 07:10:46 PST
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA03644; Sat, 7 Nov 92 10:10:45 -0500
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD003002A6
Message-ID: <9211071510.AA03644@media-lab.mit.edu>
Date:	Sat, 7 Nov 1992 07:10:45 -0800
From:	asb@media-lab.media.mit.edu
To:	community-access@parc.xerox.com
Subject: planning a community-access system for kids


I had an interesting conversation last night with some folks
who are starting a network for kids of alcoholic parents.

They'll be applying for grants and requesting donations of
equipment, and need to know what hardware they'll need.
Let's suppose that they start with 100 kids and gradually
grow to 300.

* How many incoming modem lines do you need to service that size
	community?
* What sort of hardware and software do you need to manage the modem bank?
* I'm assuming that it's simpler and safer to run the system
	on a stand-alone machine rather than try to become an Internet
	site, at least initially.  Is this a good analysis?
* What BBS software is a good choice?
* How much maintenance is required?
	-- How much time will it take to perform system administration
		tasks on a system of this size (backups, 
		maintaining the modem bank, etc.)?
	-- How much time will it take to perform community-level
		administration tasks (answering questions,
		resolving conflicts, etc.)

Thanks!

-- Amy

From media-lab.media.mit.edu!asb Sat Nov  7 07:24:01 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "7" "November" "1992" "07:18:21" "-0800" "asb@media-lab.media.mit.edu" "asb@media-lab.media.mit.edu" nil "18" "critical mass for a community" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29573>; Sat, 7 Nov 1992 07:23:54 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12044>; Sat, 7 Nov 1992 07:23:18 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12043>; Sat, 7 Nov 1992 07:22:25 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by mu.parc.xerox.com with SMTP id <58372>; Sat, 7 Nov 1992 07:19:09 -0800
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <93>; Sat, 7 Nov 1992 07:18:51 -0800
Received: from media-lab.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <12042>; Sat, 7 Nov 1992 07:18:23 PST
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA03739; Sat, 7 Nov 92 10:18:21 -0500
X-Mts: smtp
X-NS-Transport-ID: 08002008D0FD003002B9
Message-ID: <9211071518.AA03739@media-lab.mit.edu>
Date:	Sat, 7 Nov 1992 07:18:21 -0800
From:	asb@media-lab.media.mit.edu
To:	community-access@parc.xerox.com, social-vr@parc.xerox.com
Subject: critical mass for a community


How many people does it take to make a community?

As I may have mentionned, I had an interesting conversation last night
with some folks who want to start a community-access network
for kids of alcoholic parents.  It will include a BBS and a MUD,
and maybe other services.  (Any ideas?)

I'm concerned about the issue of critical mass.  It seems to me
that you need a certain number of people to start a BBS and
many more to start a viable MUD.  The question is, how many?
I suggested they aim for at least 100 kids to start.  They
suggested trying the system out with 10 kids to start, and
I said I thought that wouldn't work.

Any opinions?  Experiences you can share?  Thanks!

-- Amy

From cruzio.santa-cruz.ca.us!chris Sat Nov  7 19:29:31 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sat" "7" "November" "1992" "19:00:19" "-0800" "chris@cruzio.santa-cruz.ca.us" "chris@cruzio.santa-cruz.ca.us" nil "44" "Re: critical mass for a community" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Sat, 7 Nov 1992 19:29:24 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12535>; Sat, 7 Nov 1992 19:29:08 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12504>; Sat, 7 Nov 1992 19:28:13 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by mu.parc.xerox.com with SMTP id <58374>; Sat, 7 Nov 1992 19:23:19 -0800
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <93>; Sat, 7 Nov 1992 19:22:52 -0800
Received: from media-lab.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <12429>; Sat, 7 Nov 1992 19:22:29 PST
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA23706; Sat, 7 Nov 92 22:22:25 -0500
Received: from cruzio.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1)
	id AA09296; Sat, 7 Nov 92 20:20:53 PPE
Received: by cruzio.santa-cruz.ca.us (smail2.5)
	id AA21256; 7 Nov 92 19:00:19 PST (Sat)
X-Mailer: ELM [version 2.3 PL0]
X-NS-Transport-ID: 08002008D0FD00300753
In-Reply-to: "<9211071518.AA03739@media-lab.mit.edu>; from \"media-lab.media.mit.edu!asb\" at Nov 7, 92 7:18 am theref"
Message-ID: <9211071900.AA21256@cruzio.santa-cruz.ca.us>
Date:	Sat, 7 Nov 1992 19:00:19 -0800
From:	chris@cruzio.santa-cruz.ca.us
To:	media-lab.media.mit.edu!asb@netcom.com
cc:	media-lab.media.mit.edu!parc.xerox.com!community-access@netcom.com,
	media-lab.media.mit.edu!parc.xerox.com!social-vr@netcom.com
Subject: Re: critical mass for a community

> 
> 
> How many people does it take to make a community?
> 
> As I may have mentionned, I had an interesting conversation last night
> with some folks who want to start a community-access network
> for kids of alcoholic parents.  It will include a BBS and a MUD,
> and maybe other services.  (Any ideas?)
> 
> I'm concerned about the issue of critical mass.  It seems to me
> that you need a certain number of people to start a BBS and
> many more to start a viable MUD.  The question is, how many?
> I suggested they aim for at least 100 kids to start.  They
> suggested trying the system out with 10 kids to start, and
> I said I thought that wouldn't work.
> 
> Any opinions?  Experiences you can share?  Thanks!
> 
> -- Amy
> 


100 kids, eh?
Sounds a bit high, unless you live in a major metropolitan area.
Even if you went to meetings of AA's "Children of Alcholics" and
got the participation of every kid from that ready made and 
identified pool of potential users who had access to a computer
and modem, you might be hard pressed to get 100 kids at the 
very beginning of the system's existance.

10 does sound much more reasonable for a start. A BBS on a pc of
some sort can be put together for a couple hundred bucks. It 
can easily provide a core set of services including email, bulletins,
discussion groups and text files of interesting info.

A MUD requires a multi user platform, which is much more expensive in
hardware and software, as well as more of an administrative headache.  
(ah, those muti user operating systems...)

If money is no problem, then spring for the multi user system and prepare
to spend time growing the user base. A MUD designed for kids of alcoholic
parents sounds like a very interesting support/therapy tool.

ccn

From uunet.uu.net!markets!randy Mon Nov  9 11:38:10 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Mon" "9" "November" "1992" "09:03:45" "-0800" "markets!randy@uunet.uu.net" "markets!randy@uunet.uu.net" nil "27" "Re: critical mass for a community" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29576>; Mon, 9 Nov 1992 11:38:09 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <11797>; Mon, 9 Nov 1992 11:37:50 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11796>; Mon, 9 Nov 1992 11:36:11 PST
Received: from lambda.parc.xerox.com ([13.2.116.36]) by mu.parc.xerox.com with SMTP id <58372>; Mon, 9 Nov 1992 11:35:12 -0800
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <98>; Mon, 9 Nov 1992 11:34:53 -0800
Received: from relay1.UU.NET ([137.39.1.5]) by alpha.xerox.com with SMTP id <11756>; Mon, 9 Nov 1992 11:34:15 PST
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA12029; Mon, 9 Nov 92 14:31:20 -0500
Received: from markets.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 143046.19196; Mon, 9 Nov 1992 14:30:46 EST
Received: from grand-central by amix.com (4.1/SMI-4.1)
	id AA16567; Mon, 9 Nov 92 09:02:59 PST
Received: from [192.29.99.223] (fighter) by grand-central (4.1/Grand-Central-SMI-4.0.3)
	id AA08934; Mon, 9 Nov 92 09:02:55 PST
X-NS-Transport-ID: 08002008D0FD00301AD9
Message-ID: <9211091702.AA08934@grand-central>
Date:	Mon, 9 Nov 1992 09:03:45 -0800
From:	markets!randy@uunet.uu.net
To:	community-access@parc.xerox.com, social-vr@parc.xerox.com,
	uunet!media-lab.media.mit.edu!asb@uunet.uu.net
Subject: Re: critical mass for a community

At  7:18 AM 11/7/92 -0800, uunet!media-lab.media.mit.edu!asb wrote:
>How many people does it take to make a community?
..
>I'm concerned about the issue of critical mass.  It seems to me
>that you need a certain number of people to start a BBS and
>many more to start a viable MUD.  The question is, how many?
>I suggested they aim for at least 100 kids to start.  They
>suggested trying the system out with 10 kids to start, and
>I said I thought that wouldn't work.
>
>Any opinions?  Experiences you can share?  Thanks!
>
>-- Amy

My expeience with the Habitats' early test periods indicates that you 
need more than 10...  30-50 seemed like enough *if* the hours of
operations were limited *and* there were scheduled events or meeting times.

For self-sustaining operations (where eough people are on-line to build
a sense of place most of the time) you need *well over* 100 people.

The key with small communities (<100) is getting the word out about the times to meet.
--------------------------------------------
F. Randall Farmer     randy@markets.amix.com
  AMiX, The American Information Exchange
--------------------------------------------


From hpljaj.hpl.hp.com!jjohnson Wed Nov 11 16:55:07 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Wed" "11" "November" "1992" "16:52:08" "-0800" "Jeff Johnson" "jjohnson@hpljaj.hpl.hp.com" nil "175" "OTA Study Request on info-access" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29585>; Wed, 11 Nov 1992 16:55:02 -0800
Received: from Clayvin.Parc.Xerox.xns by alpha.xerox.com via XNS id <12815>; Wed, 11 Nov 1992 16:54:31 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12809>; Wed, 11 Nov 1992 16:53:37 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58373>; Wed, 11 Nov 1992 16:53:06 -0800
Received: from hplms2.hpl.hp.com ([15.255.176.66]) by alpha.xerox.com with SMTP id <12809>; Wed, 11 Nov 1992 16:52:35 PST
Received: from hpljaj.hpl.hp.com by hplms2.hpl.hp.com with SMTP
	(16.5/15.5+IOS 3.20) id AA15592; Wed, 11 Nov 92 16:52:25 -0800
Received: from localhost by hpljaj.hpl.hp.com with SMTP
	(16.6/15.5+IOS 3.14) id AA06622; Wed, 11 Nov 92 16:52:09 -0800
X-NS-Transport-ID: 08002008D0FD00305334
Message-ID: <9211120052.AA06622@hpljaj.hpl.hp.com>
Date:	Wed, 11 Nov 1992 16:52:08 -0800
From:	Jeff Johnson <jjohnson@hpljaj.hpl.hp.com>
To:	community-access@parc.xerox.com
cc:	cpsr-activists@csli.stanford.edu
Subject: OTA Study Request on info-access


Don't know if this already appeared on these lists.  It was posted to
systers and someone on that list forwarded it to me.

JJ

------- Forwarded Message
Date: Tue, 6 Oct 1992 08:26:38 -0600
From: "(Frank Odasz)" <franko@BIGSKY.DILLON.MT.US>
Subject: Congressional OTA Study Request

To: Consortium for School Networking members

>From: Frank Odasz, Director of Big Sky Telegraph
      franko@bigsky.dillon.mt.us

RE: I'd like to invite everyone interested to respond directly to my
Internet ID (above) regarding the following congressional request for
input! CoSN members can be particularly helpful with the POLICY
questions toward the end of the list! Please feel free to disseminate
the following.

Congressional input for this study can also be forwarded to Tom Grundner
at Cleveland Freenet - telnet 129.22.8.76 or telnet 129.22.8.75. Tom's
voice number is 216-368-2733. Tom is focusing on gathering urban input
while Big Sky Telegraph is gathering rural input. EVERYONE is invited to
contribute to this study.  Feel free to add your own questions and
answers and/or to answer the listed questions in whatever manner suits
you.

     CONGRESSIONAL OFFICE OF TECHNOLOGY ASSESSMENT STUDY AND
                 WESTERN'S BIG SKY TELEGRAPH
          CONNECT ELECTRONICALLY TO CITIZENS FOR INPUT.

The US Congressional Office of Technology Assessment is conducting a
major study and has contracted with BIG SKY TELEGRAPH of Western Montana
College to solicate from citizens suggestions regarding the potential of
information technology to allow the Federal government to be more
responsive to rural and small town America in the dissemination of
Federal services and information. BILLIONS of your tax dollars are spent
each year disseminating Federal services and information!

THE CHALLENGE:
"Electronic technologies might reduce the need for some layers of
bureaucracy, help bring government services more directly to the
citizens, and, by so doing, provide better services more cheaply."

One goal of this study is to determine if citizens CARE enough to
respond to the opportunity to advise congress DIRECTLY, if given the
opportunity. This IS YOUR opportunity! The hope is that grassroots input
will provide innovative ideas and approaches.

EVERYONE interested is invited to respond to ANY or ALL of the following
questions and engage in online discussions with any of the other
participants. Access to Big Sky Telegraph is available at no charge
using a modem at 406-683-7680. Select M)essages from the Main Menu, then
select the USCONGRESS conference. Big Sky Telegraph's voice number is
406-683-7870.

The conference will be held from September 1 - December 1, 1992,
solicating online written comments and opinions from teacher,
student, and citizen users of Big Sky Telegraph. All messages
will be printed and included as appendices to the study. A
summary 30-40 page double-spaced report from Big Sky Telegraph is
due in draft form Nov. 9, the final report is due Dec. 18, 1992.

PLEASE share your views on the following questions, and feel free to ask
your OWN!

1. What are citizen needs and desires for the electronic services?

2. If the appropriate technology were in place, what would citizens like
   to be able to DO and how would their lives improve?

3. What are the opportunities for improvement in the productivity and
   efficiency of service and information delivery?

4. What problems might arise with both service provider and citizen
   acceptance of electronic delivery?

5. What might be the requirements for education, training, and equipping
   of recipients?

6. How would electronic access impact users who are senior citizens, or
   disabled, or who live in rural settings?

7. What might be the requirements for training of service providers?

8. What services that are reasonably representative of the types of
   Federal services provided to small towns might be best suited to
   electronic delivery?

9. What services and technical applications might highlight
   opportunities for innovation in service delivery?

10. What are the prerequisites of successful implementations with
    attention to facilitators and inhibitors of innovations?

11. How might the services, delivery mechanisms, and related
    policy/management frameworks be redesigned?

EDUCATIONAL APPLICATIONS:  
What should the federal policy be with regard to supporting K-12 and
other educational applications using computer networks?

1. What computer network or information services could the federal
   government provide access to which would make our K-12 schools
   better?

2. Does the federal government have an obligation to provide more than
   access to services, must it also insure equitable access to these
   services for all schools and provide the necessary training to use
   these services effectively?

3. Should the federal government have a responsibility to assist in
   corporate and business training programs, or should it stop at the
   K-12 or college levels?

POLICY QUESTIONS: (These questions may be too technical for some
people.)

1. What might be the requirements for the government telecommunication
   and computing technology infrastructure needed to support electronic
   delivery, including appropriate technical standards to ensure systems
   compatibility and interoperability?

2. What consistency of electronic service delivery innovations exists
   with the current policy/management framework?

3. What policy/management changes that may be needed to implement
   technology-enhanced service delivery to rural/small town America?

How could electronically delivered service applications be implemented
to take into account the following policy/mangagement considerations?

1. equity of electronic access to Federal services

2. protection of citizen privacy in Federal record systems

3. prevention/detection of fraud, waste, and abuse in program management
   and service delivery

4. protection of the security and integrity of systems used for
   electronic service delivery

5. appropriate retention and archiving of records and information
   related to electronic service delivery

6. consistency with annual and five-year agency planning for
   telecommunications and information resource management

7. relationship to agency automation programs and activities

8. relationship to FTS2000, NREN, and other Federal information
   technology programs

9. opportunities presented by electronic service delivery for
   synergy/economies of scale across Federal agencies/programs, across
   Federal/State/local levels of government

10. opportunities for cooperation with the private sector (service
    providers, computer/telecommunications providers, profit and
    nonprofit)

11. opportunities for telework, telecommuting


Frank Odasz                      \   /    ^     IMAGINATION
Western Montana College, Dillon, - O -   / \  ^  is more important
MT, 59725 Voice:406-683-7338     /   \ ^/~~~\/~\  than knowledge.
Fidonet: 1:346/3 Fax 406-683-7493     / \    \  \ -Albert Einstein.
Internet:franko@bigsky.dillon.mt.us  /   \    \  \
>->>>>>>----Big Sky Telegraph-406-683-7680--1200b,8N1--->

- ------- End of Forwarded Message

From igc.apc.org!commem!carl Thu Nov 12 14:28:24 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Thu" "12" "November" "1992" "14:27:00" "-0800" "carl%commem@igc.apc.org" "carl%commem@igc.apc.org" nil "25" "Size of community" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29593>; Thu, 12 Nov 1992 14:28:15 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <11876>; Thu, 12 Nov 1992 14:27:53 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <11853>; Thu, 12 Nov 1992 14:27:11 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Thu, 12 Nov 1992 14:26:34 -0800
Received: from cdp.igc.org ([192.82.108.1]) by alpha.xerox.com with SMTP id <11853>; Thu, 12 Nov 1992 14:26:11 PST
Received: by igc.apc.org (4.1/Revision: 1.39 )
	id AA24818; Thu, 12 Nov 92 14:27:00 PST
X-NS-Transport-ID: 08002008D0FD00306880
Message-ID: <9211122227.AA24818@igc.apc.org>
Date:	Thu, 12 Nov 1992 14:27:00 -0800
From:	carl%commem@igc.apc.org
To:	community-access@parc.xerox.com
Subject: Size of community

asb@media-lab.media.mit.edu writes:

>  I'm concerned about the issue of critical mass.  It seems to me
>  that you need a certain number of people to start a BBS and
>  many more to start a viable MUD.  The question is, how many?

I don't think there's any simple answer to this question, but I can
tell you some of the factors involved.  First of all, users of electronic
communications vary greatly in how much they say.  You can have a
lively, facinating e-mail conversation with only three or four people
visibly participating (and maybe dozens or hundreds of others quietly
listening in).  So you can start things with a very small number, if
they're the right people.
Second, for a community to grow, you need to establish a culture where
people feel free to join an ongoing conversation.  You want people from
your pool of 'listeners' to contribute, even if only occasionally.  This
requires an on-line culture that encourages such participation in the
abstract and nurtures concrete examples when they occur.
Third, you need to distinguish between general interest and special
interest systems.  A general interest system needs a lot more people
just to assure that there are a few individuals interested in any given
subject.  A special interest system doesn't have this problem, so a
much smaller user base is OK.
-Carl


From well.sf.ca.us!hlr Sun Nov 15 19:09:51 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "15" "November" "1992" "19:05:34" "-0800" "Howard Rheingold" "hlr@well.sf.ca.us" nil "4" "Re:  critical mass for a community" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Sun, 15 Nov 1992 19:09:43 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <13089>; Sun, 15 Nov 1992 19:09:18 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <13091>; Sun, 15 Nov 1992 19:07:45 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Sun, 15 Nov 1992 19:06:53 -0800
Received: from nkosi.well.sf.ca.us ([192.132.30.4]) by alpha.xerox.com with SMTP id <13089>; Sun, 15 Nov 1992 19:06:27 PST
Received: from well.sf.ca.us by nkosi.well.sf.ca.us (5.65c/SMI-4.1/nkosi-921112-1)
	id AA06795; Sun, 15 Nov 1992 19:07:56 -0800
Received: by well.sf.ca.us (5.65c/SMI-4.1/well-921112-2)
	id AA23079; Sun, 15 Nov 1992 19:05:34 -0800
X-NS-Transport-ID: 08002008D0FD003097C4
Message-ID: <199211160305.AA23079@well.sf.ca.us>
Date:	Sun, 15 Nov 1992 19:05:34 -0800
From:	Howard Rheingold <hlr@well.sf.ca.us>
To:	asb@media-lab.media.mit.edu, community-access@parc.xerox.com,
	social-vr@parc.xerox.com
Subject: Re:  critical mass for a community

If the people have a strong bond, I don't think you need as many
as 100 people. In England, on a system called CIX, there seem to be
many small support groups of a dozen to twenty people in private
conferences.

From media-lab.media.mit.edu!wave Sun Nov 15 22:42:04 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "15" "November" "1992" "22:37:37" "-0800" "wave@media-lab.media.mit.edu" "wave@media-lab.media.mit.edu" nil "14" "critical mass for a community" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <29575>; Sun, 15 Nov 1992 22:41:57 -0800
Received: from Minos.PARC.Xerox.xns by alpha.xerox.com via XNS id <13119>; Sun, 15 Nov 1992 22:41:34 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12639>; Sun, 15 Nov 1992 22:40:30 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58372>; Sun, 15 Nov 1992 22:38:09 -0800
Received: from media-lab.mit.edu ([18.85.0.2]) by alpha.xerox.com with SMTP id <12639>; Sun, 15 Nov 1992 22:37:47 PST
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA16952; Mon, 16 Nov 92 01:37:37 -0500
Illegal-Object: Syntax error in From: address found on alpha.xerox.com:
	From:	Michael B.Johnson <wave@media-lab.mit.edu>
		^	 ^-illegal period in phrase
		 \-phrases containing '.' must be quoted
X-NS-Transport-ID: 08002008D0FD003098D0
In-Reply-to: "Howard Rheingold's message of Sun, 15 Nov 1992 19:05:34 PST <199211160305.AA23079@well.sf.ca.us>"
Message-ID: <9211160637.AA16952@media-lab.mit.edu>
Date:	Sun, 15 Nov 1992 22:37:37 -0800
From:	wave@media-lab.media.mit.edu
To:	hlr@well.sf.ca.us
cc:	asb@media-lab.media.mit.edu, community-access@parc.xerox.com,
	social-vr@parc.xerox.com
Subject: critical mass for a community

   Date: 	Sun, 15 Nov 1992 19:05:34 PST
   From: Howard Rheingold <hlr@well.sf.ca.us>

   If the people have a strong bond, I don't think you need as many
   as 100 people. In England, on a system called CIX, there seem to be
   many small support groups of a dozen to twenty people in private
   conferences.

Yea, Penn & Teller have a small private bulletin board called the
Jungle which has about 10 or so regular participants.  People tend to
call in every day (sometimes more than once a day) and there is a lot
of activity...

- wave 

From uu.psi.com!washofc!civille Sun Nov 29 10:20:34 1992
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Sun" "29" "November" "1992" "08:52:11" "-0800" "Richard Civille" "civille@washofc.cpsr.org" nil "18" "Re: > critical mass for a co" "^Date:" nil nil "11"])
Received: from alpha.xerox.com ([13.1.64.93]) by lane.parc.xerox.com with SMTP id <43014>; Sun, 29 Nov 1992 10:20:25 -0800
Received: from Revere.Parc.Xerox.xns by alpha.xerox.com via XNS id <12618>; Sun, 29 Nov 1992 10:19:59 PST
Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12615>; Sun, 29 Nov 1992 10:18:51 PST
Received: from alpha.xerox.com ([13.1.64.93]) by mu.parc.xerox.com with SMTP id <58373>; Sun, 29 Nov 1992 10:18:14 -0800
Received: from uu.psi.com ([136.161.128.3]) by alpha.xerox.com with SMTP id <12618>; Sun, 29 Nov 1992 10:14:54 PST
Received: from washofc.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
	id AA22073; Sun, 29 Nov 92 13:05:49 -0500
Received: from OFFICE (QM 2.5.1) by washofc.cpsr.org (UMCP\QM 2.0)
 id AA00352; Sun, 29 Nov 1992 12:55:29 EDT
Organization: CPSR, Washington Office
X-Umcp-To: Community Access, Media Lab, Social-VR
X-NS-Transport-ID: 08002008D0FD00316F46
Message-ID: <00541.2805886529.352@washofc.cpsr.org>
Date:	Sun, 29 Nov 1992 08:52:11 -0800
From:	Richard Civille <civille@washofc.cpsr.org>
Sender: washofc!civille@uu.psi.com
To:	Community Access <community-access@parc.xerox.com>
Subject: Re: > critical mass for a co

        Reply to:   RE>> critical mass for a com
I think Howard Reingold's comment about small communities on CIX in England
is on track.  He says:

>If the people have a strong bond, I don't think you need as many
>as 100 people. In England, on a system called CIX, there seem to be
>many small support groups of a dozen to twenty people in private
>conferences.

Communities are composed of small groups which have natural ties across
group boundaries, both weak and strong.  Any online system which supports a
"community" of whatever size has to have the necessary tools to really
support small groups.  Small groups are the building blocks, and social
foundation for any community. 

Richard Civille
CPSR, Wash. DC


