Properly tailored software can facilitate online deliberation and discourse; we intend this document to serve as a specification for such software. “Online” in this context means that the software allows participation by means of standard Internet software tools, in particular commonly used web browsers and email clients. “Deliberation and discourse” are intended to indicate the software’s dual purpose: To facilitate not just reasoned communication generally (discourse) but also focused discussions that culminate in decision-making. To achieve these goals, the software must provide not only a means to discuss issues but also functionality by which decision-making can be undertaken. In a system in which power is shared by those it impacts, voting is generally the basic means of decision-making, and the software must therefore include a voting apparatus of some sort. Experience suggests that reasoned discussion is promoted when participants recognize that their conversation must culminate in a vote or some other means of decision, and voting and other means of decision are more credible in the minds of those impacted if they follow upon thorough debate of issues and positions. Thus, if our ideal of reasoned, collaborative decision-making is to be achieved, the software must not permit discussion and voting to exist in disjointed form, but must rather integrate the two into a seamless whole. The software we propose therefore seeks to achieve a unified discussion and decision-making environment.

We are cognizant that some individuals will disagree with the inclusion of some of the parameters by which the structure of debates can be controlled by those given authority within the software. However, our examination of the experiences of a number of online communities and discussion fora lead us to believe these structures for control need to be a possible implementation within the system — even as our values lead us to hope that certain of the proposed controls need never be exercised and to advocate the adoption of clear and strict guidelines governing under what circumstances, and with a requirement of total transparency, these control structures may be invoked. More importantly, we reiterate that we do not attempt, in this specification or its accompanying rationale, to state definitively how ICANN or any other organization should operate. Rather, we put forward possible solutions to perceived problems with current processes, with the anticipation of vigorous discussion and group decision-making by any organization considering their use prior to their adoption.

Anticipated Applications

Although we and many others in the Internet community have long discussed the need for innovative software to facilitate online discussions,[1] the needs of the Internet Corporation for Assigned Names and Numbers (ICANN) provided the specific motivation for this project. [History. Consensus-based policy. Cite to White Paper, Bylaws.] These seminal documents call for a vibrant group of network users discussing, jointly and in various subgroups, and coming to decisions on, the issues facing ICANN.

However, although current ICANN processes have been met with acceptance by online participants, it is not clear that ICANN’s decisions have consistently arisen from widespread agreement as to the best course of action. Furthermore, experience shows ICANN’s current means of facilitating discussion to be especially vulnerable to capture both by those who are for some reason hostile to ICANN, and by those with particular substantive agendas. The current discussion fora also frequently become mired in procedural rather than substantive issues despite participation by a large number of individuals who are presumably interested in deeper issues as well as errata.[2]

ICANN’s ideals of openness and transparency[3] in policy-making – and its nature as an international body composed of members and officers joined in cyberspace but separated by time zones as well as simple distance – pose special challenges in its pursuit of bottom-up, consensus-driven policy-making. Despite its still-unusual existence as an entity operating primarily in cyberspace, it shares with other organizations that have such ideals[4] a need to balance its desire to do its work in an open environment with the difficult realities of the logistics and problems of open debate. Experience with prior ICANN-related discussion fora suggests other procedural and substantive hurdles that are considered, along with specific code-created architectures that seek to be ameliorative, in greater depth below. We believe appropriate software can mitigate these difficulties, and the design we describe below is intended to do so.

Although our work has been catalyzed by ICANN’s experience, uses for this software environment are not limited to ICANN or its needs. Although ICANN remains unusual in that the issues it faces include questions of online policy, ICANN is not the first and will not be the last organization to attempt to leverage the communications potential of the Internet and consequently to face the difficulties of electronic discourse and debate. In an offline example, urban communities have called upon deliberative polling techniques to determine what policy choices their citizenry would elect given full information and the opportunity to debate the issues with one another.[5] Effective online deliberative discourse software could permit such efforts in large physical political contexts with substantially less cost than offline alternatives require.

More generally, we anticipate that the software we propose could replace other means of online communication, most clearly the email distribution programs listserv, majordomo, and their functional equivalents. The software could be used not only in an online decision-making process but also in more general contexts including education, collaboration in for-profit and non-profit organizations, and [?].

