Project Brief

From ConsensusWiki

Jump to: navigation, search

This article is open to criticism and scrutiny. To use make an objection on any point, add the following to the wiki markup:


<ul><li class="objection">Your objection here </li></ul>


which will return:

  • Your objection here

Contents

Introduction

The broad aim of the project is to produce a web-based tool that helps users to determine what the consensus is for any given topic within a group. All users have the opportunity to participate in a small, or big way, to build consensus within a group. By 'group' we mean any organization that adopts the software, be it companies, communities or even a whole society. The software, must therefore be scalable to user bases of scores to millions.

The Wikipedia model achieves consensus for knowledge well, however, where issues and conflicts occur, they are difficult to resolve. ConsensusWiki will be designed to specifically deal with non-factual issues, and enter into the domain of beliefs and moral values, politics and collective decision making. Wikipedia is an invaluable resource of collective knowledge, ConsensusWiki is intended to be an invaluable resource of collective values and action, where conflict can only be resolved through cooperation. Where conflict is difficult to resolve, it must be shown for what it is, and not brushed under the carpet.

Few projects have attempted to achieve consensus decisions in this way. However, readers should be aware of OurDocument, formerly known as ConsensusWiki by freakish chance. It is a project by Hunter Ellinger, which has similar aims to this project, although it varies in approach. Nevertheless, the author of this article fully acknowledges the similarities of this design brief and that of Mr Ellinger’s. There are notable differences which do mark the two projects apart.

It is also necessary to point out Civic Evolution at this point. This software, made by Brian Sullivan revolves around small, local teams drafting proposals, through deliberation. ConsensusWiki is different in that it does not involve teams that must start and finish each proposal project, just individuals who can contribute in a large or small way. Furthermore, ConsensusWiki is far more flexible, to cater for many situations.

Before reading further, those involved in the project are encouraged to understand the consensus decision making process, by consulting these resources:

The aims of the web-based software, ConsensusWiki, are to enable any group to:

  • build consensus of belief and stance, in relation to the topic
  • build consensus on action, based on the foundation of the above
  • achieve the above through a mix of Wiki drafting and editing, and deliberation through message forums
  • make the use of criticism the cornerstone of the consensus building process

Assumptions

The rationale that follows is based on these assumptions:

  • The internet provides an opportunity for a practical and large scale consensus building system that is not practical in the physical world
  • Open participation through the internet is accessible, therefore democratic
  • More people will participate in a process if they have power over that process
  • Ego and authorship can hinder cooperation
  • Majority power promotes majority-minority conflict
  • Decisions made through consensus are more desirable than majority decisions
  • Building consensus is an open ended process
    • Although actions tend to require deadlines, the speed of decision making will be determined by its urgency

Fundamental Concepts

The fundamentals of the software is as follows:

  • A wiki page is created in the normal way. The page represents an issue of concern, or a collection of related issues.
  • A discussion forum is integrated into the wiki page, where links to discussion threads are inserted into the various sections of content in the page.
  • Users objections will be displayed as part of the wiki page.

The wiki page is the most important aspect of the project. The formatting rules must be flexible enough to cater for many needs (like the wiki). By reading it, the user must be able to understand:

  • The background of the issue,
  • its conflicting arguments,
  • the consensus of beliefs and values,
  • the consensus of proposed actions,
  • points of disagreement,
  • evaluation – the consequences of past decisions.

The wiki represents the consensus of the topic. The discussion functionality of ConsensusWiki will add an extra depth to the topic(s), by using the strength of discussion, individual experiences and opinions to justify the changes that are made in the wiki.

Design considerations

Before the specifics of the software is covered, it will be necessary to go through the considerations taken during design.

Open to everyone

Like the wiki model, there will be an aspiration to make the core processes in ConsensusWiki open to everyone and anyone, in line with the Wikipedia ethos. Abuses can be corrected as every amendment to ConsensusWiki is recorded, and anyone can retrieve previous versions. Users should have little or no limits to the level of contribution.

Every user will have the power to:

  • Contribute in building the consensus page
  • Edit and change the consensus page
  • Submit proposals and solutions to problems
  • Object to any part of the page
  • Block any proposal which can be deemed immoral
  • Facilitate discussion (perhaps even moderate to an extent)
  • Mediate between conflicting arguments

Any pages that are not consensual, should be clearly shown as such. In general, the consensus page will be devoid of authorship. The discussion pages, on the other hand will be accountable to the author, and is the only appropriate place for personal opinions to be shared.

Discussion

The purpose of the discussion forums is to provide the necessary space for individuals to deliberate in building consensus. It is important for the discussion of new ideas, and to express the justifications for the consensus proposals or beliefs. The discussions should be in the spirit of co-operation, and a system designed to encourage this is desired.

Moderation of forums may be required, but this should be in the hands of ordinary users as much as possible. With current PHPBB software, normal users cannot regulate discussion forums without a moderator; a solution to self-regulate discussion should be sought in the future. Such a solution is not necessary until the Alpha version of the software is released.

Open ended

The page concerning a topic will not be closed unless there are special circumstances. Otherwise, the process of building consensus will be open-ended. The system must not enforce deadlines, as it is assumed that consensus is an ever-changing entity. This will also ensure that no one is excluded from the process by the constraints of time. This does not stop users from setting informal deadlines for action as part of a proposal (although other users will be able to amend the deadline as they see fit).

Action

The translation of the contents of ConsensusWiki into real world action is an important part of the process. Group action requires the commitment of individuals. On ConsensusWiki, individuals will be able to make their pledge to act on any particular proposal. Where a proposal requires individuals to act, each user will have the option to make a pledge. Each pledge will be recorded and displayed. See PledgeBank for a working example of such a system – indeed, integration with this particular system may be the best option.

