Berkman Center for Internet & Society at Harvard Law School
Online Deliberative Discourse Research Project
Phase 1: Specification for Online Environment Platform
The Internet’s speed and efficiency as a communication tool for the global exchange of information and personal expression has raised expectations about its potential for group decision-making. The range of possible applications is vast: from a small panel of jurists considering a pending case, to a multinational corporation’s shareholders debating a merger, to a nation’s citizenry voting on candidates for leadership. The utility is easy to imagine, but key questions remain before the promise can be made real. What rules and tools would an online community need in order for it to engage in effective, meaningful debate so that decisions are generally accepted by its members? Can they produce a better-informed and more responsible constituency? Can online – and increasingly offline as well – communities govern themselves – online?
With the experience of thousands of years behind us, our sense of how traditional communities operate is well developed. No doubt, evolution of our social structures and our own evolution as a species are intertwined. In contrast, online communities are only a few decades old, and the chasm of difference evident between the two leaves us without full benefit of the lessons of experience. For example, members – or citizens – of self-organizing online communities come to one another and communicate as equals, stripped of many of the social cues present in physical encounters. Much of the effective “social glue” that binds physical communities is altogether lacking in their online counterparts. So are various forms of physical coercion that keep traditional geo-communities together in times of significant disagreement and conflict.
With the administration of ICANN as our impetus, the Berkman Center for Internet & Society considers online deliberation and proposes a design for its implementation. However, the importance of the questions we address extends far beyond the issues of online governance raised by ICANN. The growing number and importance of online organizations and the increase in offline organizations (including governments) moving toward some online operation suggest that the questions we asked are becoming universal, and that interest in solutions we offer may be widespread, as well. Accordingly, we sought to shape a solution whose utility extends naturally beyond ICANN.
Which technologies provide robust management tools that are also compatible with easy access and widespread use? We present our answers in what we think will be the most useful form: a conceptual software specification describing the principles underlying deliberative discourse and the features and tools we believe would best facilitate it in a networked environment. Many of these tools are already in use, but we suggest improvements and other modifications to make them better suited to focused deliberation. We seek through our analysis and in the details of the code’s implementation to advance both the discussion and the art of online discourse and decision-making.
We intend two primary uses for this specification: as the seed for wide, practical discussion of online governance, and as the basis for a software project management team and its coders to prepare a technical implementation plan, which could then be built and disseminated to the entire cyberspace community.
The promotion of online debate and decision-making is a problem of governance: how may an online community appropriately rule itself? How does it balance the freedom to communicate and participate with the maintenance of a productive and encouraging environment that attracts and retains members?
Although open communities in cyberspace are usually formed by those who share like values and a desire to use their shared online spaces for mutual enjoyment, virtual communities rarely achieve long-term peaceful cohabitation, much less the ability to inform themselves or discuss and decide important issues.
The very nature of online discussion contains this signal paradox: although greater anonymity online distinctly encourages both valuable conversations among those who likely would never interact offline and the recognition and respect of voices which would otherwise never be heard, it also fosters an irresponsibility which deeply undermines online discussions. Flaming, off-topic barrages, arguments about process, and endless fruitless discussion without decision-making are endemic. Methods that have been successfully used to preclude or limit these problems in offline debate typically rely upon features of shared physical space, making them inapt for the online context. By necessity, online groups resort to moderators and filtering: to refuse to use these methods of control and thus to tolerate high proportions of obnoxious and irrelevant communication guarantees that many members will abandon their participation in frustration.
Most self-organizing online communities reflect a judgment we share: that democracy is the best means by which cyberspaces may be governed. The demonstrated nature of online communities as places where communication and discussion are valued suggests that deliberative discourse (i.e., reasoned communication that is focused and intended to culminate in group decision-making) is the form of democracy most prized online. Cyberspace also naturally supports another feature that is highly desirable for deliberative discourse: equality among the participants, including especially an equal ability to disseminate information to contribute to reasoned decision-making.
Governance of online communities requires the consent of the governed in a way and to a degree that physical communities do not. Coercive power over the body of a participant, the ultimate if often unspoken tool of offline governance, does not exist over the incorporeal citizens of online communities. Control by those in authority online ends, as does that of offline counterparts, at the borders of whatever spaces comprise the polity. However, unlike in offline jurisdictions, online authorities have no significant means by which to force their citizens to remain in those spaces. This is a difference at the most basic level: not even the presence of members of self-organizing online communities is assured. For any reason or no reason at all a member can simply leave the community, sacrificing whatever social investment he has made there, usually without financial or physical loss. This essential fact of online participation demands a structure that is encouraging, egalitarian, productive and rewarding. If the process of online discourse and decision-making is unpleasant, elitist, non-productive and/or time wasting, then people will vote with their browsers by failing to log on.
Our report attempts to address real problems of online decision-making. It recognizes and designs barriers to the true miscreants in cyberspace, those who seek to disrupt and derail rather than to cooperate for the good of shared online communities. Our primary focus, though, is given to the more serious problem of large numbers of well-meaning and unselfish members who try to cooperate and discuss constructively but still find themselves unable to reach consensus or other acceptable forms of decision. Here, our effort is to design the online structure to support, reward and make their participation effective.
In considering which features and characteristics promote deliberative discourse, we examined both offline and online experiments with democratic decision-making and the tools used in those contexts. We chose many online tools that have already demonstrated success and designed adaptations of offline tools that seem promising. In shaping the environment and tools for online discourse, we remained vigilant to the danger that perfect control would defeat our overarching goal of promoting democratic decision-making. We are explicit about the values we pursued and how we determined which to privilege when they conflicted with one another. We do so to maintain our own accountability, but more importantly to enable organizations considering adoption of these tools to determine whether they share our philosophy and our judgments balancing these values. The tool set we have designed is flexible and can be implemented in any number of ways, permitting organizations to make their own determinations of priorities and balance suited to their particular philosophies and needs.
The Internet is perceived as the next great leap forward in political and organizational interaction. However, the technology on which it rests is complex and often hidden from view. Computer programmers are in some respects the cyberspace equivalent of politicians’ smoke-filled back rooms. If political processes are to move online, it is essential that the code, which facilitates and constrains the discussion and measures the community’s opinion, must be as open and transparent as the systems of democratic government that we most admire. Public interest sponsorship of such code as described in Appendix D is critical if online deliberation is to become a trusted and valuable tool of democracy.
For additional information, please contact:
1563 Massachusetts Avenue
Cambridge, MA 02138
Berkman Center for Internet & Society at Harvard Law School
Online Deliberative Discourse Research Project
Phase 1: Specification for Online Environment Platform
Table of Contents
Berkman Center for Internet & Society at Harvard Law School
Online Deliberative Discourse Research Project
Phase 1: Specification for Online Environment Platform
This conceptual specification describes the characteristics and features of a software platform that promotes online deliberative discourse, which we believe is the optimal means of decision-making for online communities. Our efforts have been specifically triggered by and in some ways tailored to the needs of the community of the Internet Corporation for Names and Numbers (ICANN); however the need for innovative software to facilitate online deliberation and discourse (grounded in solid political theory) reaches well beyond that organization. Although many of the needs we take as examples are drawn from the ICANN context, other existing online bodies could benefit from improved online discussion space, and we believe there will only be increasing need for such tools as more offline entities move portions of their deliberative activities online.
Deliberative discourse is reasoned communication that is focused and intended to culminate in group decision-making. Since the start of experiments in deliberative discourse dating back as early as Athenian democracy, the methods have built on the principles of equality among participants and on learning before choosing to assure well-informed decision-making. In the past, such processes have generally taken place in person, but we focus here on online communities whose primary means of interaction is through the use of web browsers and email clients rather than in offline encounters.
A software platform that seeks to promote deliberative discourse processes online must provide not only a means of communication but also methods by which that communication may be focused, as well as integrated functionality by which decision-making may be undertaken and recorded. Innumerable opinions and philosophical models exist regarding the particular mechanisms necessary for achievement of these ends. These opinions reflect the diversity of backgrounds and values of those who have experimented with deliberative discourse. We do not attempt to judge among the competing models or to privilege any one position above others, and we especially do not presume to state definitively how ICANN or any other organization should operate. Rather, we put forward a variety of tools and possible solutions to perceived problems with current processes, and we anticipate vigorous debate and fine-tuning by any organization considering adoption of this proposed platform.
In considering which features and characteristics could promote deliberative discourse, we examined both the offline and online experiments in democratic decision-making and the tools used in those contexts. The online world is, in fact, a new venue in the history of deliberation; its size, diversity of membership, and lack of physical constraints make traditional political science remarkably inapt. Many of the principles developed over the history of deliberation rely on face-to-face debate, implicitly assuming that the inevitable physical proximity of those with competing interests will provide an impetus toward deliberation and compromise. However, in online spaces, people may interact with little concern that they might ever confront each other physically. The greater anonymity possible online can thus encourage irresponsibility, but the correlative paucity of social cues regarding offline community standing can also enable meritocratic debate on a scale never before possible. The dynamism of the online community, its continued dramatic growth, and the rapid changes in online culture render existing scholarship to some extent inapplicable.
Due to the novelty of the problem of online decision-making, no previous or current experiment was entirely applicable and no existing software was comprehensive for the needs we perceived. We therefore focus on approaches that promote values we think important, and we adopt and tune such approaches in this specification.
Because online environments exist only as the result of the software that creates them, those who create code have inherent power that should be accompanied by accountability. Values chosen by the coders, whether consciously or by default, will inform the environment the code creates. We therefore believe that in working on a project such as this software specification, it is vital to describe explicitly the values sought to be served so that our choices can have the integrity of being self-conscious and more accountable. Others may judge our efforts both by whether the proper values for prioritization were selected and by whether that prioritization was successfully accomplished in the proposed software design. However, we believe that organizations disputing our values may nonetheless benefit from reviewing this specification so as to make appropriate adjustments; making such determinations may help them define and pursue their own priorities. Thus, we would consider these conclusions to have served well any organization considering online deliberative discourse even if they operate only as straw men to be attacked – and perhaps rejected – in vigorous debate.
Certain of the values that inform this specification were adopted with little or no consideration of competing alternatives. In particular, we embraced democracy and deliberative decision-making without weighing competing models. We sought to design software that reflected our belief that those affected by decision-making should, wherever possible, have input and some degree of power in the decision-making process, including a far-reaching ability to express their positions, concerns, and, if necessary, dissent. Further, a democracy based on public deliberation presupposes that citizens can decide through discourse what laws and policies they ought to pursue; it presupposes further that each person possesses the deliberative capacities necessary to participate in an environment where reasons are publicly exchanged and debated in the course of decision-making.
Beyond the decision to promote democratic decision-making, a number of other value determinations remained. No project may equally prioritize all values, and to determine which values will be privileged is inevitably also to determine that other values will be sacrificed where necessary. In weighing competing principles, we looked both to online and offline experiences with democracy for guidance, and we considered what shared values an online community might hold.
The set of people who are potential members of online communities is large and growing. Access to the Internet remains a limiting factor, but one of continually decreasing significance. To further the goal of opening online communities to as many people as possible, it is vital that no unnecessary technological burden on access and participation be created. Thus, where there is a conflict between using the most cutting-edge technology and permitting access by a greater number of people, we have favored greater access.
We have already stated that we concentrated on reaching those who access the Internet using web browsers and email. Alternatives to this model exist: many online discussions are currently conducted via “listserv” mailing list software which transmits and receives messages via email, and other discussions take place on Usenet via the distributed NNTP protocol. We recognize that some of these alternative means of access would be less bandwidth intensive, and thus more accessible to some participants, than using the World Wide Web and email. However, technological barriers exist not only in the form of mechanical limitations such as bandwidth availability, but also as differences in knowledge and ease of use.
In particular, low-bandwidth alternative 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 they therefore allow only minimal centralized coordination and flexibility in configuration. In contrast, an enormous number of new Internet users enter cyberspace using the World Wide Web (the Web) and many even consider it the entirety of the Internet. Furthermore, the Web provides a user interface that many people find more comfortable and effective than solely text-based communications. Although to construe the Web as the Internet is a misperception, to downplay its current importance would, in our judgment, be to foreclose participation by a large and growing Internet population.
Access barriers also exist apart from technology. Although online communities exist whose membership is primarily or even entirely composed of citizens of one nation, we consider here online communities whose membership is global. As many currently participating in such communities have noted and commented upon, the status of English as the dominant language of much of the Internet effectively, albeit not purposefully, excludes those who do not know English and often marginalizes the online speech of those who are not fluent in written English. Synchronous, automated language translation would be extraordinarily useful for this problem, but current translation software is not yet sufficiently developed to be viable for this context, and we see no other viable technical solution at present. However, as discussed in greater detail below, the software considered in this specification will be written in as modular a form as possible. One of the new features we hope will be facilitated by this modularity is translation software, once it is reasonably capable of supporting the richness of online discourse.
The decision to privilege preserving online discussion over unfettered speech and access by participants is one we did not take lightly, and it is one with which we expect some vocal disagreement. Theorists inform us that in the ideal discourse, no participant has more procedural or substantive power than any other. Traditional scholarship in this area reflects a far greater concern about capture by aggressive discussion moderators than about undirected or disrupted discussions. We are cognizant that some individuals will disagree with the inclusion of any parameters by which online deliberation can be controlled by those who are given authority within the software.
In our opinion, however, prior online experience teaches that tyranny by unknown or otherwise unaccountable individuals is much more frequent and disruptive than is tyranny by those accountably given power. Should a participant given power by the software and the group abuse it, the group can vote the user out of power or effectively end his power by moving the discussion elsewhere. On the other hand, the anonymous, or effectively anonymous person whose participation is unfettered and unfetterable under existing software parameters can ruin an online space for all others. Our firm belief in the importance of equality of voice and power for all participants is what paradoxically led us to the conclusion that the software should enable the empowerment of procedural leaders and the implementation of procedural controls. Our values lead us to hope that certain of these proposed controls need never be exercised, and to hard-code transparency and accountability of their use into the software, but to be confident nonetheless that they should be available if needed.
The short history of online interaction is filled with examples of online discussions that began with great expectations of reasoned discussion and ended with disruption, aimless procedural arguments, sparse participation and even less substantive discussion. Few empirical studies have even attempted to determine why continued reasoned discussion is so difficult to sustain when taking place in online environments, but most seem to agree that the relative anonymity and lack of the accountability of physical proximity of online discourse are the chief factors. Indeed, the connection between anonymity and the temptation to disrupt has been recognized at least since Plato. This specification therefore seeks to compensate for these weaknesses. However, we also note that the lack of accountability that accompanies anonymity has at times been beneficial to open debate.
The most common problems seen in the online communities we examined were dominance of the discussion by a few high-volume participants; disruption of the discussion by a few people or even just one individual; a lack of civility and of clear procedural and behavioral norms deterring participation by some and encouraging others to act at the lowest common denominator of behavior; high turnover of members and random postings by temporary participants; and a lack of focus on substance due to constant discussions of procedures or off-topic subjects. We believe that none of these problems is inevitable in online discourse and that a carefully crafted online environment can promote social norms and otherwise deter the behaviors that lead to these problems. We recognize that the implementation of structures of control can repress open debate even as they may try to sustain it, but with appropriate transparency and implementation guidelines, we believe that participants may have confidence that their voices are being heard equally and without substantive censorship.
Many of the administrative controls that will be built into this software environment will reflect the particular representative nature of ICANN, the community on which we are most focused, as well as the more common logistics of online environments. Multiple types of participant permissions will be useful, for example, for discussions that are open to the public for review but not for public posting. Those with leadership roles in ICANN, such as the chairs of task groups, might have supervisory responsibilities that require greater administrative powers. For example, not every member will need or should have the power to edit the archives in response to technical glitches or to create or delete message groupings or discussion areas. Many members will be relieved that their email address and other identifying characteristics are not readily available to all other members but can be accessed only by those whose roles within the organization make them accountable for the misuse of such information. Online communities with hierarchies less complex than ICANN, or with less need for administrative controls, can choose to implement only those controls appropriate for their purposes.
In part, the structures of control we include below are of a technical nature and relatively common in online discussions already. For example, we recommend certain forms of filtering, ranking of submissions, moderation by a selected participant, and archiving. Others we suggest are more of a norm-establishing nature, such as requiring enrollment in a “netiquette” course before registration and limiting participants’ anonymity. We also include a number of tools and configurations specifically designed to be useful for addressing forms of disruption commonly seen in online discussions.
For a community to be functional, members within it must accept that they have obligations to it as well as rights from it. Our goal is to allow the community to develop norms beyond what it already shares and to have those norms coded into the software and apparent to participants; this will allow participants to change their groups’ norms, if they choose as a group to do so, as well as allow individual participants to learn about group behaviors and expectations that may be unfamiliar. Social pressure is a strong force in offline communities, and we think it is a pressure online communities can profitably bring to bear on their participants as well.
Code is the first element of control in the online environment, and it is rarely if ever written at the explicit direction of the members of the community that uses it. Because those who write and administer code wield a critical source of unelected power and control, those who are impacted by the code but do not have power over or within it will be justified in having little confidence in the legitimacy of the system if the power structures within the code are not transparent in creation and action. Trust by users that their environment reflects their values is vital to the success of online discourse. Without such confidence, users will lose incentive to participate, and the discussion will suffer as fewer and fewer voices are heard. Thus, the power of those wielding code can be illusory over the long term in that the power can only reach those who choose to put themselves within it.
Continued acceptance by the community will be predicated on evidence that the environment of the online space itself is reflective of the community’s interests and needs, and that there exist mechanisms within the online space itself to adequately address such interests and needs. Thus, our belief that control features are necessary to online discourse actually increases our concurrent concern that transparency be assured in order to maintain the integrity of the discussion system. The first aspect of this transparency is the explicit description, here and in the eventual online user’s manual, of all of the controls the software permits and the circumstances under which the community has determined that they be exercised. We describe these controls below, and we suggest some circumstances under which they might be implemented. A fuller description of these conditions must be determined by the particular online community both initially and as experience teaches.
However, description of the powers that may be exercised would be insufficient to engender confidence without accountability in their use. By documenting the use of such powers in a freely accessible online record, transparency in their use is preserved. Thus, the design we propose includes, among other features for these purposes, automatic archiving and logging features that create and preserve a record of all submissions to discussions, whether filtered or not, and of all administrative actions, such as the filtering of an individual or message. These comprehensive archives will be readily available for review by anyone who chooses to access them alongside archives that reflect but do not record such exercises of control. Should members of the community allege that those empowered by the software are abusing their power, a full record will be available on which to judge the use of power.
Deliberative democracy presupposes some degree of plurality among community members, and that diversity of interests, convictions, and ideals is a condition that many international online communities achieve with no effort. However, in the context of online communities, special challenges arise in pursuit of bottom-up, consensus-driven policy-making because of the anticipated international composition of membership with its resultant separation both by time zone and geographic distance. Deliberative discourse must also presume that community members share a commitment to the discourse as a means of problem solving and decision-making even though they may not share the same opinion as to the right outcome. The software’s design both reflects that presumption and seeks to solidify it.
Diversity must be reflected in the discourse by which the community’s membership comes to decisions; for decision-making in a democracy to be legitimate, each participant, no matter how different his opinion from the group’s ultimate decision, must feel that the decision arose from “free deliberation among equals.” In particular, each participant’s voice must be able to be heard, meaning that each member should have equal standing to put forward issues for the agenda, to suggest solutions to shared problems, and to advance reasons for and criticisms against proposals under consideration. All voters should have votes of equal power, both on substantive issues and on the content of agendas, the ground rules for debate, and other procedural issues. The repression of minority viewpoints by the majority and the tyranny of deliberation by a vocal minority are equally inconsistent with deliberative democracy.
These prerequisites may sound utopian in the abstract, but their goals of equality in participation and access are in fact achievable in many contexts. In many representative organizations, for example, the community itself engenders differences in administrative power through exercise of the equal innate power of each member in electing representatives empowered to act on behalf of all. We do not deny that social inequality exists and will remain, or that differences in status within communities will naturally arise. Some of these differences will have to do with the quality of the ideas put forth by individuals as judged by their peers; others will arise by virtue of differences in online communication skills and charisma. However, we believe that the software can help engender values that recognize the inherent equality of all and discourage acceptance or rejection of ideas simply due to the identity of their proponents.
As has been widely discussed, the Internet removes many of the cues that we use in the physical world to evaluate others. Many of the conversations and communities that gather online do so because of shared interests and affinities rather than the physical or socioeconomic identities that frequently govern offline interaction. Judgment of others in the online space is generally based on their contributions to the community, whether of work, such as the writers of FAQs, or of ideas or manner, and is less subject to capture by social, gender, hierarchy, or cultural conceptions of superiority. Unlike the physical world, where status and reputation are often shaped by a complex of social, economic, political, and hereditary considerations, in the online world reputation and status can often be gained only through the accumulated appreciation of others.
For decision-making through deliberative discourse to be legitimate, participants must be confident that decisions result from “no force except that of the better argument.” Although no piece of software can erase all relevant differences, the platform we propose seeks to diminish their significance in the online discussion and evaluation of ideas. In particular, we establish limits on the contact information available to participants about one another so as to de-emphasize offline status cues, as well as to combat the address harvesting which currently deters some people from participating in certain bulletin board systems.
We have sought to foster participation by a wide group through a number of mechanisms. For example, among other means to minimize the financial and other costs of participation, we choose asynchronous interaction and low-bandwidth alternatives where doing so does not overly sacrifice the quality of interaction possible. The software seeks to preserve space in the discussion for a wide variety of individuals and ideas by having controls available for implementation if dominance by a vocal few becomes problematic. Finally, one role of moderators, who may be appointed by or for a discussion group, is to ensure that the diversity of viewpoints has an opportunity to be expressed and to reiterate norms of discussion that promote free and equal expression by all.
In the context of an online community that must make far-reaching decisions that will impact many people, as is the case for a complicated and important resource like the domain name system, deliberative groups must have accountability both of participants and of elected leaders. Experience suggests that anonymity not only encourages disruptive behavior in discussions, but also may lead to fraud in the promotion of unsupported viewpoints, in the libel of individuals, and in voting. For equality of power to be real, there must be safeguards ensuring that each participant is a unique individual and has the power of only one vote. Authentication of identity is a necessary part of such accountability and is thus extremely important when a discussion moves to deliberation and voting and where elements of a unique identity engender certain voting privileges, such as eligibility to select regional candidates.
True identification of unique individuals in cyberspace remains a complicated and difficult technical issue. Even offline authentication is not without complexity; the cost and expense of reliable authentication of a globally distributed constituency is beyond the budget of most organizations, and further difficulty follows from the different identifying documents used in different nations. In the context of ICANN, authentication of regional residence is key to certain types of voting and will be accomplished by sending a postal mailing to membership applicants to verify location. The distribution of confidential user codes via these postal mailings and comprehensive logging of all available technical information about registered users can be helpful in resolving disputes and addressing problems and allegations of fraud and other misdeeds as they arise. Following this model, we privilege authentication of individuals over absolute privacy where the two conflict, as described below.
However, participation under an alias, or an identity that is unique to a person but which is not publicly known to be associated with that person, can be liberating for the individual and enriching for the group. Stripped of institutional affiliations and the responsibilities and burdens associated with them, individuals can speak freely without fear that their individual voices may be mistaken for those of their institutions, and they are similarly free from risk of reprisals by their institutions. The knowledge such individuals can share under an alias may prove illuminating to a group’s discussion, and we conclude that it should therefore be encouraged.
The balance we find most appropriate is to require individual user information, but to make it available only to administrators and to prohibit its further disclosure except under certain specific and unusual circumstances. No effort will be made to discourage community members from revealing personal information, including in their registration biographies, but the default for the environment will be to protect individual privacy.
Documentation here has three main purposes: 1) the establishment of transparency in the regulation of the online environment, 2) the group creation of a history of discussions and decision-making, and 3) the enrichment of the discussions. To further these three purposes, the software will automatically generate logs of administrative actions, comprehensive archives in addition to archives reflecting whatever filtering or other editing may have taken place, and a library of documents and background materials referred to during discussion. Although the creation and maintenance of these three forms of documentation will be a substantial task for the software and its administrators, we believe the resulting documentation is well worth the burden.
2.7. To be successful, the software must above all else serve the online community’s needs now and going forward.
In designing this software, our goal was to serve the interests of ICANN and other online communities, not to further ideological platforms of our own or to attempt to design software according to academic theories of political interaction. If the software is not helpful to those groups, it will be a failure.
We hope that the need for many of the filtering and blocking controls that we include as possible features of the software will never arise. However, as described elsewhere in this document, experience suggests that at least some of these controls may be needed, or at a minimum, that it will be valuable to have the threat of their use exist for its deterrent effect.
Flexibility is a key aspect of utility. Online communities will continue to need to adapt to reflect technological changes as well as changes in their constituency, and their online environment must be designed to accommodate both the current uses and discussion formats, and those to come. In the context of ICANN, the software should facilitate both the purely online deliberation and online discussion in conjunction with offline meetings. In other deliberative contexts, from local community decision-making to election support for national candidates, the software might prove helpful as a forum for discussing difficult and contentious issues. Furthermore, the software may be used in contexts beyond deliberation, including distance learning, course support, and other educational purposes. While we hesitate to add features primarily useful in these alternative contexts, we note that few such additional features would be needed; a complete implementation of an environment for online deliberation and discourse would also prove a useful space for educational and other purposes.
The expression of reasoned principles through discourse may occur on many different levels and involve vastly different numbers of participants. For example, there may be need for discourse related to specific tasks, not all of which occur in a public forum. A small working meeting might take advantage of a shared virtual white board to annotate jointly a central document, with markups visible to all others simultaneously. Some groups might prefer privacy for their initial efforts or for the preparation of material that is expected to undergo frequent revisions before presentation to the public while others activities have no value without substantial participation (i.e., election of community leaders).
Thus, we have designed this software specification to allow users and groups to set their own preferences and use the feature sets they design in many ways. However, defaults for types of discussion groups and particular tasks will be created so that there is a baseline from which groups can make changes, and to try to prevent procedural arguments and discussions from swamping the substantive debates which are the very reason for the existence of the discussion areas.
Another key aspect of utility is longevity. To continue to be useful to online communities, the software must be able to change at the pace of the Internet. Conversation may never be outdated, but software can be outmoded in months. If and when the software is commissioned, we will seek to have its structure be as modular and easily upgradable as possible.
Over time, a few formats have emerged as the most popular templates for discourse by online communities. These are threaded discussions, message or bulletin boards, and text-based virtual environments, along with combinations of one or more of these forms. Standard threaded messaging has already proven a useful low-bandwidth means of communication for literally thousands of online communities, but improvements could substantially enhance the experience. The deliberative discourse platform we describe here builds on this model but adds features which are useful for community deliberation and decision-making and which permit greater flexibility in responding to the problems frequently encountered in online communities.
At a minimum, the platform must support the basic features of existing systems: (1) account creation, (2) authentication, (3) login, (4) message retrieval, (5) message posting, and (6) some form of configurable voting. We have incorporated all of these basic features along with certain others, notably optional architectures of control, that we believe will promote deliberative discourse in the online environment. We are cognizant of the danger that the existence of many possible configurations of 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 and options available in the software’s toolkit should their situation call for them.
Because we have privileged basic accessibility for more participants over greater depth of participation for a few, the software should be realistically usable on as many Internet clients as possible. Thus, for example, it should not require Java or be unduly graphics-intensive. 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.
Individual users should be able to configure their system preferences for message reading to suit their liking and their access, and to have sets of preferences for use with different groups or for different purposes. 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, and the system should similarly allow offline reading of discussions via pages readily cached by appropriate client-side software. The software should be configurable to display either one message per screen or many messages per screen to better suit users according to their network connection speed. Finally, each user should be able to specify her own criteria for filtering messages on a number of bases specified later in this document.
We appreciate and will replicate software that allows message viewing without registration, sign-on, or even pressing of a “Guest” button. In the absence of security concerns, we would favor allowing the posting of messages by email to reduce further the participation burden for low bandwidth and frequently disconnected users. However, posting should require registration and login via the web interface because this approach thwarts the “email header forge” tactic that would otherwise circumvent email posting security systems.
To register for participation, users should first be required to read and acknowledge a description of the expectations of the community of users. Terms for such participation obligation agreements are described in Appendix B.
Following completion of these few screens, users will begin the registration process. In designing the registration interface, great attention must be paid to making it as unburdensome and intuitive as possible. The plurality of membership, especially in the native languages and nations of its participants, mandates that as many of the controls as possible be represented with symbols as well as words, and that directions and basic help be provided in multiple, widely-spoken languages. Registration procedures should also be flexible; for example, registration confirmations should be available by email. Furthermore, each discussion group implemented under the software should be able to specify its own questions and format for the registration system; the software should provide administrative, configuration, and user-interface functionality that makes these additions seamless.
The interface will ask users for information regarding their offline and online identities, including a working email address. A biographical file and associated page will automatically be generated for each individual by the software. This file will contain selected information submitted at registration and will later be linked to posts and other forms of discourse participation. A new user will be able to elect some brief description of himself and his background to be available on his biographical page; there will not, however, be any designated space on that page for contact information. We recognize that biographical information may serve to undermine the equalizing effect of online interaction, but we also recognize that this information cannot and in our opinion should not be actively withheld.
To accompany the information specified by the user for his biographical file, the software will also automatically generate information about his participation in the online environment. The discussion groups in which he has participated and any leadership roles he has undertaken will be listed, as well as any membership in subunits of the community. Current censures by moderators or administrators will be listed with the behavior that led to them and the length of time until they expire.
However, answers to certain registration questions will be markable as private (for example, a secondary authentication mechanism for security), while other answers (web page, whether or not representing an affiliated organization in an official capacity, etc.) should be public. Some might be user-configurable to be public or private (e.g., geographic location). However, much of the biographical file will not be accessible to general users, and all contact information and “real” names specifically requested by the registration interface should be kept confidential by the software and its administrators. Inspired by ICANN’s needs, the software will also be configurable to verify the validity of email addresses and to crosscheck account registrations with records from an external database.
Concerns about email address harvesting and consequent spam deter some people from participating fully in discussion lists. Current attempts to prevent such harvesting include adding obviously false strings to reply-to addresses as well as broader system-wide remedies. This software should address the issue by masking email addresses from participants but allowing individuals to click on one other forum participant at a time to send a single message without revealing the recipient’s email address. The recipient will then be in possession of the sender’s address, and may decide for herself whether to respond and reveal her address in turn, or to ignore the message. We recognize that this increases the transaction costs of both appropriate and inappropriate one-to-one and one-to-several communications. However, we believe the burden is justified because it solves a serious problem of address confidentiality and because participants wishing to communicate outside of the online environment will remain able to do so.
Configuration of discussion areas, for all that it seems a dry subject, can be a surprisingly loaded topic. Controversies over procedures have destroyed many online discussions before substantive controversies were ever reached. To preclude endless circular discussion over correct procedures, the software should include a set of default protocols for discussion scenarios, and when a discussion group is formed, its original procedural rules should follow from the scenario it most resembles. The formulation of these default procedures will not be easy, but such procedures will greatly benefit online communities that later wish to focus on substance rather than devise detailed rules appropriate to their task.
Once a new group has been formed, it will have an initial period during which a majority vote may change some or all of the procedural rules set as defaults. After that initial period, discussions of further changes would be discouraged absent some triggering event like a major disruption or an allegation of misuse of power by a moderator, and an actual change would require the assenting votes of most users, perhaps seventy-five per cent of a group’s active participants.
Configuration options should facilitate the many uses of the software. 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.
Each group should maintain a FAQ (“frequency asked questions” list) documenting answers to common questions and concerns of new and existing participants. The FAQ for a particular group should also give some history of the discussion and of the group, with clear instructions for searching the archive and reading the associated library, if any. Finally, the FAQ should provide any pertinent rules or guidelines for participation in the group, any penalty structure for violations, and a guide to acronyms or emoticons frequently called upon by participants.
The key question of who originally configures the software remains to be answered. Although transparent documentation of the configuration can lessen concerns surrounding configuration, and the provision of a default configuration lessens the controversy surrounding any particular instance of the software, we are conscious that the underlying design of the software constrains behavior at least as much as does its configuration in a particular instance. Therefore, we want to assure that software designers and administrators are responsible and accountable, at the very least producing automatic administration logs and comprehensive archives detailing the ultimate configuration, as well as documenting assumptions and basic principles as in this document.
Since all configuration settings must be entered into the software itself, we suggest that the software should automatically produce a “current configuration for this group” document stating what sorts of messages are prohibited, what type of behavior will meet with what type of censoring response, etc. We expect that such a document would be especially helpful in the context of proposal processing and voting, a system sufficiently complex that many participants might otherwise be unsure how the system is configured. The current configuration document would be accessible via the discussion group’s home page as well as in a “Procedural Area” housing this and other non-substantive documents and materials.
Traditional threaded messaging has proven a useful and robust means by which many types of online discussions may take place. The software we propose will supplement threaded messaging with substantial “meta information” to aid in discussion organization, thus assisting participants in following the discussion and in reviewing particular points of the discussion from the archive. With this additional information as well as data that the system already has about message threading, the software will create a sophisticated and informative graphical presentation of the discussion’s structure. This system might be in part automated (e.g., colored to show the number of replies in agreement and in disagreement with each message) and in part manual (e.g., configured to generate a brief title of each message or group of messages, perhaps distinct from subject).
WebBoard and other threaded messaging systems allow users to classify their own submissions to better organize the discussion. We will follow and expand upon this model, such that when posting a message, participants will be able to categorize their submission into an appropriate field. Classifications might include “I agree” or “Changing the subject,” among others, and each discussion group hosted by the software could configure its own list of message classifications. Combining classifications with message threading information, the software will recognize the structure of a discussion created as a result (i.e. will class all messages associated by users with a topic together) and will allow filtering accordingly in appropriate circumstances.
Rating systems have become a familiar part of the network landscape as online communities and companies have sought to leverage community opinion and knowledge. For example, in eBay, users rate the parties with whom they transact according to how well the other party performed the duties associated with its role in the transaction. In the ICANN context, the rating system will not have criteria that are as clearly defined because ICANN participants do not all share a common specific goal and associated values as do eBay users (namely, accomplishing a valid, efficient transaction). ICANN participants might differ so fundamentally on substance that they could find it difficult to rate one another impartially on content-neutral civility or the rationality of submissions.
Each participant who has been subscribed for a set amount of time, one not too long but sufficient to demonstrate commitment to the discourse,  can give weights to messages she reads as well as to her own contributions when made. Rating possibilities we envision include determining whether a message is relevant, helpful, informative, or not, and whether or not it offers a new or otherwise significant position on an issue. Although a variety of scales will be used, the total number of measures used will be limited in order not to overburden raters. As discussed in the Filtering section (18.104.22.168. below), these ratings will be available for use by filters.
We note that Slashdot and others have implemented such systems with great success, though sometimes with controversy surrounding their specific implementations.
Reason is the keystone of deliberative discourse and is enhanced by information and education. Good decision-making requires good information and a willingness on the part of decision makers to absorb such information and have it impact their opinions. Ideally, comprehensive, balanced, and accurate background materials would always be available to and read by all discourse participants prior to debate and decision-making. Although this software cannot guarantee the consistent achievement of this ideal, the software seeks to facilitate informed decision-making by including a library feature to provide the necessary background information.
The library will contain materials relevant both to specific discussions and to the online community and the issues it faces more generally. These materials will be available for delivery by browser, email, or offline review on request or automatically, as the group determines. Articles placed in the library will be associated with specific discussion groups and will also be tied to keywords and topical fields. Searches of the library will be possible by discussion group, keyword and topical field.
Readers will be encouraged to rate materials they read from the library according to how useful it was in relation to a specific discussion group, field or keyword, and this rating will be part of the search process. Because the rating system will help library users filter materials as necessary, we suggest allowing all participants to submit documents to the library. Similarly, any person or group could annotate documents in the library; a library user could choose to see the document without annotations, or with the annotations of only selected individuals or groups. Administrators would remove documents only if they are facially inappropriate in tone, language, subject or length. Any such administrative removal will be reflected in the administrative action logs and could be appealed in a “Concern Area” as discussed in Section 3.6.3 below.
When a discussion group is created, a link for submissions to or searches of the library for relevant materials will be generated on its home page within the online environment. Further, the participant obligations training undertaken at registration will mention the responsibility of discourse participants to educate themselves about the issues they wish to deliberate. Finally, the group’s rating system will also encourage more informed participation.
3.4. “Help” functionality
Apart from the technological issues that can make access to an online environment difficult for a potential online community member, user interface issues can prove to be a significant deterrent to access and participation as well. To reduce this deterrent, the software should provide an interface as intuitive as possible, providing detailed guides and assistance to users requesting help. In particular, online manuals and “Help” functionality should be context-sensitive as well as clear and comprehensive, and automated assistants (“wizards”) should assist with selected tasks such as registration. The interface should make the online manuals and Help functionality easy to find, with frequent reminders in the form of icons and text messages on various screens. Help email addresses and discussion areas should be clearly identified throughout the Help screens and online manuals so that users can get answers to unanticipated questions not covered by the provided Help text.
Technical moderators/administrators will have significant roles in the online discourse environment. Volunteers or employees who have been trained in the technical administration of the software, they will be the primary sources of technical support for groups and individuals, but they should not participate in discussions of a group for which they provide support. This separation of roles is important for the preservation of legitimacy; technical administrators will have significant power over discussion formats and controls, and it would be inappropriate to combine that power with individual agendas.
Technical support personnel should not only appreciate the intricacies of the server-side software but also be able to assist users in learning the basic computer and Internet skills necessary to use the deliberative software effectively. Technical moderators must be selected for their patience and ability to communicate with users whatever the skill level; arrogance or unresponsiveness in the support personnel would be an enormous deterrent to participation by new users, a vital and growing constituency. Given the serious possibility of abuse by a technical moderator (“technological tyranny”) and the devastating effect this could have on the legitimacy and the outcome of the deliberation, space in the Concern Center forum (see below) will be reserved for complaints regarding moderators, and we suggest that effective oversight be maintained by community personnel.
Ideally, we would prefer to allow all messages and speakers to compete equally for community attention and response according to their substantive contribution. However, as discussed elsewhere in this document, experience convincingly demonstrates that fully unregulated discussions often collapse under the weight of excessive post volumes, flames, trolling, spam, and ad hominem attacks. To prevent these undesirable outcomes, we propose that systems of control be incorporated to empower administrators, moderators, and participants themselves.
In a perfect world, discussions among equals would take place in an organized, directed, and civil manner without need for any individual discussant to be differently empowered than any other. Deliberative discourse ideals reject discussion moderators and other authority figures to prevent a possible power dynamic from adversely affecting the open and equal flow of ideas. Some online discussions have gone on successfully in such a manner for long periods of time. However, other online interactions, in mailing lists, on Usenet, and in MUDs, and in other contexts, have fractured and failed in the absence of any authority able to bring and enforce order.
Out of desperation in the face of disarray or by choice at formation, many online communities vest certain governance responsibilities for the creation and enforcement of rules of discussion in moderators, list administrators or sysops. The empowered person may in fact have created the online environment, or he may be the creator of the rules as well their enforcer. Alternatively, the community may enact them and then delegate enforcement. In some instances, online communities have established complex bodies of regulations and mechanisms for voting and dispute resolution and then empowered certain individuals to implement these rules.
As elsewhere in this document, the nature of online interaction is such that many of the inhibitions that deter rude and disruptive behavior in offline conversations are absent, and the resulting volume of messages and uncivil behavior often drive away those interested in thoughtful, productive discussion. Although the coder has initial (and unelected) power in sculpting discussion space, once the software is in use, other sources of authority, such as moderators and administrators, can begin to emerge. Given our presumption that the mutual goal of the online community is the promotion of reasoned discourse and democratic decision-making, the employment of carefully selected, trained, and tasked administrators and moderators to protect the “signal-to-noise ratio” of the discussions seems to us highly appropriate.
As described elsewhere in this document, the software will automatically log administrative actions in an area accessible to all participants. Thus, moderator actions such as the filtering of particular individuals or the failure to include some postings in the official discussion list archive will be readily known to all, making moderators accountable. Groups may vote on which powers moderators may exercise and under what circumstances, and the resulting discussion group rules will be available in its FAQ. Technical administrators will be tasked with setting up the discussion group within the software such that the moderator’s powers are limited as the group has elected and as the FAQ indicates. Complaint recording and impeachment procedures must be available to ensure accountability. Although the software may enable these procedures, the online community must itself decide on their particulars to ensure legitimacy.
Administrators may be volunteers nominated and elected by groups or selected by community officials, or they may be employees. The online community and its constituents will have to determine specific organizational structures by which to administer the software. However, we think it vital that the powers of the administrators be listed explicitly in the final software specification and be correspondingly limited by the environment’s code to the specified powers. The same applies to any individual whose role is to provide technical administrative support rather than to administer the rules of the environment or a particular group.
Based on experience with prior discussion groups, we recommend that the software be configurable to facilitate groups with or without a moderator. Although some discussions may not need the guidance of moderators, the experience of many online groups has demonstrated that procedural guidance and an authority figure can help groups stay focused and on topic. In general, the responsibility of the moderator should be to enforce the governance decisions made by the discussion group, as recorded in the participant obligations agreement entered into by all participants at registration (as described in Appendix B), in the online user’s manual for the software, and in the FAQs for particular discussion groups. Although this description fails to iterate the particular jobs of moderators, it rightfully emphasizes that the moderator is the servant of the discussion and of the community, not the leader or owner.
Depending on the purpose of a group, a moderator might or might not be the creator of the discussion group. However, whether or not the moderator is the activating force, she will be responsible for understanding the group’s goals and the issues that face it. She may take censuses and review registration records to determine how many people are monitoring the discussion and what proportion are participating, and whether there is some structural reason preventing more full participation. She must also remain alert to the ultimate goals of the group and the timeline for their accomplishment to ensure that distraction does not prevent success for the group.
The promotion of mores of civil, reasoned discussion is one vital aspect of a moderator’s role. The participant obligation agreement entered into by participants at registration and the FAQs of individual discussion groups will make the standards of behavior for the online environment known to all. Moderators will be tasked with enforcement of these rules of behavior and will be given tools to effect that enforcement.
A moderator must privilege the needs of the group and its ultimate goals above her own active participation and favored outcome. Moderators will have to balance carefully the need to stimulate discussion and ensure that it is directed to eventual decision-making as against the temptation to direct the substance of discussions toward particular outcomes to the detriment of particular viewpoints or individuals. Moderators cannot make all participants’ voices equally articulate or their ideas equally compelling, but they have a responsibility to help all voices and ideas have space within the discussion to be heard and considered. Part of preserving this space will be “killing” obviously off-topic postings such as commercial spam, controlling overly voluminous posters, and keeping the discussion relevant to its goals through postings and direct interaction with off-topic posters.
Moderators have a role in promoting effective as well as equal deliberation. Moderators can be vital to moving discussions away from procedural morasses towards the substantive issues that inspired the group’s formation. Both the topic and the timeline for discussion should be announced periodically to help participants focus on the group’s goal. As the deadline for decision nears, the moderator will be responsible for calling for final submission of differing ideas and for moving the discussion towards deliberation of specific proposals. Although the software would permit a group to choose to allow any member to call for a vote, moderators will have the final responsibility to call for a vote to meet the decision deadline.
The training of moderators will be vital to their efficacy. Training must reinforce the limited charge of moderators--to facilitate but never dominate. Their aim must be to help shape the discussion space so that all may be heard and no one person or viewpoint drowns out others and so that mores of civil discourse are emphasized and enforced. The “signal to noise ratio” of a group is key to its success as a discussion space, and moderators will learn what tools the software provides to help maintain an appropriate one. The moderator manuals and the guidelines established by the community at large and by specific discussion groups at their formation will help direct moderators in their responsibilities after their training is complete.
Moderator manuals will provide suggestions and the lessons of experience for moderators regarding various types of discussion groups, how to further their goals, and the types of problems often encountered with them. Clear guidelines for what behavior will trigger enforcement responses and what appropriate procedures should be undertaken in conjunction with enforcement will engender accountability for moderators in their enforcement role. For example, ad hominem attacks and other forms of harassment of other participants should meet with an immediate response, whereas posting in a volume the group has determined to be excessive should be first met with a warning and only after repeated violations should any more severe sanction apply.
Procedures for selection of moderators must be carefully considered and their power constrained in order for discussion participants to feel that discussion is truly organic and not orchestrated by the moderator. As described above, in an appropriate situation such as a short-term discourse, a moderator may even be selected from outside a decision-making body so that his own agenda does not interfere with the group’s discourse. The moderators for some discussion groups may be chosen by virtue of their elected roles within subgroups of the online community. For other groups, moderators could be chosen by discussion members from a rotation of long-time active members. Terms should be restricted to provide continuing change in leadership; the existence of a permanent moderator, who cannot be unseated or changed, is highly inimical to the validity of the discourse.
Offline filters exist both on individual and group levels. Through laws and regulations, societies can regulate the time, place, manner and content of speech. Individuals can often choose not to be exposed to speech they do not want to hear, whether by failing to read it or by avoiding places where – or people by whom – such speech will be uttered. Speakers are also under greater social pressure to behave appropriately in offline fora, leading to less need for filters.
Online, a filter is a familiar tool for many people. Filters are implemented both on the server-side, by administrators and moderators, and on the client-side, by end users. Publicized use of filters has proven to be one of the most effective means of improving a user’s experience with the discourse environment. Although they are often identified only as a way to protect a user from views he finds unpleasant, filters are also useful because, when used with a rating system, they can intelligently cut down on the volume of posts encountered even when no poster is individually excessive or offensive. For substance- or participant-based filtering, however, filtering of the discussion is most appropriate when individuals decide for themselves what language or individuals they choose not to hear. This type of bottom-up filtering best preserves our intuitive notion of the value of unfettered speech while at the same time offering users the option of blocking out comments they find offensive or useless.
The user-side filters we recommend can be configured either according to the identity of the poster or, if a ranking system has been implemented, according to the ranking of a message. Because other list participants may not have the same individual filtered, and may post messages which include that person’s comments, it would be preferable to design filters that screen both original and quoted matter from the same source.
Individual filtering should be as flexible as possible, allowing users to filter messages or other participants on all readily available criteria. At a minimum, the software should allow participants to filter other specific posters, including any of their input that has been copied by others in forwards or prior post excerpts; to exclude posts according to any rating systems implemented; to filter posts according to the presence of specific words or phrases in their subjects or bodies; to adopt the filtering preferences of other users; and to filter according to the number of current censures in a poster’s biography file. Users should be able to have several “preference sets” for filtering, such that they can use one set for open discussions, another for discourses leading to votes, and another for a different discussion group or topic altogether. We also favor the use of rating systems, like Slashdot’s, that depend on users or moderators, according to a group’s configuration, to provide standards that individual users may then choose to follow for filtering purposes.
An ideal discourse would not require top-down administrator control, but the imperfect reality is that such controls are often necessary. Filtering (or canceling) of certain types of messages can be appropriately and efficiently delegated to moderators. Administrative, top-down filtering should also be possible to filter posts from particular people in especially egregious cases. Such filtering should be time-limited, with review required prior to any extension or repetition of the period. We envision this to be helpful on discussion lists where there is such disruption that in order for the discussion to survive, the list administrator must maintain both a censored and an uncensored list. The software could allow groups to elect some top-down filtering according to the amalgamated individual filtering or ratings, such as by having all messages that have been filtered by a (high) set percentage of individuals in the group be filtered by default for the entire group; filtering of any message not achieving a set rating; of any message in excess of a poster’s set allowance of messages in a given time period; or of all messages from particular people the community has adjudicated to be repeat offenders. Individual group members might override such group defaults by choosing to be more or less restrictive than the standard group conventions. A proxy system would permit group members to adopt the preferences of another member or group of members, thereby lessening the load of deciding which participants should be filtered for excessive posts or for some other reason. We note, however, that excessive use of these features could be dangerous because they can become tools for tyranny by the majority, silencing valid minority viewpoints.
22.214.171.124. Rating and Classification Systems
Although their implementation is motivated in large part by their utility in structuring discussions, the rating and classification features in the software are also useful as agents of control by the community. The community can promote its values of reasoned discourse by responding to the ratings and classifications of messages. As an example, there is little incentive to post a message that almost no one will read, so the ability of participants to filter out messages according to their low ratings can serve as motivation for posters to try to contribute to the discourse rather than posting inappropriately.
Filtering according to rating and classification will be possible in a number of ways. The most straightforward is the standard show/hide filtering according to the average of all raters’ evaluations. 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 users. Alternatively, filters might adjust formatting on certain messages, perhaps by reducing the font size of messages frequently marked as “not constructive.” If the group so elects, the moderator’s ratings would be averaged in with all other participants’ ratings, but the moderator’s rating could also be accessed separately if individual participants wanted to use it as the sole criteria for filtering purposes.
Averages of all ratings for all posts from an individual to a particular discussion group would be available to the moderator for use in warning messages for those falling below community standards, e.g., “Your messages have an average rating of +3 for constructiveness and –3 for civility of discussion. Your messages might find more receptive audiences if you try to be less insulting.” However, we suggest that, in general, these averages should not be made available to the entire group.
The first responses from the system could presume that a poster’s inappropriate behavior represents a lack of attention to community standards rather than a malicious disregard of them. Thus, automatically-generated, firm but not harsh reminders of those standards and the consequences of repeated failures to follow them could be useful as reminders. Information about the violations should be included, such as by what margin a poster has exceeded a group’s configured volume threshold and what percentage of all posters they exceed in volume. Details of the community’s response, such as what percentage of participants filter the participant in question, could be helpful deterrents as well.
Cancel commands remove a message from a mailing list or bulletin board system before it is fully disseminated. Message cancellation differs from filtering in that cancelled messages are not stored in either the filtered archive or the comprehensive archive. Thus, the cancel command is a sanction that should be reserved for facially irrelevant messages such as commercial solicitations and other messages that are completely off-topic. Messages that might be censored due to their inappropriate content should be handled by filtering so that they are present in the comprehensive archive. Moderators as well as administrators should be able to issue cancels.
126.96.36.199. Kill Command
A kill command can prevent a participant from logging into the system at all, or can merely reject any submissions he seeks to enter, or to enter in certain areas. The command can be temporary or permanent. The use of the kill command is an extreme sanction, and we believe it should not be possible in its most extreme incarnation of preventing login altogether. Rather, the kill command should be reserved for senior administrators, should be applicable for only a set period of some days, weeks, or possibly months, and should not prevent a user from posting to the specific section of the Concern Area reserved for appeals of kill commands.
For groups in which disruption is rampant, comes from many inappropriate posters, and in which widespread support for such a move has been demonstrated, a moderator may establish a separate, censored list. Administrator content control should be used as a last resort, and its inclusion as a tool is a testament to the severity of verbal attacks that online communities have faced. A moderator-censored list would be moderated more aggressively than the original; the moderator would have authority to filter many more posts than would fit standard filtering criteria, and top-down filtering of long-term offenders would be implemented. Both lists would reach the archive, assisting in holding moderators accountable for their decisions.
A peer voting system requiring the assent of a high proportion of participants could be used to elect and apply sanctions on disruptive individuals. Inappropriate behavior could be noted and reported by the moderator to a higher administrator, who could certify the issue of sanctions for a group vote if the behavior met certain standards of egregiousness. The software would present the group with options of setting binding limits on a number of levels of granularity (per day, week, or thread) or only to send a formal “warning/request” to the poster informing her that some proportion of her peers in the discussion group find her behavior incompatible with the group’s norms and would like to see a change. However, obvious concerns about the tyranny of the majority exist with such an approach, among them that sanctions will be disproportionately applied against those with unpopular ideas.
A progression of the warnings and sanctions described above, in conjunction with community-chosen standards of behavior for discussion groups and publication of these standards in the group’s FAQ, is appropriate for all of these potential problems.
In situations where the system faces numerous or large messages intended to overload it, or some other denial of service attack, it is generally accepted that system administrators are justified in taking all necessary steps to protect the system. If, on the other hand, the problem is solely annoyance, greater transparency should be required through the establishment of clear standards for responses and automatic and accessible logging of administrative action.
It must be noted that volume can be measured according to the total number of posts from a participant, or from the aggregate data size of all posts from a poster. The latter is what we believe to be more fundamental a difficulty; although overly numerous posts of small amounts of data is a problem that has been seen, it rarely exists without also creating an excess of data. We thus focus our attention on the posting of too great a volume of data in a set period of time by a participant.
A group might configure itself such that the system simply will not accept more than some set volume of posts per day, week, and/or thread, from any one poster. Providing that this self-binding prohibition is clearly posted and publicized to participants, it is an absolute, rigorous, and simple solution, albeit one lacking in flexibility. We suggest that groups should generally choose methods less drastic than this outright block. For example, a group might elect to use a combination of the control and feedback tools described above, with a clear progression of sanctions for repeat offenders.
On an individual level, participants can filter messages from particular posters with a history of excessive posting. One problem with this solution is that there is little incentive for the offender to change his behavior because most individuals will not then remove him from their filter list even though the substance of his messages may never have suggested that his contributions would not be valuable if more succinct.
We recommend alternatively that participants be encouraged to filter according to message ratings, and that the system automatically assign messages in excess of the volume standard a negative rating. Rating systems can be configured to penalize excessive posters automatically by, for example, assigning a weight of –1 to posts beyond the community-set standard for per-user volume. The substance of some of an excessive poster’s messages will then still reach the participants, and there will also be an incentive for him to change his behavior so more of his substance reaches them. Messages in excess that are sufficiently valuable might even trump their initial negative rating, an appropriate outcome in our opinion. In conjunction with increasing levels of sanctions for repeat offenders, individual rating filters can be a well-suited tool for addressing this problem.
Many people find profanity and obscenity to be offensive, unpleasant and counter-productive to rational discourse. We believe that the participant obligations agreement should clearly discourage the use of profanity and obscenity, especially when it is used as the primary form of communication rather than for occasional emphasis.
System- or group-wide filtering of profanity, using a “prohibited words list” and intelligence that searches for variations of profanity such as certain separations of letters by spaces or punctuation, has been found useful in reducing participants’ exposure to it. Furthermore, non-English communications could be reached via a system familiar with obscenities in multiple languages. Although these methods can be reasonably effective, we believe that human resourcefulness is such that they will over time be defeated, and, more importantly, this type of systemic censorship seems heavy-handed and undesirable.
Instead, we recommend that group norms be promoted that strongly discourage profanity and obscenity. The participant obligations agreement is the first means by which this can be accomplished. Further, group FAQs can establish group policies of intolerance for this type of language. Building on the POA and FAQs, moderators can then send messages reminding selected participants of these standards, and, most importantly, end users can choose to filter participants who demonstrate an unwillingness to meet community standards.
The software could be configurable to reject messages beyond a certain length if they contained many layers of prior responses. The system might generally accept only quoted comments from the last message to which the poster is responding, perhaps unless specific steps are taken by the message poster to confirm his 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.
If volume controls are implemented, forwarded messages may diminish as a problem because they will count towards a participant’s total message count. The software will allow participants to mark a message as a forward, and to filter any messages so marked.
Only registered participants will be able to post to discussion groups, but the spamming of discussion groups by their own participants is unfortunately not unknown. At least three possible solutions can be implemented if this problem occurs. An administrator can issue a “kill” command that prevents the participant from logging into the online environment to post; an administrator or moderator can impose top-down server-side filtering that rejects posts from the participant for some period of time or entirely; or an administrator or moderator could cancel the offending message, preventing it from disrupting the flow of discussion for all participants and perhaps preventing it from reaching even the comprehensive group archive.
Of these three, we find the last choice to reflect the best balance between protecting the discussion and maintaining minimum top-down regulation. The kill command seems inappropriate given the nature of the online environment as a political arena, and top-down filtering is heavy-handed if not carefully cabined by group-established standards that withhold its application for all but the most egregious offenders. Message cancellation places a greater burden on the moderator because it must be done on a message-by-message basis, but we believe that type of attention to be appropriate when considering precluding users, without their knowledge, from ever seeing a particular message.
This area of the online environment will be largely self-referential. Discussions about procedures, general conversations about suggested changes in configuration defaults, complaints about software administration, and interactive help discussions will be concentrated here. Moderators for substantive discussion groups will be encouraged to suggest to individuals or groups that they participate here if they seem to be pushing a substantive discussion group too far into procedural conversations to the detriment of the substantive debate. Areas will also be dedicated to specific types of complaints, such as inappropriate behavior by substantive or technical moderators, or suspected identity fraud by participants.
We believe the problem of legitimacy is ameliorated by relatively more perfect information and by allowing shared experience to demonstrate rather than relying on rhetoric to convince. We therefore suggest the establishment of a demo discussion area where “practice” discussion groups can be established in which all options can be adjusted and explored by any interested member of the general public. Experimentation can be undertaken here to see how a discussion group can be configured and what alternatives exist for groups when procedural debates arise. A “recipe book” would provide documentation of the lessons of experience and provide previously successful solutions for common problems; for example, “Are you having trouble with an obscene poster? Try this.” “Can’t get people to focus on the subject at hand? Try this.” The practice discussion areas would then permit immediate experience of what such a configuration would “feel” like to users.
Transparency in regulation is vital to the creation of trust within the online community. Participants must trust that administrators use their power appropriately and neither can nor will circumvent the controls placed by the community on that power; otherwise, users will not feel empowered as participants and constituents, and they will question whether the environment is a worthwhile forum for expressing their political will. To ensure accountability in the regulation of the online software environment, the actions of those empowered by the system cannot be hidden from participants. To that end, the software should generate an entry in the administrative action logs whenever an empowered person exercises any of the controls possible within the system.
Because the software will automatically generate the logs, participants will trust the logs insofar as they believe that the software operates as it is described. Furthermore, administrators will not be able to edit these logs. The logs will be searchable by action taken, administrator acting, discussion group(s) affected, individuals specified by the action, and time period in which the action was taken. They will be reviewable by anyone, at any time, whether a logged-in user or not. Appeals of the actions or complaints about them or the administrator who took them will be raised in the Concern Area.
No matter how transparent we attempt to make the online discourse environment, there will be questions and concerns about its fundamental structure, day-to-day administration, and the individuals who administer and populate it. Participants can raise these issues here to be considered by software administrators, their overseers, and by fellow participants who monitor the area.
When a participant enters the Concern Area, he will have a choice of choosing a topic or area of concern from a menu, or entering a phrase describing the issue he has come to discuss. The software will use keywords found in his phrase to refer him to appropriate public comment areas, experts, or staff best able to respond to particular concerns. Administrators will encourage participants to be appropriate in their choice of forum, and to change fora within the Concern Area if necessary to preserve the utility of the archives and FAQs of the various areas within the Concern Area.
Although participants will have access to administrators’ and community officials’ email addresses, they will be encouraged to post their questions and concerns rather than emailing them privately so that others can also benefit from the responses. Unlike elsewhere in the software, we recommend that anonymous posting will be allowed in this area. In this context, we suggest that it is especially vital to promote open questions, and that removing the risk of personal embarrassment for unfounded concerns or misapprehensions is helpful in doing so even though it leads to less accountability.
General questions about the software environment and its structure will have a discussion area here. A continually updated FAQ will prevent some question replication; questions marked “new” by a software administrator may be automatically entered into the FAQ database for subsequent indexing and searching. Thus, the software might provide an automated or semi-automated means of exporting organized responses to standard web pages for archiving 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.
Regularly scheduled or occasional events might feature key staff or office holders participating in real-time chats or otherwise engaging in discussion groups by responding to questions and issues. Such a system would require the existence of a permission level enabling a “specially empowered participant” to reorder questions (perhaps without being able to alter them otherwise) to group multiple concerns together and perform other administrative tasks over the discussion without having broader administrative power elsewhere in the Concern Area or the system generally.
Although questions about a specific discussion group should be directed first to that group’s area within the Concern Center if one exists, questions about the propriety of the moderator’s behavior may not be comfortably or effectively raised there, since the moderator for the group will likely also moderate, albeit less actively, the group’s concern area. Participants would be encouraged to try first to find satisfaction over a moderator issue in the group’s Concern Area, but to resort to the general Moderators Area if not satisfied. This area will be monitored by those within the community who have been appointed or elected to oversee the online moderators and administrators.
A specific area must be reserved for those appealing kill command sanctions. Kill command sanctions are discussed elsewhere in this document, but briefly, they prevent posting to any area in the online environment except for this specific portion of the Concern Center.
Large or often contentious discussion groups will also have specific discussion areas in the Concern Area where their particular issues can be raised. Although questions about the software generally would be more profitably raised in the general area, we believe that the risk of overwhelming the general area’s discussion with debates specific to individual groups outweighs the potential disbursement of useful content to multiple fora.
Participants should be able to submit allegations of identity fraud or other forms of deceit to administrators. They will be encouraged to make the first such allegation against an individual or group of individuals as a confidential submission. The log system should log allegations of identity fraud if no action is taken or if the complainant is not satisfied with the result of the administrative investigation.
Automatic comprehensive logging of all available information about users accessing the system will prove helpful in the context of investigating alleged identity fraud. For example, it is trivial to record browser type, operating system, and IP address (for reverse lookup into a fully qualified domain name if available) of users accessing a system. Such information might support allegations of fraudulent multiple registrations. For example, if the allegedly duplicate users accessed the Internet from the same IP address or from nearby addresses and used the same software, an impartial analyst might reasonably suspect fraud; the burden of proof of unique identity might then shift to the allegedly duplicate users.
The accused user or users should be given an opportunity to respond by the administrators without being informed of the accuser’s identity. If the response is unsatisfactory, the investigation has become public, or a discussion group seems paralyzed by identity fraud issues, the software could implement a so-called “web of trust” whereby administrators are allowed to reveal identifying information, each user specifies whom he knows, and the system then lists those whom no one knows. Such a system presents clear problems – in particular, it disadvantages newcomers and outsiders – but it might nonetheless be appropriate in certain contexts, especially when coupled with other means of investigating complaints.
If an investigation determines that one user is participating and voting in a discussion group under multiple identities, all but one of the offending identities should be removed from the system, and the remaining identity will have a censure recorded in its associated biography for some set period of time. Other users can choose to filter automatically all users with such censures in their biographies. Individuals with some number of censures will lose their right to vote in the groups in which they are registered for some period of time, and those with some greater number will be unable to submit to the system for a set period.
Accurate, complete, searchable archives will be vital to the software’s efficacy. The automatic generation of uncensored archives and of administrative action logs will assure the transparency and thus the legitimacy of the online environment’s administration. The comprehensiveness of the record and facility of search functions will be equally important to the creation of a shared history and robust governance.
Archives should encompass all online deliberatio, transcripts and/or audio-video records of any physical or telephonic proceedings, formal decisions and resolutions passed and implemented by the online community, and all background materials (including laws, policy papers, research and data pertaining the subject matter of deliberations) that were referred to or constituted part of the documentation considered in the course of deliberations. To allow later reconsideration, we believe it is important that an uncensored list be available, even after participants have blocked out certain users. Such a system further reduces criticism of the list on the grounds that the administrator is offering content control over list contributions.
Ease of use will be a priority in the archive’s structure. Both the comprehensive and the moderated archives should be publicly available via a straightforward interface accessible from standard intuitive URLs. Archives should be fully searchable, with provisions for full-text, Boolean, per-field, and compound searches along with a friendly “wizard” user interface for novices. Message environments should enable citations to individual messages and groups of messages (conversation threads) in the archive, but should also link to meta-information like records of individual events (i.e. the voting records on a particular question) and the cross-referenced records of individual participants (i.e. all posts and votes by a single individual) and the discussion parameters under which a debate was held/vote was taken.
The software should automatically generate 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. Such notice might also prove helpful if a group came to question the decisions of its moderator.
3.8. Voting apparatus
Voting is the predominant means of decision-making in systems in which a system’s constituents share power. The software we propose must therefore include a voting apparatus of some kind. 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 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.
Online systems already exist for recording and tallying votes. Some are designed particularly for elections and include candidate presentation and campaign applications; others are designed for shareholder use. All online voting systems must confront concerns about identity authentication, fraud, and anonymity. Online systems are also capable of using the same variety of methods for the calculation of winning candidates that is available in the offline world.
Numerous formulae, from “winner takes all” to preferential voting, have been created to determine which candidate of a field has demonstrated the highest level of support from the electorate. Polling mechanisms that protect minority rights, regional or interest group representation “seats,” preferential voting, supermajority requirements and other devices can be supported by the software and instituted to prevent dominance by one large group. The benefits vary among these different polling models and the choice in any particular deliberation should depend on the nature of the decision being made and the number of participants. A poll taken among members of a small committee, for example, would not require the delicate precision enabled by preferential voting systems.
The software should allow empowered participants to call for a vote at the discussion’s home page. Among groups, the criteria for voting will vary greatly; for example, in a group convened as a committee meeting, only the Chair might be able to call for a vote, whereas in a “town meeting” group, any participant might be able to call for a vote but be unsuccessful unless a sufficient number of his peers concurred. Voting will require login via a browser to a web page automatically generated for the vote in question.
In addition to enabling traditional decision-making, the voting apparatus should also be to provide a “sense of the group” polling feature (configurable as anonymous or non-anonymous, per group or individual choice) to see if further discussion is actually necessary on an issue for which agreement may already have been reached. Because it does not lead to final decision-making and therefore requires less security, this type of polling could be handled by email.
Security for voter authentication and voting record data is essential, both in transit and in storage, as is a mechanism for independent review of the election software for accuracy of process and result. A difficult paradox with current online voting systems is that user authentication is vital to prevent voting fraud, but due to the necessity of tracking the identification data, the anonymity of voting is generally compromised. Although we have not identified a truly satisfying solution to this problem, we believe the assignment of confidential user codes and the restriction of access to those codes within the software could serve the purpose. Assigning confidential user codes and publishing vote results linked to such codes allows voters to be confident that their vote was properly recorded without revealing to any but the voter what the vote actually was.
Voting mechanisms should anticipate the possibility that different participants would be eligible to participate in different votes. For example, in the context of ICANN, geographic region determines the slate of candidates among whom a voter can select.
The discourse software should include software applications to encourage an interchange of ideas among participants. For example, many applications might benefit from a system in which each participant is required to comment on an important document, attempting to reduce the silence prevalent in certain discussion areas. One such application would allow a question or thought to be posed, by a moderator or by another participant, to the entire group. Participants each answer the question or respond to the thought individually, then the server “shuffles” their individual responses such that each receives the response of another. Each participant must then submit a critique of the response he received, and all responses and critiques are ultimately posted to a public archive for review and further discussion by the entire group. This tool will also be useful for group production of documents.
3.10. Code and Database Structure
Registration, discourse and polling should all be seamlessly integrated with back end applications for a number of purposes including the generation of analytical reports, of participant analyses, and of customized mailings.
The system should allow administrators to access certain types of identifying information, and moderators should be able to retrieve some or all such information after appropriate procedural safeguards. The security configuration of archives should be fully customizable, with particular aspects of the archive public or internal according to settings made by the group administrator.
Given appropriate system design, most reconfiguration and ongoing administration should be possible through an administrative user interface rather than through modification of the underlying source code, for this approach will prove far more robust and reliable. Such architecture will also make easier the delegation of certain software administration roles to less technical staff and/or group operators. However, recognizing that certain far-reaching changes will require modifications to the code, we propose that the software be written in a mainstream modern language following best practices for programming design, documentation, separation of presentation and “system rule intelligence,” and other programming standards as they evolve.
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 into which the addition of data structures is a straightforward task. To facilitate the inclusion of new modules, the user interface should provide interfaces for the addition of new modules or components as well as for the translation or other customized presentation of existing modules and components. The code should be logically separated into standardized components as fully as possible to promote future code reuse.
Finally, the code should anticipate connection to external programs. For example, it should be possible for external web-based programs to use its registration and authentication systems in order to serve the same user base.
20 August 2000
Reports prepared for the Berkman Center for Internet & Society’s Online Deliberation Discourse Research Project appear online at <http://cyber.law.harvard.edu/projects/deliberation/>.
For additional information, please contact:
Berkman Center for Internet & Society at Harvard Law School
1563 Massachusetts Avenue
Cambridge, MA 02138
Berkman Center for Internet & Society at Harvard Law School
Online Deliberative Discourse Research Project
Phase 1: Specification for Online Environment Platform
The Internet Corporation for Assigned Names and Numbers (ICANN) presents a novel situation for decision-making. It is hybrid by nature and global in effect. Although it shares many constraints and characteristics with online communities, its membership has joined around a shared resource rather than a shared affinity. While individuals can generally leave online communities and the reach of their governance at will, sacrificing whatever personal investment they made there but otherwise able to cut the ties cleanly, decisions made by ICANN will generally impact even those individuals who reject membership or participation in ICANN or who question the legitimacy of ICANN’s decisions. So long as a critical mass of Internet infrastructure operators defer to ICANN-administered standards, that organization’s decisions will determine certain technical aspects of the Internet experience.
However, even within its assigned purview and despite the impact of its decision-making, ICANN is unlike a government in a number of important respects, notably that it lacks a government’s so-called “police powers.” Indeed, many of ICANN’s decisions require the assent of those impacted to a degree rarely seen by most governments. ICANN has little remedy against those who refuse to act according to community mores or to promote group goals. For example, where an offline community can physically remove or even jail someone for impermissibly disrupting decision-making meetings or votes, ICANN often has little recourse against those whose goals are only to disrupt and distract. No one can be forced to participate or vote in ICANN’s decision-making, or even to register that they exist as an online person. ICANN’s goal of legitimacy is all the more difficult because it cannot identify or reach all those who will be impacted. Nevertheless, ICANN must seek to reflect the values of the Internet community if it is to garner legitimate authority by serving its current membership and attracting the willing support of other Internet users.
No authoritative voice exists to express the Internet community’s values, if in fact any are held universally. In considering ICANN’s unusual position and the values its community does share, we found little constancy except that almost all are concerned with having a stable and reliable Internet, and most seem to believe that decision-making power should be distributed and transparent. As has been frequently recognized, no body of law reflecting online society’s shared values exists for cyberspace. However, frequent reference has been made to constitutional principles or derivations such as the freedom of speech, an aversion to government intervention, and a right to privacy, that are ostensibly shared values of the community of online users. It remains to be seen to what degree such assertions reflect current, and future, reality.
Further identification of shared values will come, we hope, as ICANN’s members consider this specification and other similar reports and determine which aspects to embrace and which to reject. To start the process, initial parameters must be chosen without the benefit of a process validated by the entire affected constituency. However, so long as the initially chosen parameters allow for their own replacement if the group so decides, we believe that neither the initial decision maker nor the initial processes should be faulted for the unenviable responsibility having had to be first.
By some measures, the adoption of values by the ICANN community will be overly mechanistic because this community has not gathered organically around values its members already shared. However, we believe that the shared goal of a stable Internet and the explicit adoption of core values will enable the community to be stronger in its principles than are those who presume, but have no explicit proof, that their community shares common precepts. In this context, the code that creates the online environment in which ICANN members interact will have a vital role in helping the community adhere to the values that it explicitly chooses.
ICANN seeks a difficult balance between a desire to do its work in an open environment and the harsh realities of the logistical and other challenges of open debate. Because the issues addressed by ICANN are in part complex and technically challenging, the availability of information and support for discourse will be vital for the public to appreciate the ramifications of its decisions on its use of and access to the Internet. This information and discourse will need to be supported in a variety of formats to suit the wide range of technical skills of ICANN constituents.
Furthermore, the different formats of ICANN’s various working units call for varying types of discourse. There are large groups, such as the DNSO’s General Assembly (to which anyone can belong) with sporadic comment online and more serious consensus-determination taken in physical space in conjunction with ICANN’s board meetings. The new At Large Membership has already attracted over 150,000 people around the world, likely with widely varying degrees of interest in and knowledge about ICANN’s charge and challenges. Smaller ICANN communities include working groups and advisory committees, which operate in different degrees of openness, from the sovereign states-only restriction of the Governmental Advisory Committee, to the public fact-finding hearings and online document-drafting practices of the Membership Advisory Committee. Some small committees such as the Elections Committee do their work primarily in private but periodically post documents for public review and comment. The ICANN Board itself uses various formats, from teleconferences to large public gatherings with over 400 people physically present. Some Board sessions seek to collect community input; the Board not only encourages those present to speak, but also welcomes web-based remote participation. During formal board meetings, however, the public may be present (or watching via webcast), but cannot verbally intrude without the consent of the chair.
Although ICANN’s procedures have been accepted by many 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. A new online environment is needed to promote the kind of productive and illuminating discussion that can lead to informed democratic voting.
Berkman Center for Internet & Society at Harvard Law School
Online Deliberative Discourse Research Project
Phase 1: Specification for Online Environment Platform
As discussed in Section 3.1.2 of the main document, we believe that reciprocity of expectations and obligations must exist between communities and their participants in order for communities to function as environments for rational discourse. In this context, we mean that the rules and code governing the online environment in which participants discuss and vote should instill in participants a confidence that their voices are heard equal to others’ and that their votes count equally in the decision-making processes for which they are eligible. We further mean that the community should be able to expect certain standards of behavior from its members, and that those standards should be clear and enforced such that no member feels marginalized due to the excesses of another and that no member is entitled or empowered to disrupt the online environment to the detriment of all others.
Online social mores, like their offline counterparts, are constantly evolving and differ from group to group and community to community. Social theorists have provided principles they believe aid communities in facilitating goal-oriented discussions. Many communities in Usenet and on the World Wide Web have Frequently Asked Question (FAQ) documents or membership agreements that are intended to provide guidance to new and existing members when questions about appropriate behavior arise. As a body of information (including, ordinarily, the history and the “do’s and don’ts”) about the particular online community, FAQs offer a simple way for new participants to get acquainted with the rules and procedures governing the community in question. They save administrators and established members the tedium of re-explaining and re-justifying the rules to newcomers, and they also help to provide a convenient reference to frequent areas of concern to group members. In examining a number of these types of resources and templates, we have found some points to be particularly apt.
The most fundamental obligation of participants is to become familiar with the technology and the medium in which they will be communicating. In order to access the online environment at all, this obligation will already have to have been met in large part, but it is important that once online, the applications used for communication remain simple and as easy to navigate as possible, with help screens and information readily available. However, the standards of behavior and the lingua franca of this environment will not be intuitive to all newcomers, and there will be an obligation for them to acclimate themselves.
One key to establishing the right relationship between community and member is education. Members should be educated about the obligations that the community has to them. In ICANN’s case, the rights and powers associated with membership in the General Assembly, the Membership At Large, or other subgroups should be clear and widely disseminated and perpetually available. The archive in the software specification discussed in the main document will have sections delineating the roles of each type of ICANN member who will have discussion space within the online environment that the software creates. Correlatively, the duties and responsibilities of those types of members will also be delineated there.
Further, members should be educated about their obligations to the community. Particularly where the community is large and diverse, we suggest that a short course on using the online environment and on social protocols for ICANN discussions might be required for those wishing to register as participants in online discussions. The first part of the course would be a concise explanation and guide to the basic features of the software. Next, four to six screens would describe how appropriate behavior facilitates online discussion and ensures that no one is drowned out of full debate, explaining how the software and any appropriately empowered moderator can enforce these norms, and asking the potential participant to commit to participating accordingly. Clicking on “I understand,” “I agree,” “I will” or “I will not” where appropriate would be required to move forward through the course and into registration. We structure this as a contract not with the goal of creating a legally binding document, but rather to emphasize the creation of a social contract binding all of the community and submitting all members to those controls necessary to enforce this social contract.
Part of the social protocols tutorial would contain basic, widely accepted “netiquette.” Basic concepts such as the need to recognize the difficulty of accurately conveying complex thoughts and certain tones, such as sarcasm, and the correlative need to read the remarks of others charitably, would be covered. The document would similarly explain that the use of all capital letters is construed by most people to be the online equivalent of shouting, a fact unknown to many newcomers to online communication. Finally, spamming, as well as use of list information for any commercial purpose without explicit authorization, will be explicitly prohibited.
More substantive standards of behavior would be covered in the netiquette section as well. At least one page would describe the inhibition-lessening tendencies of online interaction and each participant’s obligation to maintain civil and reasonable tones in discussion, and to focus on issues rather than on personalities. The libraries associated with different discussion groups would be described, and the civic responsibility of participants to learn about the topics they wish to discuss and vote upon would be iterated.
Common tools of online communication would also be covered. Acronyms are a frequently utilized tool to economize typing, but they are also a frequent barrier to newcomers, especially those for whom English is not the first language. Examples abound both of offline idioms which have become online acronyms, and of acronyms whose use is common online but effectively unheard of offline. Some discussion could be included of so-called “emoticons” (also called “smileys”), commonly used representative faces comprised of ASCII characters and intended to add clarity to online dialogue.
The contents of an ICANN social protocols tutorial will evolve as ICANN does. However, scholarship in this area articulates prerequisites for reasoned discourse that should be encompassed. “Participant Guidelines for Electronic Discussion Groups” by the Civic Practices Network provides an example of suggestions for the conduct of participants in an online environment.
carefully to others.
Maintain an open mind.
Strive to understand the position of those who disagree with you.
Help keep the discussion on track.
Speak your mind freely, but don’t monopolize the discussion.
Address your remarks to the group rather than the leader.
Communicate your needs to the leader in personal e-mail messages.
Value your own experience and opinions.
Engage in friendly disagreement.
Make your messages one computer screen length.
Limit each message to one idea.
Use the subject line according to group rules for topics.
Remember that humor and a pleasant manner can go far in helping you make your points.
Consider whether the message should go to an individual rather than the group.
Four aspects of participation, taken from the work of Paul Grice, are of particular importance to online discussion. First, the manner of expression: is the statement to be submitted clear, succinct, and civil? Second, the quality of expression should be considered. Is the statement informative to the discussion? If it alleges a fact, is the fact supported? Can the participant articulate reasons supporting opinions given? Participants have a burden in a deliberative discourse to effectively present the reasoning behind individual points of view. Next, the quantity of expression should be evaluated. The participant should ask herself whether her contribution is no more informative than required for the current purposes of the discussion, and compare the amount and number of her recent submissions with others in the discussion. Is she forwarding a great deal of material that most others have already seen and will not need again? Is her submission focused? Finally, a participant should examine whether his submission is relevant to the discussion where it currently stands. Is what he wishes to submit a response or other form of participation in the group dialogue, or merely a declaration that does not fall within the conversation? If what he wishes to submit represents a change in topic, is it one which remains within the discussion’s purview? Has he marked it as such, or can he wait to raise his point until the discussion has more naturally arrived there?
Berkman Center for Internet & Society at Harvard Law School
Online Deliberative Discourse Research Project
Phase 1: Specification for Online Environment Platform
The expression of reasoned principles through discourse might occur on many different levels and involve vastly different numbers of participants. ICANN has many subsidiary organizations with different roles and empowerments associated with each and with different types of tasks that each may undertake.
For example, there may be need for discourse related to specific tasks, not all of which occur in a public forum. A small Domain Name Supporting Organization working group might take advantage of a shared virtual white board to jointly annotate a central document, with markups visible to all others simultaneously. Some groups might prefer privacy for their initial efforts or for the preparation of material that is expected to undergo frequent revisions before presentation to the public. Some subjects may require a degree of privacy (early drafts of a proposal, for example) while others have no value without substantial participation (election of Directors). We discuss some likely scenarios below.
Comment by participants on document drafts.
The library will be the original repository into which documents can be loaded from elsewhere on the Web. A threaded messaging system will allow comments to be organized such that they fall under the relevant portion of the working document in a visual presentation. The Rotisserie functionality will allow revisions to be proposed and discussed with proposed alternatives. Multiple copies of the working document can be maintained to reflect different alternative revisions. Voting can then be undertaken on each proposed revision, or to select from among the multiple copies. Group creation of a document can be handled in a similar manner, with discussion, proposals, and voting on particular submissions for new sections.
Complicated problem with difficult issues on all sides.
Experience shows that standard messaging tools may make getting a handle on a tough issue difficult because they provide no way to divide a question into manageable parts. The flow of messages can also be overwhelming, without indication of where the conversation begins nor any sort of informed leader to guide newcomers through the process.
Our software will provide a way to comment on particular portions of a proposed text. Cross-referencing of these comments will enrich the reading of original material, as particular sections are hyperlinked to relevant current and archived comments.
Dispute on a particular question.
The software’s polling feature and its various configuration options (multiple choice, short answer, Rotisserie) will allow determination of the particular facet of a question that remains under dispute, so that the group may better focus its attention. The customizable reporting the software supports will enable users to view selections from past and current debate according to the various rating and classification schemes used by the group, including, perhaps, according to the self-identified affiliations of posters recorded in the participant biography file.
Comprehensive customizable reporting will enable users to view the selections from the discussion according a variety of criteria, including by message ratings, by any keyword or topic heading, and by filtering/break-outs by relevant self-identification facts if so configured during registration. Cross-tab analysis might report notable differences on an issue among subgroups of the online community. Furthermore, users so empowered by the group administrator might be permitted to retrieve raw voting data in some identify-protecting form, allowing them to perform their own analysis in separate software programs so as to attempt to find possible areas of consensus.
Difficult issue, discussion open to all constituents.
Discussion open to all constituents will take place in a fully public mode, meaning that registration for participation in the particular discussion group will be open to any interested party, and that reading the group’s current and archived messages will not even require that a reader be a registered user of the software.
Breakout groups can consider focused sub-issues in separate discussion lists, reporting their results back to the larger group.
Difficult issue, limited to committee members but with real-time or asynchronous public observation.
For public committee discussions, such as the ICANN DNSO Names Council teleconferences, the software would be configured so that full access will be possible only for committee members, although members of the public can read them concurrently (if the Council so chose) or only be able to review the archive of the completed 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.
Finally, the system may also allow for public discussion in a separate area. If so, it should facilitate direct links to specific actions taken by the committee, to specific proposals made by committee members, etc. 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. A synchronous chat rather than message board would be useful in these situations with links between chat logs and archived recordings.
Quotidian issue, discussion limited to committee members but public observation possible.
This situation would benefit from the development of a unified format for links to outside references (i.e. citation of a relevant bylaw). Also, one might add statistical analysis capability by classifying issues into predetermined categories, then automatically calculating certain statistics about the process as a whole (i.e., statistics about the frequency of various resolutions according to category).
Berkman Center for Internet & Society at Harvard Law School
Online Deliberative Discourse Research Project
Phase 1: Specification for Online Environment Platform
Since its founding in 1997, the Berkman Center has engaged in extensive research in teaching with technology. This research has been of an active character: we have taught online lecture and discussion series to thousands of people over the Internet, running our own software code, specifically designed with particular pedagogical questions and hypotheses in mind. Given our budget and resources, we have sought to develop prototypes rather than scalable, commercial-quality software. Furthermore, we have tried to avoid reinventing the wheel wherever possible, coding new forms of engagement to complement, rather than replace, existing applications such as chat, threaded messaging, and audiovisual streaming.
Based on our experience, we believe that designing and deploying a compatible set of tools as have described in this Phase 1 proposal will result in active, productive and responsible environments for the deliberative activities of a wide range of online communities, and we propose to undertake the following projects to test that hypothesis over the course of the next two years:
1. We will build basic software code, implemented through a frameworked web environment, through which modular tools can be developed, shared, and used among multiple developers, teachers, and students. This code will be designed to allow a bottom-up clearinghouse of formerly-disparate coding projects, browsable by possible contributors and users of that code – from any networked user.
2. We will adapt our innovative prototypes to be compatible with the above framework thus allowing flexibility, robustness, multiple classifications, the harnessing of network effects, and other valuable efficiencies.
3. We will adapt existing workhorse applications, such as threaded messaging, to fit into our framework.
Phase 2: Development and Testing
The specifications described above should be put to bid immediately under a Request For Proposals.
The Berkman Center estimates that it will be able to construct an operational beta version of the fundamental tools for online deliberative consultation in six months from date of funding at a minimum cost of $825,000.
Five programmers working full-time for six months, at a half-year salary of $45,000 each, will cost approximately $300,000, including overhead and benefits. Equipment, software, licensing, and related expenses will total at least $75,000. Project management personnel for one full year (including tasks of hiring programming personnel and supervision through installation) will add $150,000, including overhead and benefits.
Expenses to beta test a sample discourse and deliberation environment will include the expense of designing discussion content and recruitment of personnel and participants at an approximate cost of $300,000.
Thus, at least $825,000 will be required to complete Phase 2 (development and testing program. Full funding for Phase 2 must be secured by early fall of 2000, to allow planning and development to be completed in time to begin debate in preparation for ICANN’s second At-Large election (the first to elect the full complement of popular representatives to the Board).
Phase 3: Debugging and Amplification
Following the testing of Phase 2, an additional four months of programming work, at a minimum of $550,000, will be required to finalize and document the software and to ensure its compatibility with a number of platforms and software configurations. Instruction manuals for moderators and technical support personnel as well as sample participant obligation agreements will also be drafted during Phase 3.
ICANN would be an ideal candidate to publicly launch the software in conjunction with the second round of At Large elections currently scheduled for November of 2001. Arrangements for installation support, user training, compliance reviews, and other details of technical installation will require one full-time support individual (preferably one of the original programmers) for one month at the cost of $25,000 (including salary, overhead, travel, housing, etc.).
Arrangements should be made for long-term public distribution of the software under reasonable terms and conditions, including preparation of licenses, burning and shipping of disks and maintenance of a web site for downloads. Detailed estimates of these costs and studies of possible subcontractors should be made during Phase 3.
 See Jonathan Zittrain, “The Rise and Fall of Sysopdom,” 10 Harv. J.L. & Tech. 495 <http://jolt.law.harvard.edu/articles/10hjolt495.html> (visited 5/05/00).
 Robert A. Dahl, Democracy and Its Critics, (1989), at 307.
 Robert A. Dahl, Democracy and Its Critics, (1989), at 307.
 We recognize that other protocols and means of online interaction support communities. However, we will limit our discussion to communities relying on the World Wide Web and email because they currently predominate.
 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 <http://www.hypernews.org/> and Webboardä <http://webboard.oreilly.com/ >; their graphical means of depicting message flows is quite helpful for reviewing lengthy discussions. Most flexible of all, the Slashdot <http://www.slashdot.org/> system allows either threaded or linear message review according to individual user preferences, a form of filtering we think is central to self-governance of a community forming around discussion areas.
 Lawrence Lessig, Code and Other Laws of Cyberspace, (1999), at 199.
 In part these presumptive choices reflected our belief regarding the ICANN community’s current values; in part they also inevitably reflected our own backgrounds as citizens of the United States. We acknowledge the impact of our political heritage and the fact that we share many of its values even as we recognize that our political system has not always faithfully upheld those values. We further neither believe nor assert that the American system is the only means by which these values can be pursued or that these values are the only ones a society may prioritize; in fact, we hope that the software eventually arising from this project may reflect input of those from other backgrounds. As but one example, although the American tradition promotes majoritarian voting, the software will permit voting by proportion or other means. See “Vote Aggregation Methods” at <http://www.ccrc.wustl.edu/~lorracks/dsv/diss/node4.html> (Visited 5/20/00) for a comparison of various tabulation systems.
 Joshua Cohen, “Deliberation and Democratic Legitimacy,” in Deliberative Democracy: Essays on Reason and Politics, (James Bohman and William Rehg, eds., 1997), at 72.
 For example, although voice and video over the Web are improving in quality and are thought by some to add value to discussions, they are extremely bandwidth and processor intensive, and so we do not include them in this specification. Should they become more readily usable to a greater proportion of the online community, they may be appropriate to add to the software’s functionality at a later date.
 For a history of the Web’s evolution as the foremost Internet service, see Tim Berners-Lee, “The World Wide Web: Past, Present, and Future” (1996), <http://www.w3.org/People/Berners-Lee/1996/ppf.html> (Visited 5/25/00).
 See statement of Hotta from ISPCP Constituency during Cairo meeting in Section V(J) at <http://cyber.law.harvard.edu/icann/cairo/archive/scribe-icann-030900.html> (Visited 5/20/00).
 Software technology that converts documents from one language to another is still relatively primitive; while it would be easy to make available such systems via automatically-generated links to appropriate external sites, we do not expect to rely heavily on such systems in the short term. It is notable, however, that ICANN recently composed versions of its at-large membership pages in Chinese, French, German, Japanese, Korean, Portuguese, and Spanish. See <http://members.icann.org/> (Visited 7/10/00).
 As Bruckman observed in her experiment in online democracy, “The conversation is completely dominated by a few extremely vocal individuals who post at great length and if you wanted to respond to everything they said, it would take you all day.” Amy Bruckman, “Democracy in Cyberspace: Lessons from a Failed Political Experiment,” <http://web.mit.edu/womens-studies/www/bruckman.html> (Visited 12/14/00).
 Lawrence Lessig, Code and Other Laws of Cyberspace, (1999), at 142-3.
 See statistics on user contributions to the ICANN DNSO discussion list at <http://cyber.law.harvard.edu/rcs/listanalysis/DNSOAllMessagesBySender.html> (Visited 5/25/00). Note the number of posting from Jeff Williams, for example, an online personality who makes claims that have been repeatedly disproved by numerous critics.
 Plato told the story of Gyges in book II of The Republic. Gyges kills the king and sleeps with the queen once he recognizes that his ability to be invisible makes him unaccountable for his actions. See Plato, The Republic, <http://phd.evansville.edu/tetra_4/republic/gyges.htm> (Visited 5/20/00).
 As one commentator writes of his first experience of being flamed, “No one had ever said something like this to me before, and no one could have said this to me before: in any other medium these worlds would be, literally, unspeakable.” John Seabrook, “My First Flame,” New Yorker, June 6, 1994, at 71.
 See McVeigh v. Cohen, 983 F. Supp. 215 (D.D.C. 1998) in which a naval volunteer received an e-mail from an AOL screen name “boysrch” regarding a toy drive she was coordinating. Unsure of the sender’s identity, the woman reviewed the AOL member directory. She found a profile describing “boysrch” as “Tim” from Honolulu, Hawaii, working in the military, and had identified his marital status as “gay.” The e-mail and member directory listing found their way to the Judge Advocate General Corps where, upon investigation, the U.S. Navy suspected that “Tim” was Senior Chief Timothy McVeigh. Without obtaining a warrant, court order, or even speaking to McVeigh, Navy investigators contacted and spoke with an AOL member service representative who identified Timothy McVeigh as the owner of the account. The Navy then used this information to bring administrative discharge proceedings against McVeigh for “homosexual conduct, as evidenced by [his] statement that [he was] a homosexual.”
 Lawrence Lessig, Code and Other Laws of Cyberspace, (1999), at 89-90.
 As discussed in Appendix A, ICANN differs from a purely online community in that the impact of its decisions will be felt even by those who do not choose to participate in its decision-making process. However, if ICANN cannot demonstrate that a critical mass of its potential constituency endorses it, it will not retain the authority over its current purview. Its potential constituents can organize and meet in online and offline spaces other than those ICANN sponsors if ICANN’s processes and online environment do not gain their trust, and the consequent shrinking of ICANN’s ranks would be a telling indication of the hollow power of illegitimacy.
 For example, ICANN particularly seeks global diversity among its participants. Article V, Section 6, International Representation, “Bylaws of the Internet Corporation For Assigned Names And Numbers As Revised May 27, 1999” <http://www.icann.org/bylaws-09apr99.html#V> (Visited 5/05/00).
 Joshua Cohen, “Deliberation and Democratic Legitimacy,” in Deliberative Democracy: Essays on Reason and Politics, (Bohman and Rehg, eds., 1997), at 72.
 Joshua Cohen, “Deliberation and Democratic Legitimacy,” in Deliberative Democracy: Essays on Reason and Politics, (Bohman and Rehg, eds.), at 74.
 James Bohman, Public Deliberation: Pluralism, Complexity, and Democracy, (1996), at 96-97.
 Joshua Cohen, “Deliberation and Democratic Legitimacy,” in Deliberative Democracy: Essays on Reason and Politics, (Bohman and Rehg, eds., 1997), at 74-75.
 AOL/Roper Starch Cyberstudy 1999, November 11, 1999 <http://corp.aol.com/presentation_cyberstudy99.html> (Visited 5/05/00).
 AOL/Roper Starch Cyberstudy 1999, November 11, 1999 <http://corp.aol.com/presentation_cyberstudy99.html> (Visited 5/05/00).
 Howard Rheingold, “A Slice of My Life in My Virtual Community” in High Noon on the Electronic Frontier: Conceptual Issues in Cyberspace, (Ludlow ed., 1996), at 422-423.
 “How an Evil Clown, a Haitian Trickster Spirit, Two Wizards, and a Cast of Dozens Turned a Database into a Society,” in High Noon on the Electronic Frontier: Conceptual Issues in Cyberspace, (Ludlow ed., 1996), at 391.
 See John Suler’s account of how a member of the Palace attains the status of “wizard” in the Palace, in “Knowledge, Power, Wisdom…and your very own asterisk: Wizards at the Palace” (Visited 5/05/00) <http://www.rider.edu/users/suler/psycyber/wizards.html>. For another illustrative statement of the underlying attitude, see Eric Raymond, “How to Become A Hacker,” at <http://www.tuxedo.org/~esr/faqs/hacker-howto.html> (Visited 1/12/00).
 Jurgen Habermas, Legitimation Crisis, translated by Thomas McCarthy (1975), at 108.
 This is not to suggest that deliberative democracy is inconsistent with cultural pluralism. Yet if the ideals of deliberative democracy are not to lose their force, the elimination of some inequalities (such as the equality of access to information) must at least be theoretically possible. This is not impossible—as Kant puts it, “Ought implies can.” Quoted in James Bohman, Public Deliberation: Pluralism, Complexity, and Democracy, (1996), at 21. Differences in viewpoints resulting from cultural pluralism can in fact add to the strength of discourse by introducing unique views and perspectives into the discourse. Ibid.
 Jurgen Habermas, quoted in Howard Rheingold, The Virtual Community (1993), at 282. Habermas notes: “A portion of the public sphere is constituted in every conversation in which private persons come together to form a public. They are then acting neither as business or professional people conducting their private affairs, nor as legal consociates subject to the legal regulations of a state bureaucracy and obligated to obedience.”
 MUDs (Multi-User Domains) and MOOs (Multi-user, Object Oriented Domains) are predominant examples of this type of virtual environment. See Jennifer L. Mnookin, “Virtual(ly) Law: The Emergence of Law in LambdaMOO,” 2 J. Computer-Mediated Comm. (June 1996).
 We are cognizant that the confidentiality of such information is limited by legal process of jurisdictions whose reach includes the software’s administrators. However, ICANN must have such information to function properly, and thus we think the risk of occasional revelation under subpoena or comparative legal process is worthwhile.
 See, for example, the forum host eGroups.com <http://www.egroups.com> (Visited 5/20/00), which never displays complete email addresses on the site but instead provides a trusted intermediary web-based sendmail script for participants seeking to contact one another directly.
 Online public dialogue is often supplemented by one-to-one e-mail, telephone conversation, or face-to-face contact. See Peter Kollock and Marc A. Smith, “Managing the Virtual Commons: Cooperation and Conflict in Computer Communities” at <http://www.sscnet.ucla.edu/soc/faculty/kollock/papers/vcommons.htm> (Visited 5/05/00). For example, during a threaded messaging conference or electronic forum dialogue, like-minded groups of members might communicate with one another either by separate e-mail, real-time chat, or by phone in order to discuss issues or engage in further discourse. John Coate, “Cyberspace Innkeeping: Building Online Community,” in Reinventing Technology, Rediscovering Community: Critical Explorations of Computing as a Social Practice (Philip E. Agre, Douglas Schuler, eds., 1997) at 170-172.
 Back-channel communication is also often the next step for members of online communities who desire to enhance relationships created online. Barry Wellman & Milena Gulia, “Virtual Communities as Communities: Net Surfers Don’t Ride Alone,” in Communities in Cyberspace, (Marc A. Smith & Peter Kollock eds., 1999), at 184, 186.
 By graphical, we mean that the primarily text-based presentation would be structured in a way to suggest texture and depth of discussion in a more elaborate layout than a traditional threaded messaging display page.
 As with many of the procedural issues in this software, the ICANN community should make the resolution of the appropriate length of time.
 This can be traced back to Kant (viz. The problem is how to bring about “the public use of reason.”) Quoted in Joshua Cohen, “Deliberation and Democratic Legitimacy,” in Deliberative Democracy: Essays on Reason and Politics, (Bohman and Rehg, eds., 1997), at 74.
 Joshua Cohen, “Deliberation and Democratic Legitimacy,” in Deliberative Democracy: Essays on Reason and Politics, (Bohman and Rehg, eds., 1997), at 72-74.
 For example, in Deliberative Polling™, a group representative of an issue’s constituency is polled to determine what the group opinion is, and a period of education takes place prior to the debate and polling. See James S. Fishkin, The Voice of the People: Public Opinion and Democracy, (1997, Expanded Edition).
 This feature will be especially useful for groups writing or considering documents. Individuals or subgroups could provide their own commentary or suggested changes for consideration.
 Obviously this will be a judgment call, though the creation of standards guiding this determination would be helpful.
 We recognize that some of these skills are best learned through experience, and that teaching them over a distance may be essentially impossible since doing so requires the user to use the skills he is seeking to learn to access the teaching. However, technical support personnel must be ready to answer what may seem to be obvious or basic questions with straightforward answers nonetheless.
 Online discourse communities have been carefully crafted such that automated controls obviated the need for active moderation of discussion. For example, in the RealityCheck.com experiment, a series of strict automated controls was implemented to govern an online group discussion of the impeachment of United States President Bill Clinton. Only a limited number of people were permitted to join, the discussion terminated on a set date, and participants committed to active participation for the duration of the discussion. An evaluation by WebLab of the RealityCheck system found that “sixty percent of the survey respondents said their respect for other members increased over time, four times the proportion that said respect decreased.” Web Lab, “Changing the Nature of Online Conversation: An Evaluation of RealityCheck.com,” <http://www.weblab.org/sgd/excerpt.pdf> (Visited 5/10/00). However, the carefully constructed nature of these experiments makes them less appropriate to the ICANN context; as an ongoing democratic enterprise, ICANN cannot and should not limit participation to those who enter by a certain date or otherwise overly restrict input.
 An example of how moderators/controllers work can be seen in the experiences of the WELL, Gail Ann Williams, “Online Moderator Guidelines and Community – Building Tips,” <http://www.well.com/confteam/hosting.html> (Visited 5/10/00), or in the functions of the “wizards” that operate within the MUD/MOO environments. Wizards, for example, are vested with technological and social power, in the sense that the community first assents to the conferment of wizard status on a member who is then vested with access to the technological tools that aid in enforcement within these environments.
 See Jonathan Zittrain, The Rise and Fall of Sysopdom, 10 Harv. J.L. & Tech. 495 <http://jolt.law.harvard.edu/articles/10hjolt495.html> (Visited 5/05/00); See also, Bruckman’s account in “Democracy’ in Cyberspace: Lessons from a Failed Political Experiment” <http://web.mit.edu/afs/athena.mit.edu/org/w/womens-studies/www/bruckman.html> (Visited 12/14/00).
 See Bruckman’s account in “Democracy’ in Cyberspace: Lessons from a Failed Political Experiment” <http://web.mit.edu/afs/athena.mit.edu/org/w/womens-studies/www/bruckman.html> (Visited 12/14/00) and John Suler, “On Being A God” at <http://www.rider.edu/users/suler/psycyber/jbum.html> (Visited 5/10/00).
 Connected to this is the phenomenon of the benevolent dictatorship. Out of the controller/moderator/sysop types and the owner/creator types, there will occasionally emerge (or inherently exist) in some online communities, a personality with the attributes of a benevolent dictator – in whom the functions and powers of rulemaking, enforcement/control, and adjudication/dispute resolution, all converge. There may be a variety of circumstances that lead to such convergence, but often this is a result of the combined strength of character, authority, reliability/credibility and founding role of the personality in question. Most significantly, perhaps, the majority of participants in these benevolently dictated communities support and advocate such convergence. Examples of such benevolent dictatorships (which do not in any way appear a reflection on personal values, only those of the group) are the roles played, inter alia, by Howard Rheingold in Electric Minds, see account by Nancy White, “Musings on Online Community Governance – Lessons Learned From My Electric Minds Experience” <http://www.fullcirc.com/community/governance.htm> (Visited 5/12/00), and Pavel Curtis in LambdaMOO, see Maltz, “Customary Law & Power in Internet Communities,” Journal of Computer Mediated Communication, Vol.2, Issue 1 <http://www.ascusc.org/jcmc/vol2/issue1/custom.html> (Visited 2/20/00); Julian Dibbell, “A Rape in Cyberspace,” <http://www.levity.com/julian/bungle_print.html> (Visited 2/08/00).
 See Peter Kollock and Marc A. Smith, “Managing the Virtual Commons: Cooperation and Conflict in Computer Communities” at <http://www.sscnet.ucla.edu/soc/faculty/kollock/papers/vcommons.htm> (Visited 5/01/00); Howard Rheingold, “The Art of Hosting Good Conversations Online” <http://www.rheingold.com/texts/artonlinehost.html> (Visited 1/12/00).
 For examples from Usenet, see Peter Kollock, “The Economies of Online Cooperation: Gifts and Public Goods in Cyberspace in Communities” in Communities in Cyberspace, (Marc A. Smith & Peter Kollock eds., 1999) at 220-221. See also Jennifer L. Mnookin, “Virtual(ly) Law: The Emergence of Law in LambdaMOO,” 2 J. Computer-Mediated Comm. (June 1996) <http://www.ascusc.org/jcmc/vol2/issue1/lambda.html> (Visited 4/25/00) (describing MOO rules).
 And indeed, Lessig identifies code as only one of four tensions that may serve to regulate cyberspace at large, law (black-letter), markets and norms being the others. See Lawrence Lessig, Code and Other Laws of Cyberspace, (1999), at 87 et seq.
 For this reason, some groups may elect to have a moderator who is not directly interested in the outcome or will not have a vote in the final decision.
 A discussion group could task its moderator with the maintenance of a reference document that does not identify the proponents of proposals, but that contains summaries by proponents of their own proposals, and of their objections to others’ proposals.
 See Morgens H. Hansen, The Athenian Democracy in the Age of Demosthenes: Structure, Principles and Ideology, (1991), at 314.
 In ancient Athens, the Council (whose job it was to prepare items for the larger assembly) was convened and organized by a president. This position was not elected, but rather rotated among the membership such that “every fourth adult male Athenian citizen could say, ‘I have been for twenty-four hours President of Athens’ — but no Athenian citizen could ever boast of having been so for more than twenty-four hours.” See also Roderick T. Long, “The Athenian Constitution: Government by Jury and Referendum,” <http://www.freenation.org/a/f41l1.html> (Visited 12/14/00).
 Though the server-side versus client-side distinction is meaningful also in a technical sense, referring to the actual location at which filtering is performed, we mean it here to describe the difference between centralized filtering configured by some empowered authority as distinguished from a single user individually deciding to filter another user. In the suggested architecture, primarily a web-based discussion space, all filtering would actually take place on the server, but both centrally-configured and user-configured filters would be possible.
 Such a system is currently used on Slashdot <http://www.slashdot.org/> (Visited 5/05/00), which takes its moderators (who rate posts as good or bad) from a randomly drawn pool of users who meet certain criteria (e.g. they must be regular users). Among the pool of Slashdot users who fit the predetermined criteria, the task of moderating is randomly assigned and moderators only serve for a short time, perhaps only for the duration of the deliberation on a particular issue. This prevents moderators from abusing their power while producing a system where Slashdot users can decide what level of comments they want to read. The result is a system which reduces clutter, allows users to see only high quality posts if they wish, and does not permit moderators to act as tyrants. See “Slashdot Moderation,” <http://slashdot.org/moderation.shtml> (Visited 2/08/00).
 We refer here to messages facially unrelated to ICANN, its community, and the issues they address, such as commercial spam.
 As does the ICANN DNSO, see <http://www.dnso.org/clubpublic/ga/Arc03/msg01146.html> (Visited 5/15/00).
 Participants who choose to read all messages rather than filtering by rating will then see the offending message and rate it, and a message beyond the acceptable volume that is nonetheless of exceptional substantive value might overcome be able to overcome its penalty and be seen by filtering participants if rated sufficiently highly by non-filterers.
 Lorrie Faith Cranor, Electronic Voting Hot List <http://www.ccrc.wustl.edu/~lorracks/sensus/hotlist.html> (Visited 5/05/00). See in particular D.R. Newman, “The On-line Preferendum” <http://www.qub.ac.uk/mgt/papers/prefer/> (Visited 5/05/00).
 See “Ballot Collection” at <http://www.ccrc.wustl.edu/~lorracks/dsv/diss/node5.html> (Visited 6/20/00).
 Preferential voting systems are considered by many to provide greater precision and expression of minority viewpoints. In such a system, candidates are ranked in order of preference by voters and then these rankings are compiled, with the candidate with the widest overall support (as determined according to one of several competing methodologies) having a greater chance of victory than would a candidate who is the first choice of the largest number of people but who ranks very low for other voters. In other words, preferential voting privileges candidates with whom the largest group could be satisfied over candidates who engender love in some group but only indifference or actual dislike in others.
 We recognize the superiority of having voting by email enabled. However, security concerns lead us to believe it inappropriate.
 Compare a common offline voting system. A voter can vote only at a certain location. At that site, he presents himself and identifying credentials to a voting official. The official checks his name against a list of voters eligible to vote at that site who have not yet done so, and, if satisfied, allows the voter entry to the voting booth. Once within the booth, the voter casts his ballot without identifying himself to the vote-taking mechanism. Since no record is kept of the time his identity was authenticated, no cross-comparison of the booth’s and list-keeper’s records could identify his vote with his name. His vote has thus been authenticated as unique while remaining anonymous.
 This investment, however, can be quite large, with some MUDers spending in excess of eighty hours per week building and maintaining MUD spaces. See Sherry Turkle, Life on the Screen: Identity in the Age of the Internet, (1995), at 200-201.
 “DOJ, ICANN Accused of Collusion,” <http://news.cnet.com/news/0-1005-200-345544.html?tag=st> (Visited 7/26/00).
 “The Internet is the Wild West of technology” says Donald Gooding, research partner at Accel Partners, “Nobody has written the rules yet.” John W. Verity and Robert D. Hof, “The Internet,” Business Week, 14 November 1994.
 See “Free Speech” in The Rights and Responsibilities of Participants in Networked Communities, (Dorothy E. Denning & Herbert S. Lin, eds., 1994), at 55-68.
 See “Privacy,” in The Rights and Responsibilities of Participants in Networked Communities, (Dorothy E. Denning & Herbert S. Lin, eds., 1994), at 99-111.
 See Article III, “Transparency and Procedures, Bylaws of the Internet Corporation for Assigned Names and Numbers” As Revised May 27, 1999, <http://www.icann.org/general/bylaws.htm - III> (Visited 5/05/00).
 ICANN’s mailing lists, in particular the list operated by the General Assembly of the DNSO and also the various comment-receiving addresses set up to receive feedback on some issues, have lots of messages, but remain mostly stuck on procedure. For list archives, see ICANN/DNSO List of Mailing (sic) Lists and Archives <http://www.dnso.org/listsdnso.html> (visited May 5, 2000).
 Maltz, “Customary Law & Power in Internet Communities,” Journal of Computer Mediated Communication, Vol.2, Issue 1 <http://www.ascusc.org/jcmc/vol2/issue1/custom.html> (Visited 2/20/00); Julian Dibbell, “A Rape in Cyberspace,” <http://www.levity.com/julian/bungle_print.html> (Visited 2/08/00).
 Examples transplanted from real-life include ASAP (“as soon as possible”) and FYI (“for your information”). Others have evolved online, such as BTW (“by the way”) and FWIW (“for what it’s worth”).
 Elizabeth M. Reid, “Communication and Community on Internet Relay Chat: Constructing Communities” in High Noon on the Electronic Frontier: Conceptual Issues in Cyberspace, 397, 399-400 (Ludlow, ed., 1996). “Smiley” dictionaries abound; see, for example, <http://wellweb.com/behappy/smiley.htm>, <http://www.chatlist.com/faces.html>, and <http://www.eff.org/papers/eegtti/eeg_286.html> (All visited 4/12/00).
 See Rinaldi, “Guidelines for Electronic Communications in The Net: User Guidelines and Netiquette” <http://www.fau.edu/netiquette/net/elec.html> (Visited 4/12/00). At least one online community is averse to emoticon use – see Stacy Horn, Cyberville (1998).
 Civic Practices Network, “Participant Guidelines for an Electronic Study Group,” <http://www.cpn.org/sections/tools/manuals/electronic_handbook5.html> (Visited 1/06/00).
 Philosopher Paul Grice offers one formulation of the obligations of discussion participants as the Cooperative Principle: “Make your conversational contribution such as is required, at the stage at which it occurs, by the accepted purpose or direction of the talk exchange in which you are engaged.” Paul Grice, Studies in the Way of Words, (Cambridge: Harvard University Press, 1989), 26.
 Robert J. Fogelin and Walter Sinnott-Armstrong, Understanding Arguments, 17-19 (1997).