History: ElephantRefinements

Source of version: 3 (current)

See ((Elephant)). # 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. # 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. # 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. # 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)) 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. * Just so. --((John Cowan)) 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 Kominek|jay))