Elephant

From Lojban
Jump to: navigation, search

Elephant was a concept of John Cowan based on the IBIS approach to discussing open-ended issues. So many points had been discussed back and forth over and over again throughout the decades of the Lojban project, that many of the participants wished a document of record would emerge instead of starting over every time. It was a debateware, named after the old phrase, "an elephant never forgets."

Elephant is a combined Web server and mailing list (hopefully the jboske mailing list); people post to the Web server, which forwards the postings to the mailing list. To fully participate, one must sign up for both.

Initial postings to Elephant consist of Issues: an issue is typically a question.

Responses to Issues must (to a first approximation) consist of Positions on the issues. Responses to Positions are Arguments, either pro or con.

Everything starts when someone posts an Issue at the Web site. The Issue is sent to the mailing list, with an URL at the end. Click on this URL, and you are at the Web site posting a Position. URLs at the end of a Position posting are for posting a pro Argument or a con Argument. Of course, you can go to the web site first, navigate to the Issue or Position you wish to respond to, and post directly from the site.

The idea here is to prevent the looping behavior of typical mailing lists, where people just repeat their arguments ad nauseam. The Issue-Position-Argument structure prevents this looping, because one can see each person's Position spread out in space, not just serialized in time.

(The advantage over wiki-based discussion, OTOH, is that it's more fascist (i.e. structured & organised), so it's easier for a final Document Of Record to emerge, without requiring that consensus be achieved. -- nitcion)

History

Elephant implementation effort was last restarted in 2003-02-08. Then the project was abandoned largely because the language became more or less complete.

Last active participants:

  • Matt Arnold aka Eppcott, central organizer or 'Ankus'. Contact him at matt dot mattarn at gmail dot com
  • Matthew Dunlap, one of the programmers
  • Bancus, Models in Ruby on Rails
  • la cizra, Controllers in Ruby on Rails
  • timonator, Views in Ruby on Rails
  • John Cowan, designer and old fart

Past participants:

Design

Here is the Elephant status as of the date at the bottom of the page:

  • Infrastructure:
    • Message-base object: previous version abandoned, new design, implemented!
    • Message object: previous version abandoned, new design, coded
    • Wiki-compatibility interpreter: coded and tested
    • Entity interpreter: partially designed
  • Document types:
    • Document properties table: written
    • Document templates: written
    • Email templates: written
    • Form-filling templates: written
  • CGI programs:
    • Elephant viewer: designed
    • Elephant poster: designed
    • Elephant user editor: partially designed
  • ElephantClerk tools: barely thought about

Refinements

  1. Notes are messages that can be attached to any Elephant message to add information. Unlike Wiki entries, you can't post-edit an Elephant message: it would be unreasonable to allow a Position to be changed after people have posted Arguments against it. Notes can clarify, or serve as instructions to the ElephantClerk.
  2. Specializations: you can attach a sub-Issue to an Issue, a sub-Position to a Position, or a sub-Argument to an Argument. This allows complexity to be broken down. An example of sub-Positions would be alternatives within a greater Position.
  3. A new Issue can arise out of any other type of message. These are of two types: Generalized Issues and Challenge Issues. A Generalized Issue is a broader take on an existing problem that may be too narrow. A Challenge Issue challenges the underlying assumptions of the existing problem.
  4. When an Issue seems settled, the ElephantClerk can change one of the Positions on the Issue to a Decision. This closes the Issue, but retains a permanent corporate memory of why the Issue was decided as it was. Of course, some Issues may never be decided at all.

The message types are Aa, Ac, Af, Ap, Ic, Ig, Im, Is, No, Po, and Ps. The first letter indicates the main type and the second letter is the subtype. The main types of documents are Issues, Positions, Arguments, and Notes. The form of argumentation in Elephant is that someone posts an Issue, which is typically an open-ended question. The children of an Issue are Positions on the issue. The children of a Position are Arguments pro and con for that Position. Notes are for material outside the system, and they can be hooked in anywhere to provide background information or whatever. Im is a top-level issue, so when you add a completely new branch to the tree, it's an Im.

The other two types of I? messages are for issues that arise out of the discussion of other issues.

If the new issue is a *generalization* of something that arose during the discussion, you post an Ig to state it.

But if the new issue is a *challenge to the assumptions* of the discussion, you post an Ic to state it.

Each of these can be attached to any other type of message. An Is is placed under another I to indicate a subissue or specialization of the issue.

So there are two trees in the system:

the all-messages tree, which contains every message (every message has a single parent)

The second tree is the issues tree, since each issue except an Im has a nearest ancestor issue.

(The root of the tree would be a general description of the field from which the issues arise; this is not shown above.)

