OneHyperText

MeatballWiki | RecentChanges | Random Page | Indices | Categories

A web version of OneText. By OneHyperText, I mean a hypertext that specifically supports, and possibly includes, a OneText and related processes.

Sounds so, so, ever so close to a wiki. There is only one version on the surface that everyone must collaborate to build. It isn't exactly like a wiki as it is possible for pages with opposing viewpoints to be created. By the way, I think this is one of the points that Cliff and I disagree on. ViewPoint allows divergent opinions and sources, where I prefer a unified whole--divergent opinions and everything. (See Wiki:ThereforeBut.) --SunirShah

Some CriticalSuccessFactors? of a OneHyperText, over and above the CSFs for a OneText:

What Wiki features help or hinder efficient and effective consensus building, especially in comparison to more structured collaborative web spaces?

Current state of affairs

Somebody opens a new page or introduces a new idea into an existing page. Other people start a discussion by either asking more questions or disagreeing. As the discussion grows, the page goes into ThreadMode. As the discussion dies down again, somebody will refactor the page back into DocumentMode.

In order to avoid loss of focus, discussions are often moved to another page, usually named FooDiscussion. Often this is part of the refactoring process.

Based on the current state of affairs, the following points seem to be important factors:

People and Issues are separated because signatures may be factored away and often enough contributions are anonymous.
Options are easy to generate because new pages are easily generated, thereby forking text development.
All participants are essentially equal (except for the GodKing).
Dirty tricks are discouraged via SoftSecurity.
Objective discussion is encouraged via PeerReview.

Possible problems:

There is no reward for reworking unless you add your signature, thereby mixing people and issues again.

: Rebuttal. Reworking improves clarity. Clarity is the reward. Often when I don't understand a page or code, I will rework it until it makes sense again. For instance, I didn't understand everything that was written on KeptPages, so I reworked it.

: It presumably depends on the person and situation. I just refactored XmlDotGov and the pages related to this page when I realized what a pigs ear I'd made of the initial shot. The last thing I want to do is add my signature to admit it was me that made the mess in the first place! ;>

Lack of readers prevents effective PeerReview.
SoftSecurity doesn't prevent people problems.

: Rebuttal. HardSecurity doesn't prevent people problems, either; but it exacerbates them.

What useful formal outputs could one hope to construct from a web based consensus building process via a Wiki?

A web implementation of a OneText (the formal agreement between parties that is the main output from the GettingToYes consensus building method) makes a lot of sense, but it all but demands mandatory authentication of every edit. Could a Wiki system support development of a OneText without losing its Wikiness?

Why authenticate attributions?

As the discussion goes on, dies down, and gets refactored, a new document emerges. The consensus. Often enough it is a list of pros and cons on a certain subject. Why should attributions matter?

: I've removed mentions of attributions from the opening statement above. I believe that the OneText method pretty much demands authentication of contributions to the formal OneText so that the author of a change could be traced. (Given the latter, I decided you might as well just attribute everything, but that is a red herring.)

: In particular, OwenAmbur? of XmlDotGov, the guy who introduced the notion of a OneText on the web, said:

: "... no doubt, many people may find wikis wacky... Not me! I'm among the disciples of the Happy Warrior's admonition to "trust, but verify". In short, I believe that anyone should be empowered and enabled to add whatever value they see fit -- provided that: a) they are *accountable* for their own contributions (or lack thereof) to the record that is collectively created, and b) their "contributions" are not imposed upon those who have no desire to receive them (i.e., pull versus push paradigm)."

: "In the broader context of the U.S. federal government, that means the use of Department of Defense Std. 5015.2 compliant E-records management systems. (Department of Defense Std. 5015.2 embodies legal and logical requirements that are applicable to all U.S. federal agencies with respect to the management of records. <http://jitc.fhu.disa.mil/recmgt/>;. That National Archives and Records Administration has endorsed it for use by all U.S. federal agencies. <http://www.nara.gov/records/nwm04-01.html>;)"

Consider the AuditTrail SoftSecurity pattern.

: He later added:

: "Authentication is required?"

: "For business quality records, the answer is yes."

: "Can a system be RMA compliant even if most people have the same authorization level, and that level provides rights to change almost anything?"

: "Organizations may use whatever process that may make sense to create their records. When the purpose of the organization is to achieve "voluntary consensus," obviously those with interest and appropriate qualifications should be free to contribute in any manner they see fit. However, that does not mean they should have the right to overwrite contributions made by others."

Of course it means that people have the right to overwrite contributions by others. The team acts as a whole. Individuality in a team is destabilizing. On the other hand, it equally doesn't empower individuals to act individually. Imposing your opinion the team against their will is equally as destabilizing.

Producing one document in the end

If the result is supposed to be a report or a paper, then you need a way to collect all the contributions back into one document -- an executive summary, a discussion of the various factors, etc. A reworked wiki is not like that; rather, it is a collection of pages summarizing discussions, pointing out details, etc. It is a good collection of facts and opinions, but what it requires is an editor.

Solutions:

No editing: We assume that reading the various pages results in a better understanding of the subject, and that really the simplification of the discussion into an executive summary is not something that happens on a wiki. Every person must do that for himself, ie. several people will put up their summaries of the discussion. This kind of summarizing doesn't happen very often on a wiki.
Appointed editors: The person that started the discussion (ie. JoiIto and his Emergent Democracy [1] essay) takes it upon himself to summarize the contributions and work them into the original document. This assumes some sort of natural responsability (original author of a paper, founder of a wiki).
Rotating editors: Pass the draft around and let everybody amend the document. The point is to encourage people to just make sure their contribution from the various pages "makes it into the document" and that no conflicting statements arise. This may require some conflict resolution after the first round.

One Document Result Discussion

Is one document necessary? I think so, eg. the Emergent Democracy essay by JoiIto [1] remains a single document, eventhough lots of other opinions accumulated on his wiki.

Are rotating editors going to work? I don't know. This is very-non wiki.