New Software is Needed

The Model of Web-Based Threaded Messaging Software

Standard web-based threaded messaging has already proven a useful, low-bandwidth means of communication for any number of online communities. We envision future deliberative discourse software that follows this model but adds features that permit greater flexibility in responding to the problems frequently encountered in online communities.

Alternatives to this model exist: many online discussions are currently conducted via listserv software which transmits and receives messages via email, and other discussions take place on Usenet via the distributed NNTP protocol. However, these methods of message transmission lack the user interfaces for advanced functions we believe will be necessary for effective online deliberation; email and NNTP-based discussions rely primarily on client-side software (email and NNTP readers, respectively) beyond the control of discussion operators and providing only a minimal level of centralized coordination or flexibility. We therefore focus on web-based software, although we certainly favor software that includes email, NNTP, and other standard interfaces wherever possible.

Existing Software

In planning a new software environment, we take inspiration from what we think of as the best of existing software. For example, we’ve been quite impressed by the message threading features of Hypernews[6] and Webboard[7]; their graphical means of depicting message flows is quite helpful for reviewing lengthy discussions. In contrast, the ColdFusion forum at Velvetcafe[8] provides an intuitive linear message viewing system less intimidating to new users of the software. Most flexible of all, the Slashdot[9] system allows either threaded or linear message review according to individual user preferences.

We also appreciate software that allows message viewing without registration, sign-on, or even pressing of a “Guest” button. In this respect, the Velvetcafe forum and Slashdot excel.

Finally, Slashdot is also notable for its filtering tools; since we think that such systems are central to self-governance of a community that forms around a discussion group, we [are very interested in this]. We don’t mean to suggest that Slashdot has all the necessary features, but it seems to us well on its way, certainly the closest of any of the packages we’ve looked at so far, and providing interfaces and mechanisms for additional rating systems we propose elsewhere in this document.

[Others? What software did they use in the AZ primary? We should have some discussion of voting software since we are adamant about needing a voting apparatus. ]

Weaknesses of Existing Software

Each of these programs contain features that are useful for community deliberation and decision-making, but these programs are not designed specifically for that task. Instead, we envision software specialized not only to facilitate the vital processes of online deliberation and decision-making, but also able to help a community hold to the values that underlie their discussion by hard-coding such values into the environment in which the community effectively exists. In particular, we believe the dedicated areas of the software’s user interface and database structure should be designed so as to engender the features we describe below.

Furthermore, general-purpose existing software systems are all lacking in that they fail to unite the multifaceted requirements of certain online deliberative processes. In particular, we envision software specialized to facilitate decision-making and thus to reinforce the system of operations of a “resolution-based” body. We therefore believe the software needs to support the features that follow via dedicated areas of its user interface and database structure.

Implementation Goals

Transparency and Ease of Use

While philosophical theory teaches that top-down, externally-enforced rules of participation are not without costs for deliberative discussion, experience suggests that some regulation will be needed for many applications of the software. However, we believe the rules of participation will be least oppressive if there is clear up-front disclosure of what rules exist, in what circumstances they can be imposed, and what recourse exists if there is protest.

Ease of Upgradability

To remain up to date, the software must be upgradeable and customizable on an ongoing basis. Recognizing that for certain far-reaching changes, the code will require modification, we propose that the code be written in a mainstream language following best practices for programming design, documentation, separation of presentation and “intelligence,” etc.

However, given appropriate code architecture, most reconfiguration and ongoing administration should be possible through an administration user interface rather than through modification of the underlying source code, for this approach will prove more robust and reliable. Such an architecture will also make easier the delegation of certain software administration roles to less technical staff and/or group operators.

Finally, to reduce the costs, complexity, and delays of future modifications to the system, we propose that the design be as forward-thinking as possible. In particular, the system should include a well-designed relational database for which it’s as easy as possible to add additional data structures. Furthermore, its user interface should provide interfaces for the addition of new modules or components, and software code should be logically separated into standardized components as fully as possible to promote future code reuse.

Flexibility

