\section{Status and Future Directions}

{\it Discuss} has found ever-increasing popularity since its initial
implementation in
Fall 1986.  Its user community has grown from a core set of SIPB
members to more than 220 MIT students and staff.  The number of
meetings has grown from a few test meetings on a couple machines to
116 meetings on eight server machines.

\subsection{Current {\it Discuss} meetings}
Some of the current {\it Discuss} meetings archive mailing lists that exist
on the
Internet.  For example, there are {\it Discuss} meetings that archive the
``Info-Mac'', ``TeXHaX'', ``Risks'', and ``Kerberos'' mailing lists.
These meetings allow MIT computer users to read these lists without
getting themselves added to the lists and having these messages
intermixed with their regular electronic mail.

{\it Discuss} meetings support several services at Project Athena.
They archive user bug reports, so that developers can review them in a
readily accessible and efficient manner.  {\it Discuss} is also used by
the Athena On-line Consulting (OLC) System to store sessions
between users and consultants.  This way, all consultants can review
interactions between users and consultants.

Several Athena development projects use {\it Discuss} to coordinate
the activities of project members who have different schedules and
different geographic locations.  {\it Discuss} has been used to help
develop {\it Discuss} itself, {\it Zephyr}, and {\it Kerberos}.  With a {\it
Discuss} meeting, chaining allows replies to be organized, and the
archival nature of {\it Discuss} means that new members of the
project can review past transactions.

Finally, {\it Discuss} meetings play a social role at MIT.  There are
{\it Discuss}
meetings for random discussion, changed {\it plan} files, depressing
thoughts and cheery thoughts, as well as private meetings for
self-selected groups of people.  These meetings frequently generate
interesting, lively discussion.

\subsection{Future of {\it Discuss}}
At the moment, {\it Discuss} appears to have attained critical mass, in that
the current user community is producing enough interesting information
to sustain itself.  Future development in {\it Discuss} will be aimed at
improving the current system, and increasing its usage within the
MIT community.

The next improvement to {\it Discuss} will be better user interfaces, so
that {\it Discuss} can be used by people who are unfamiliar or uncomfortable 
with command-line
interfaces.  Currently, one of the authors is working on {\tt xdsc}, an 
X-based client,
so that users can read and enter {\it Discuss} transactions using a
mouse/window interface.  Minor changes such as displaying a user's real name
instead of his user name could have a large user friendliness payoff.
Another way of increasing {\it Discuss} usage is to
port {\it Discuss} onto other machines with distinctive user interfaces,
such as the Apple Macintosh.

Along with different interfaces, we are considering adding new features
to {\it Discuss}.  With an X-based interface, it is useful to
consider multi-media transactions, where {\it Discuss} transactions could mix
pictures and text.  {\it Discuss} could also be better integrated with mail,
so that users could reply to {\it Discuss} mail archives directly.
Another natural extension is the idea of voting, so polling can be conducted 
in an authenticated and convenient manner.  {\it Notes} and {\it
Forum} have shown that a ``chairman
message'', shown to all users of a meeting or even just users
about to enter a new transaction is useful; adding such a feature
to {\it Discuss} would not be difficult.  Per-transaction or per-chain
``attributes'' have been requested for meetings which track tasks, so
tasks represented by transactions or chains could be marked as
``resolved'' or ``urgent''.  This would be more difficult to do in a
general way, but would probably be worth the effort.

Integrating a nameservice like {\it Hesiod} into the meeting location
process would simplify finding new meetings and would allow meetings
to be easily moved from one server to another.  At the moment this
information is scattered among all the {\tt .meetings} files.  Since we
are not sure that the
benefits from this are worth the cost of centralized registration of
meetings, this is still a topic for further thought.

Another open issue is that of server-side state.  Currently the
{\it Discuss} server retains no per-user state.  This greatly simplifies
its implementation, but it makes the {\tt .meetings} file more
important and does not allow one to discover who else is attending a
meeting or which transactions they have read.  Some people feel having
this information available would be useful, others think privacy
concerns preclude releasing such information.