A root could be strictly needed, or Ims could just be the tops of their own trees.

A main Position, one directly under an Issue, is a Po.

Perhaps a Topic to group main issues or something as a root.

a Ps is a sub-position, which can appear under a Po or a Ps (sub-sub-positions, etc.) when it needs to be specialized.

(A Topic could have Topics under it, too.)

Next, Arguments.

Ap and Ac are the children of Positions, and they are pro and con arguments respectively.

Af and Aa (for and against) are sub-arguments of pro and con arguments respectively.

An argument against isn't an opposition, it's a specialization. In other words, it does not *oppose* the argument above it, it supports it.

The thing we want to avoid is long thin trees that go "Is!" "Is not!" "Is too!"

Instead we get bushy trees under a position that shows the arguments for and against in a reasonable fashion.

"If you can argue against something while supporting it, why "against" and "for"?

You can argue *against* a position by *supporting* another argument.

So it's Po -> Ac -> Aa -> Aa -> Aa etc.

It's why we need all four.

The relationship between Ac and its Aa children is that the children are sub-arguments of the parent. But all are arguments against the original position.

Ditto(Ap, Af, for).

A concurrant against.

This does not mean we would also have arguments for arguments against arguments against arguments for an argument.

Beneath a position we have pro arguments and their sub-arguments, and con-arguments and their sub-arguments.

ie, if you want to disagree with an argument, you post an opposing argument, rather than arguing with the arguer.

But internally the sub-argument of a pro argument is different from the sub-argument of a con argument.

(It would be nice if there were hyperlink cross-referencing like "this sub-argument kills pro-argument #42".)

Can Aa/Af be children of other Aa/Af?

00:20 <@bancus> An Aa could only attach to an Aa?

00:20 < jcowan> Right.

Here's "what can attach to what"

Anything can get an Ig or Ic or No child.

Im can get Is or Po.

Same for Is, Ig, and Ic.

Po can get Ps or Ap or Ac.

Ditto for Ps.

An Ap can have an Af.

Ditto for Af.

An Ac can have an Aa

Ditto for Aa

A No can't have anything special, only Ig, Ic, or No.

By convention, the background color of the page shows whether it's an I (yellow), P (blue), Ap/Af (green),

Ac/Aa (red), or No (white)

We want to make clear than an Af is still an argument pro, and an Aa is still an argument against.

There could be simple vote-tallying.

The "+1" convention will probably work okay for supporting-without-arguing, at least to start with.

It can be hard to tabulate though.

Most of these systems break down because people are unhappy with the rigidity of them, so I want to keep the rules as

un-rigid as possible.

Rather than simply being able to look at the title of the message and see "for: x against: y"

Well, you could count the number of people who have contributed either Ap/Af or Ac/Aa messages.

If someone later decides they no longer support a position they once did, you could add voting as a bag on the side of P messages, then; you can vote for a P, which revokes your votes for any other P.

The biggest problem in the beginning of using such systems is people write too much in one message.

On mailing lists, it's not uncommon for people to write a message that proposes a new issue (Im), takes a position on it (Po), and argues for that position (Ap).

It takes some mental work to break it up into three separate postings.

The forms for entering the data should remind the user of the separation.

The ElephantClerk therefore has to have Godlike powers to change content and create new messages under other people's identities.

And therefore has to be a very trusted person.

John Cowan thinks it's important to keep this as simple as possible to get to 1.0 as fast as possible so people can try it out and find what refinements are actually needed.

The interface should be English at least at first, and Lojban if desired.

Elephant should be released to the larger world under a permissive license, with clean source.

There are lots of groups that could really use it. --- I hope it is recognized that in the early phases of a discussion one continually changes one's mind, so it is quite likely that a single person might issue a series of Positions on the same topic, each of which supersedes the previous one. (And Rosta)

Obviously; but it'd be polite to keep the old Position there: you may have changed your mind, but others may now think you were right in the first place. Of course, you should feel free to flood your former proposal with CONs: "I must have been insane to have ever considered proposing this, because..." -- nitcion.

One should be able to indicate that one position obsoletes another position.

  • I think the righteous term would be something like "supersedes". I will figure out how to incorporate this feature; my implementation strategy allows lots of flexibility about what kinds of documents exist, and what kinds of relationships exist between them.

(So if you change your mind, you can see explicitly which position obsoletes which other position.) T'would be able to form a nice little chain. also, it might be amusing, if not useful, for people to be able to register their confidence/agreement with each position, so that one can sort of get a quick glance and see what position is "winning". and while i'm dreaming: each issue can have a timeline, on which will be indicate the time each post on the issue was made, and the running total confidence in each position. --Jay