In general, the software should be usable on all sorts of clients; thus, it shouldn’t require Java, for example, and neither should it be unduly graphics-intensive. It should recognize the bandwidth limitations faced by many participants, and it should value accessibility from more potential participants over greater depth of participation for a few.

The software should comply with individual user preferences for message reading. In particular, it should allow either one message per screen or many messages per screen, per user preference, in order to better suit users with various speeds of network connections. The software should allow per-user filtering of messages (showing only those messages rated a certain way by others in the group; messages except those or only those from certain people; messages with or without certain words in their subjects or bodies) and should allow each user to save and switch between multiple message filtering and viewing modes for different purposes. As discussed in Promotion of Email Participation, below, the software should also allow users to receive messages via email according to individual preferences.

Finally, given the asynchronicity of the system, the system should allow offline reading of discussions via pages that are readily cacheable by appropriate client-side software.

Promotion of Email Participation

Each forum participant should be able to choose to receive messages via email, either in bulk (one long message per day) or individually, according to personal preference. It should be possible to elect to receive only certain messages via email, as discussed in Flexibility.

It may be necessary to restrict posting to the web interface – have to log into the forum to send messages. This would provide greater security (have to know password to get in; not enough just to spoof mail headers). But otherwise we’d favor allowing the posting of messages by email to further reduce the participation burden for low-bandwidth and frequently-disconnected users.

Key Features of the Proposed Software

The Basics

The software must support the basic features of existing systems: account creation, authentication, login, message retrieval, message posting, and some form of configurable voting.

The registration system should be as unburdensome and intuitive as possible, all else equal. However, it should also be extensively configurable on demand: to allow registration confirmation via email if desired, to ask additional questions, to cross-check new accounts created with PINs from an external database, to ask numerous additional questions of various standard formats if needed. Answers to certain registration questions should be markable as private (for example, a secondary authentication mechanism for security), while other answers (web page, whether or not representing affiliated organization in an official capacity, etc.) should be public and some might be user-configurable to be public or private (city, country, perhaps even real name).

Login should ideally use standard HTTP methods for improved client-side transparency on modern browsers; alternatively, the software might provide optional cookie-based persistent logins.

Message retrieval and classification should follow the flexible options detailed above in Flexibility, while posting mechanisms should take into account concerns about spoofing as described in Promotion of Email Participation.

Differential Permissions

We expect that many situations will call for multiple types of participant permissions. We recognize that there is serious argument over the legitimacy of such differentiation in the philosophical literature, but we believe the lessons of experience, and certain of the logistics inherent in online discussion, make this feature necessary. In the context of ICANN, it seems clear that not all members need to or should have the ability to edit the archives in response to technical glitches, to obtain the physical addresses of all discussion participants, or to create highest-level message groupings. On a more substantive level, the chair of a task group might be given certain supervisory rights, granting full participation rights only to group members, while other ICANN members could observe but not participate in the group’s discussion. A parallel conversation might be created for the observers, much as those attending ICANN public meetings via webcast often participate in a synchronous chat while watching.

We state that we believe such features to be necessary with a concurrent concern that transparency must be protected to maintain the integrity of the discussion system. In particular, there should be a utilization log detailing what permissions are extant and who enacted them; edits to the log should be extremely limited if possible at all, and all group members should be able to review the log and post complaints. Furthermore, discussion participants might also receive automatically-generated notification should the moderator take certain actions like changing discussion rules or excluding a particular participant. Experience has shown that a group may laud the exercise of such power in a particular instance, but we believe the need for public notice to be a requisite correlative occurrence if the online environment is to foster truly democratic discourse and decision-making. Furthermore, such notice might also prove helpful if a group came to question the decisions of its moderator.

Proposal Handling

To assist with ultimate decision-making processes, the software must includes provisions for proposing, seconding, debating, and voting on proposals. It should also include mechanisms for polling for and stating “inclinations” and “ready to vote” status to determine the sense of the group. All such options should be totally configurable – to handle multiple types of proposals, some of which do and some don’t require seconding, debating, a subsequent vote, etc. Rules of this sort should be optionally shared in a central “proposal handling rules library” so that one group can borrow the rules and procedures of another. There should also be provisions for proposals to change the system’s configuration, such as a vote to change the threshold for future votes.