Proposals that require action from specific individuals or groups (e.g. from government), should make this clear within the proposal. It is assumed that it would be dangerous for any democratic organisation to go against a strong consensus. This disincentive should encourage organisations to largely follow consensus policies automatically.

Design Specification

The following is the detailed description of how the software will work from the user’s point of view. The Example page also describes the styling requirements of each document.

Approach

ConsensusWiki will be based on MediaWiki and PHPBB forums open-source software. They will be integrated into each other. ConsensusWiki will be a ‘splicing’ of these two different, but excellent communication tools, with added features.

In the programming of ConsensusWiki, programmers should make use of hooks and plugins where possible. This will ensure that future updates of MediaWiki and PHPBB can be integrated easily into ConsensusWiki as they are needed.

All changes must be documented.

MediaWiki and PHPBB Forums user login integration (version 0.1.0)

The login process must be integrated. Users that log into MediaWiki will automatically login to the forums. A MOD that achieves this already exists, and must be integrated.

At this stage, it may also be worth integrating the databases of MediaWiki and PHPBB forums.

MediaWiki PHPBB Forums integration (version 0.2.0)

The integration should do the following:

  • As new pages are created on the MediaWiki, new forums on PHPBB will be created automatically, and vice-versa.
  • The wikitext will be broken into sections, as is already done (in parser.php), but to a greater degree. List items will be broken into separate sections.
  • Within the wikitext, the following code: [[discuss| topic name here]] will:
    • create a new thread in the forum attached to the new page, called “topic name here”
    • provide a link to the thread “topic name here” within the section where the code resides. The link will read “edit/discuss”
  • On clicking the link “edit/discuss” the complete thread with posts will be shown. At the top of this standard page:
    • A form will be displayed, ready for the user to make a post, contributing to the discussion
    • The wikitext of the section that the thread is attached to will be shown and will be directly editable
    • This ensures that discussion and editing of the wiki are conducted at the same time.
  • If the code [[discuss| topic name here]] is deleted from the wikitext, then the thread that it is linked to will be moved to a ‘deleted’ category in the forums. If the thread name is changed, then the old thread will be moved to the deleted category, then a new thread bearing the new name will be created.

The completion of the above steps will succeed in achieving software version 0.2.0. A stable release of version 0.2.0 will have enough functionality to be useful in its own right. Further features are required to make this software useful for building consensus.

Layout of Wiki page

The layout and formatting of the wiki page representing a particular issue is not set. Indeed, there should be no concrete prescription in order that the software remains flexible for many situations. However, for most pages, the following order is envisioned, and will be assumed for the sake of development:

  • Page name / Topic
  • Introduction – will be a short summary of the issue
  • Background / Further Reading – will set the scene of the issue. Sources of information will be quoted, and opposing arguments introduced. Will be neutral and factual only, along Wikipedia guidelines
  • Beliefs / Values / Foundation – The beliefs and values of the consensus are envisioned to evolve out of the specific situation. As consensus values are established, firm proposals can be produced.
    • Proposal / Action – Proposals and actions are rooted in the foundation of consensus values and beliefs. As such, a proposal is seen
  • Evaluation
  • References


Objection, Reservation and Block markers(version 0.3.0)

Criticism is the cornerstone of building consensus. So objections, reservations and blocks must take centre stage. If at any point, the user disagrees with what is written on the wiki pages, but does not want to edit the text, they have the option of making an objection, reservation or block marker for that particular point.

  • Objections are used when an individual sees that a proposal has flaws, thinks that its essence is generally right, and can be improved.
  • Reservations are used when an individual sees that a proposal has flaws, but the flaws are not bad enough to hinder the proposal from going ahead.
  • Blocks are used when an individual believes that a proposal directly contravenes a belief, or value held by the consensus. A single block on a proposal is normally enough to stop a proposal from going ahead without major redrafting.

To insert one of these markers, the user will enter one of the following into the wikitext:

* objection: I object to this because of foo

* reservation: I agree largely, but I have reservations about bar

* block: This proposal directly goes against the consensus belief in foobar, and is immoral

Which will return the following markers:

  • objection: I object to this because of foo
  • reservation: I agree largely, but I have reservations about bar
  • block: This proposal directly goes against the consensus belief in foobar, and is immoral

These objections, reservations and blocks will let the user looking at the page understand these points of disagreement at the outset, pointing out the flaws in the document that need to be addressed.

These markers can be removed by anyone, just as they can be put back by anyone. A legitimate situation in which a user would remove an objection to a proposal, would be if that user had changed the proposal to accommodate the objections, thereby nullifying it.

The completion of the marker system will succeed in achieving software version 0.3.0. The completion up to this level means that ConsensusWiki can function at its basic level, and will be released as an alpha version.

Further integration of features between MediaWiki and PHPBB forums

The basic integration has already taken place. Ways must be devised to integrate many of the peripheral features of MediaWiki and PHPBB forums. This section is an incomplete specification, but is intended as a guide.

  • Users preferences / control panel integration
  • Private messaging integration
  • Integrate style / look between wiki and forums

Further features to improve

  • Display the number of edits and page views at the top of the page.
  • Display the level of consensus for each section
    • This can be mathematically calculated according to the number of edits, views, points of disagreement etc.
  • Languages – ConsensusWiki must in the long run cater for many languages, and this must be taken into account.
  • Location – many issues and topics are specific to a location, and this must be made clear for each topic. MediaWiki’s existing category system could be manipulated to deal with this. Topics should also be browsable by location.
  • Groups – All users can create a group, or be part of a group. External organisations should not create an organisation account on ConsensusWiki, but create a group that bears the organisation’s name.
  • Tidy up / delete unnecessary features from MediaWiki / PHPBB forums.