User:Eleanorg/thesis/draft1.1/online systems

From XPUB & Lens-Based wiki

So far I have discussed consent as it relates to sexual negotiation. The close feminist scrutiny of what happens in the process of reaching consent in this context helps us to put other types of consent, collaboration and agreement under the microscope too. Here I will look at the example of democratic collaboration as it is facilitated by software. I'll use Kleinig's terms - the ontology, signification and grammar of consent - to look closely at which models of consent are at work in three online platforms, where 'consent' has been encoded for computation.

The three collaborative systems I'll look at are Wikipedia (built on the MediaWiki software), e-consensus, and Doodle. While designed for varied use-cases, what these systems have in common is that they accept input from various users, and allow users to co-ordinate that input by offering various ways of establishing consensus. All of them priviledge democratic negotiation, although each of them encode this process in slightly different ways.


Doodle

Doodle is a clear and elegant example of a decision-making system which encodes 'common-sense' ideas about reaching agreement. Doodle lets anyone who knows the URL of a poll share their preferred days for a meeting, via a simple calendar 'polling' interface. Users of Doodle aren't consenting to anything per se - it is intended as an information-gathering tool to help a meeting planner chose the best date. However, it is an interesting example of the way that individual vs group preferences can be recorded and displayed. Its aim is to arrive at a consensus by consulting with each group member, and to arrive at a date which may not suit everybody, but which achieves the maximum possible overlap of individual preferences.

What is Doodle's grammar of consent? In any given instance a proposal can only be made by one person, the poll initiator. The initiator chooses which dates to include in the poll, thus delimiting the choices presented. For each date, participants have by default only two choices: to check the box (meaning, I can make it), or to leave it unchecked (can't make it). Checked dates turn green, unchecked dates turn red. The poll initiator can enable, if they choose, a halfway option 'Ifneedbe', which when checked displays orange. The single poll initiator therefore poses a question with various options, in line with the classical "yes or no" grammar of consent.

How is consent signified? For each date, users may check the box, or leave it blank. If no dates are suitable, the participant may save the form without checking any boxes, or click a button reading "Can't make it", which also submits the form blank. By implication, then, silence signifies not consent but the opposite; while agreement must be actively signalled with by the gesture of ticking the relevant box. Any more detailed ambiguity than 'Ifneedbe' must be recorded in a separate comments box below the poll, which is not semantically linked to it. The system narrows users' options in order to produce a clear numeric 'favourite'; thus the checked boxes can only be a rough guide, and not a reliable indication of felt preferences or desires.

Wikipedia

Wikipedia articles may be edited by many users, with the aim of arriving at a consensus on the text.

What is Wikipedia's grammar of consent? In Kleinig's terms, consent is given by A to B, for P. Here, P is any change to the text. B is the editor making the change. She seeks the consent of (plural) A, all other users. Wikipedia's grammar of consent thus conforms to a fairly conservative one in which consent is 'sought' and 'given'. However, it begins to stretch this grammar, as multiple users make proposals in an ongoing and collaborative process. A does not merely play the passive role of saying 'yes' or 'no', but is expected to be an active agent contributing her own changes if she disagrees. It is unclear whether A includes readers of Wikipedia who do not have an account on the site. Are they, by reading the text and not creating an account in order to change it, consenting to the status quo? This expectation of agency informs how consent is signified.

How is consent signified? In its policy on consensus, Wikipedia (2013a) states clearly that: "Any edit that is not disputed or reverted by another editor can be assumed to have consensus." A related essay linked from this statement, "Silence and Consensus" (Wikipedia Editors, 2013b) - though not a policy document - comments that "Consensus can be presumed to exist until voiced disagreement becomes evident... [because] In wiki-editing, it is difficult to get positive affirmation for your edits..." (ibid). Kleinig himself notes that signifiers are culturally-specific, and may include silence in some cases (Kleinig 2010, p.11). Because of this, "there must be a convention whereby consent given is recognized as such" (ibid). Wikipedia's policy on Consensus attempts to set in place this convention. However, this convention is not without controversy. The Wikipedia Essay "Silence Means Nothing" gives several examples of things that silence may signify other than consent: "polite disagreement", not having seen, or choosing to ignore an edit (Wikipedia Editors 2013c).

What is the ontology of consent? Because consent in Wikipedia is signalled by silence, there is no clear distinction made between the state of mind of agreement, and the act of giving consent. Indeed, the chronological version control of in wiki software means that the only active gesture available - making an edit - is one which signals /lack/ of consent to the status-quo.

eConsensus

EConsensus.org is a relatively new online tool to help activists organize. Within 'groups', group members can create and comment upon 'proposals' as well as creating 'decisions'. The image to the left shows the commenting options which are displayed next to each proposal. The current totals for each type of comment are shown. Clicking on one creates a new comment with that tag.

What is its grammar of consent? What is being consented to is clear on eConsensus.org - proposals are named as such and given a unique ID. Proposals are commented on, and ultimately consented to (or not) by group members, whose name is registered next to their consent (if given). It attempts to mimic face-to-face consensus decision-making used in activist groups, in which a proposal is presented, discussed, modified and ultimately consented to by all involved. It is notable that each proposal may be modified at any time - possibly creating confusion as to which version of the proposal the comments (and consent) below refer to.

What is the ontology of consent? Group users may comment upon proposals, and 'tag' their comment with only one option from this list: 'Question', 'Danger', 'Concerns', 'Consent', or merely 'Comment'. Consent must therefore be communicated as a clear gesture; writing a positive comment without tagging it as 'Consent' does not constitute consent. (Although users of the software may, of course, choose to implement their own conventions.)

How is consent signified? Consent is signalled by selecting 'Consent' from a dropdown list of tags (called 'ratings') when writing a comment on a proposal. The visual language used to display these tags is blunt. Comments tagged as 'Danger' have a red mark; comments tagged 'Consent' are bright green. 'Concerns' are orange, and sit in between Danger and Consent in the interface, creating a symbolic colour spectrum. (These are the very same colours that Doodle uses to encode 'yes', 'no' and 'ifneedbe'.) Unlike Doodle, eConsensus lets users decide how to tag their responses, rather than giving initiators the power to decide whether or not users will be able to express ambivalance ('Ifneedbe' in Doodle; 'Concern' in eConsensus).

It is interesting to note that it is not possible to give consent and to signal danger or concern in the same comment. 'Comment' and 'Question' sit at either end of this spectrum, apparently unrelated to the middle three options in their respective shades of grey and blue. There is no option to refuse consent, ie 'block' a proposal, as there is in conventional face-to-face consensus, or in the Doodle interface. The assumption in the system must therefore be that proposals are never final, and are open to modification as long as concerns or dangers persist. It takes the Wikipedia approach of assuming that a rejection of the current proposal should be expressed as a modification, not a refusal, and makes it technically impossible to say "no".


Note: I might split up this section and intersperse the text with these examples rather than putting them all together. Could use to illustrate a spectrum from 'over-simplified/coercive' to 'more open space'?