We note that so many features, while essential to forming a system usable in all desired contexts, have the potential to overwhelm. To address concerns of excessive complexity, we suggest several preconfigured defaults in the “rules library” as well as “wizard” assistants to aid in the creation or modification of new rule sets.

Flexibility

We are cognizant of the danger that the existence of so many possible features might be so overwhelming as to be ignored. However, we anticipate that the default rules of the discussion space will implement very few of these features, but that groups will have these tools available in the software’s toolkit should their situation call for them.

For example, members of a forum could ignore the variety of provisions for voting on motions if not needed; a forum administrator might similarly keep permissions at their default or not publicize the archive. The software might provide levels of flexibility (“basic” versus “expert”), each level with its own set of variables. Under whatever specific implementation, the administrator interface might provide a number of toggle options to expose various additional pieces of functionality only as required.

Application of the Software in Likely Scenarios

Difficult issue, discussion open to all constituents

For such an application , the software would be configured in fully public mode, with registration open to all interested parties and with message and archive readings available without registration. Break-out groups might consider focused subissues, reporting results to the larger group.

Additional challenges or disruptions would result in appropriate tweaks to the software, as configured by a trusted administrator chosen at the start of the process. The administrator’s actions would be fully documented in an automatically-generated log file.

Difficult issue, limited to committee members but with real-time or asynchronous public observation

For public committee discussions, like the ICANN DNSO Names Council teleconferences[10], the software would be configured for full access only by committee members but for public review of the complete proceedings.

For the benefit of both committee members and public observers, the software might provide a “link library” with an organized means of retrieving key documents (or sections of documents), both inside and outside the discussion system. Ideally, the system would also allow annotations by anyone with appropriate permissions.

In addition to the standard voting features, the software might provide a “sense of the group” polling feature (configurable as anonymous or non-anonymous, per group or individual choice) to see if further discussion really is necessary on an issue for which agreement may already have been reached.

Finally, the system might also allow for public discussion in a separate area. If so, the system should facilitate direct links to specific actions taken by the committee, to specific proposals made by committee members, and so on. For real-time meetings such as teleconference webcasts, it might also be helpful to note the time at which each comment was submitted (or started) so as to optionally link it to the appropriate portion of an archived recording. For real-time meetings, it might be helpful to have a synchronous chat rather than message board; in that case too, links between chat logs and archived recordings would be helpful.

Quotidian issue, discussion limited to committee members but public observation possible

Unified format for links to outside references (i.e. cite relevant aspect of bylaws)

Possibility of classifying issues into predetermined categories and predetermined resolutions, then automatically calculating certain statistics about the process as a whole (i.e. statistics re frequency of various resolutions according to category).

i.e. a neighborhood deliberating what to do about zoning for a particular new business wanting to enter. Or on a larger scale. could be education for own sake or for public decision-making.

Educational offering open to general public

example in schools? Conflict re some issue of interest? Better yet, a non-conflict-based example? (Suggested example: Why IPv6 will be good– not controversial but also not well understood by many)

Comment on a draft document

In this context, the software should provide a means to load document into the system (or “suck in” a document from elsewhere on the web), then allow comment on particular sections of it. Should include some way to propose revisions to the document, discuss those revisions, provide alternative revisions, view a document according to suggested revisions by one or more individuals, and ultimately allow voting on revisions. The system should also facilitate group creation of a document, with voting on particular submissions for the next section (“which paragraph A do you prefer?”).

“Concern Center”

The software might be configured to provide a forum in which to register concerns or suggest alternatives with the process generally or with particular moderators for responses from others of the forum or perhaps staff of some related organization.

In this context, the software should perhaps allow anonymous posting to spare embarrassment at potentially unfounded concerns. But it should also provide an organized, linked space for responses – “no, that concern has been addressed by the following provision” or “actually existing applicable law is even worse” or “committee X looked at that question and concluded the following [link].” The software might also provide a semi-automated means to refer interested individuals to the appropriate public comment areas, experts, or staff best able to respond to particular concerns. Alternatively, the forum might feature key staff or office-holders posting in response to at least some messages for deliberation between policy-makers and the “electorate.” Such a system would require additional permission level for “specially empowered participant” to be able to, for example, reorder questions (perhaps without being able to alter them otherwise) to group multiple concerns together, which regular users can’t and without being able to do everything full administrators can.

In this context, the archive system becomes especially critical because archives would be of general interest to those with similar questions in the future. Thus, the software might provide an automated or semi-automated means of exporting organized responses to standard HTML for archival as a sort of FAQ (after further editing, if necessary). Also, the system should be configured to provide a robust search mechanism, both of structured archives and of current discussions and concerns.

Potential problems with discussion fora

In our experience with ICANN and other lists [cite JZ Sysopdom, etc.]…

Complicated problem with difficult issues on all sides

Experience shows it sometimes to be difficult to get a handle on a tough issue through standard messaging tools because traditional messaging systems provide no way to divide a question into manageable parts. Furthermore, the flow of messages can be overwhelming, providing no obvious place to begin nor any sort of informed leader to guide a newcomer through the process.

The anticipated software might provide a method for the structured presentation of ideas and debate. It would establish more than simple threaded messaging, rather adding “meta information” to aid in organization. At message post, a participant would self-categorize the submitted message, perhaps into categories including “I agree with message #x” or “I disagree with message #x” in addition to off-the-cuff classifications like “A new idea” or “Let’s put this question aside.”

The software might provide a means of rating, both by posters and by readers, the importance or insightfulness of individual messages and of a particular portions of the discussion/debate (“Does this matter?”). Then participants coming to the thread in the middle of discussion could choose a filter “See parts of this long discussion that other participants have rated as the most important” or “… that other participants have rated as the clearest restatement of the issues.” Note that these means of organization rely on the good faith efforts of participants, but experience with systems like Slashdot’s suggests that such a system of rating by peers is generally successful.

With this additional information as well as data the system already has about message threading, it would be possible to create a sophisticated and informative graphical presentation to provide an overview of messages. This system might be in part automated (i.e. number of replies in agreement and in disagreement with each message) and in part manual (brief title of each message or group of messages, perhaps distinct from subject) linked to appropriate messages. Note that “graphical” would likely still actually be primarily text-based, but with somewhat more elaborate a layout than a traditional threaded messaging display page.

Also, when working with a proposed text, the software might provide a way to comment on particular portions of it. It would then cross-reference comments across portions of the document – so that the original would come to have like “see comments on section n of this message” with automatic links in archives as appropriate.

Dispute on a particular question

The software might be configured for polling of various types. It should include flexible configuration options: multiple choice, short answer, rotisserie (“peer review” – someone asks a question, all participants answer, each answer is routed to another participant for an individual response, all messages posted to web site for subsequent discussion), and perhaps others.

The software should then provide comprehensive customizable reporting, with filtering/break-outs by relevant self-identification facts if so configured during registration. Cross-tab analysis and similar techniques might be especially helpful. For users so empowered by the group administrator, the system might provide user-customizable reporting or even raw data dumps with personally-identifiable characteristics removed for privacy.

Excessive posts from a single person

Code to filter messages by sender

Existing software generally provides no obvious means to do so on a group level; it’s possible to prohibit postings from certain individuals, but the process is far from transparent, places a high burden on systems administrators, and is not as readily reversible or investigable as might be desirable. We therefore suggest that the software anticipate this frequent problem and take appropriate steps to reduce its effect.

For example, in a discussion group using user-weighting systems, the software might automatically assign a weight chit of -1 to posts beyond the community standard for per-user post volume.

Alternatively, the software might, by default, hide all posts from particular people or show only posts from particular people, excluding in particular all or excessive posts from those who post more messages than permitted by group rules. Individual group members might override such defaults by choosing to be more or less restrictive than the standard group conventions, or one group member might defer to the preferences of another member via a proxy setting system, thereby lessening the load of deciding which participants should be filtered for excessive posts or for some other reason.

Establish norms against excessive posting.

The software might alternatively or simultaneously seek to create norms against excessive posting. At a minimum, on subscription to the list and/or on entrance to the discussion forum, users might be reminded of what behavior is expected and/or required of all participants. Furthermore, such messages should make clear what consequences are built into system and that rules will be automatically applied by the system

Users might also provide ratings of each other, a la ebay.[11] This is somewhat harder in many online deliberation contexts than for ebay because ebay users all share a set of values – that a good merchant ships the expected merchandise properly and promptly – whereas participants in a deliberative discussion might differ so fundamentally on substance that they find it difficult to impartially rate each other on content-neutral civility. Nonetheless, some overall rating of a user – perhaps average ratings of messages rather than of the user himself – might be helpful for certain circumstances.

Finally, the system might automatically generate messages to excessive posters notifying them that their behavior is outside of what’s expected and including statistics about such behavior. For example, such a message might note that x% of people posting in volume like the infringing user are screened by y% of readers, that a particular user is being screened by z% of people, or that a particular user posts more than k% of all posters.

Use code to prevent excessively many posts from a single subscriber.

This solution is generally best-received when bandwidth is the limiting factor, as when the system faces large attachments or a denial of service attack. In such cases, we believe it is generally accepted that system administrators quickly take all necessary precautions to protect the system; however, if the problem is not system overload but rather annoyance, there should be greater transparency. For example, the system might remove from the archives any message that more than x% of people filtered, or it might not archive posts from a single person after the first n per discussion.

More rigorously, the system might have a well-publicized but absolutely self-binding prohibition on more than n posts per day, week, and/or thread. Alternatively, the system might generate a warning on post, perhaps starting somewhat before self-binding prohibition binds, or perhaps instead of binding code prohibition.

Some sort of peer voting system might be used to make constraints bind if approved by some proportion of participants. The software would then present options to create binding limits on a number of levels of granularity (per day, week, or thread) or to send a “formal warning/request” to the poster letting him know that some proportion of his peers on the discussion forum find his behavior incompatible with their norms and would like him to change in a certain way. However, this sort of approach raises serious worries of the tyranny of the majority. [needs at least a full paragraph, likely its own section]

Excessive forwarded messages

On post, the system might allow a participant to mark a message as a forward, then give all users the option to filter out messages so marked.

Alternatively, forwarded messages might not require special treatment because forwarded messages count towards a subscriber’s total messages per time period; so, if there are limitations on total messages per time period, such limitations would also apply to forwarded messages, and these constraints might prove sufficient to constrain the behavior at issue.

Also, the software might be configured not to allow lengthy messages with many layers of prior responses. The system might generally accept only quoted comments from the last message the poster is responding to, perhaps unless specific steps taken by poster to confirm intent to do otherwise, as might be appropriate in certain detail-oriented discussions involving lengthy quoting. Alternatively, the system might require a particular ratio of original content to quotes, as is the case on many NNTP servers.

Multiple personalities by a single person

Formal system for alleging fraud

The software might implement a so-called “web of trust” whereby each user specifies who he knows, then the system lists who no one knows. Such a system presents clear problems – in particular, it disadvantages outsiders – but it might nonetheless be appropriate in certain contexts when coupled with other means of checking unjustified complaints.

A more lenient version of the system might provide a forum in which users could state allegations of fraud or deceit against other participants, then give each accused user a particular area in which to respond.

If some proportion of the forum finds a participant’s conduct offensive, fraudulent, etc., the software might provide some group voting mechanism for them to mark the participant in that way, then provide filtering options to hide by default all posters commonly thought to be offensive or conceivably to remove the offending user’s access to a closed group.

[Usenet used to have a totally crazily complicated system for determining the validity of votes (ie only one per person, etc) for newsgroup additions/changes/deletions. It involved a corps of people who were the vote acceptors, and I don’t know whether it’s at all still technically feasible, but we should probably look at it either way.]

Comprehensive logging of all available information.

In some contexts, it might be helpful to have records as complete as possible about users accessing the system. For example, it’s trivial to record browser type, OS, and IP address (reverse lookup’ed into a fully qualified domain name if available) of users accessing a system. Such information might support allegations of fraudulent multiple registrations; if the allegedly-duplicate users accessed the Internet from the same IP address or nearby addresses and used the same software, others might be relatively more suspicious of them.

Nonetheless, there would clearly remain significant privacy concerns with making this information public. Perhaps individual user information might initially be available only to administrators, and only made public when some proportion of the forum requests that the administrator answer a certain question. (For example, users might ask the forum administrator: “Is there objective technical evidence to support the claim that Participant X and Participant Y use the same computer?”) The software should therefore provide customizable privacy settings for each group.

Ad hominem attacks

Experience shows ad hominem attacks to be especially destructive to many online groups both for the distraction from core issues and for the long-term divisions among participants. We believe software can help reinforce social norms against such postings via a system of classifications and filters. Classifications might include “This message is helpful” or not, “… constructive” or not as messages are read by others in the group. (Such classifications would be similar to the way Amazon lets users rate book reviews posted by other users.) Then, filters might be selected, either by default or by individual users to show only messages generally rated as constructive and/or helpful by some proportion of messages. Alternatively, filters might adjust formatting on certain messages, perhaps by reducing the font size of messages frequently marked as “not constructive.”

The system might also reduce ad hominem attacks via automatic filtering of profanity. Such a system would be based on a “prohibited words list,” perhaps along with intelligence that looks for variations of profane words such as separation of letters with spaces or punctuation marks. Although these methods would be imperfect, they might nonetheless form an effective baseline. Furthermore, such a system might be extended to non-English communications via a system like Word 2000’s automatic language detection.

Spamming of participants

Experience with other lists has shown the serious problem of “address harvesting” whereby one participant sends unsolicited email to others via BCC or other techniques, bypassing all centralized rules and controls, causing much confusion, and making himself subject to recourse only via his upstream connectivity provider.

eGroups.com solves this problem by never displaying complete email addresses on the site but rather providing a trusted intermediary web-based sendmail script. However, depending on implementation, this raises the problem of facilitating excessive anonymity and therefore almost encouraging people to take extreme positions.

We believe one reasonable compromise is to mask email addresses as listed on the web but allow each forum participant to click on the name of another forum participant and send the latter a single message without. Since the system does so without revealing the recipient’s email address, this system prevents mass email to many multiple forum participants simultaneously. However, some might find it unduly burdensome, and it does prevent certain kinds of one-to-several communications.

Who Watches the Watchers?

[needs work]

Still to be answered is the key question of who configures the software. Although this is less of a problem if the software’s configuration is transparently documented, we are conscious that the underlying design of the software constrains behavior at least as much as its configuration in a particular instance, and we therefore want to assure that software designers and administrators are responsible and accountable.

Yet we would be disappointed to see a discussion group dominated by non-substantive questions like “should we or should we not enable option x?” We suggest that controversy over configuration could be reduced by employing a default configuration set by some trusted party. This of course assumes there is such a mutually-trusted third party, say a respected professor interested in related issues in the abstract but not in the particular dispensation of individual issues so as to reduce bootstrapping concerns.

We believe the problem of legitimacy is partly solved by relatively more perfect information – granting the general public full access to a “demo” discussion space for which all options can be adjusted so that those who are interested can see how a system could be setup to present alternatives to groups when procedural questions arise. Furthermore, documentation and experience would provide usual solutions for common problems; for example, a manual for administrators might read “Are you having trouble with an obscene poster? Try this. Can’t get people to focus on the subject at hand? Try this.”

Finally, there remains a question of whether majority vote among a potentially-dysfunctional discussion group (with problems, per above, potentially including fraudulent multiple personalities of a single person) could truly validate configuration changes. [It’s not clear that it could…]

Ben Edelman

Berkman Center for Internet and Society

Harvard Law School

[1] Zittrain, Jonathan. “The Rise and Fall of Sysopdom.” 10 Harv. J.L. & Tech. 495 (Summer 1997). <http://jolt.law.harvard.edu/articles/10hjolt495.html>

[2] ICANN’s mailing lists, in particular the list operated by the General Assembly of the DNSO and also the various comment receiving addresses setup to receive feedback on some issues, have lots of messages, but remain mostly stuck on procedure.

[3] Department of Commerce White Paper on the Management of Internet Names and Addresses. <http://www.ntia.doc.gov/ntiahome/domainname/6_5_98dns.htm>

[4] Cite organizations with openness and transparency challenges and/or scholarship on the subject