TurnBasedVsInterruptedThreadMode

A ThreadMode argument frequently starts like so:

Then someone wants to reply. They have two choices at this point:

An example of an InterruptedThreadMode response follows:

I’m calling it “InterruptedThreadMode,” because the thread is interrupted.

The other option was a new response, which we’ll call “TurnBasedThreadMode,” because we take a new turn to reply:

InterruptedThreadMode

Recursive include of InterruptedThreadMode!

Responding by interruption is easy: You just read through the inspiring message, and insert comments wherever inspiration strikes. The reader of your responses can see exactly what you are responding to.

However, InterruptedThreadMode can become very troublesome. You can end up playing whack-a-mole with arguments. After a couple of rounds of response, the threads of discussion can wildly diverge. Prioritization of threads generally does not happen, beyond “let’s discuss this,” or “let’s not.” (See DivergingArguments for more on these problems.)

Readers (as opposed to participants) of InterruptedThreadMode suffer the most. Readers have great difficulty following arguments, because arguments are fragmented over the page, and because the sense of temporal flow is hard to gather.

Consider 5 exchanges:

  A - 1st exchange   B - 2nd exchange   C - 3rd  D - 4th  E - 5th

  AAAAA.
    BBBBB?
       CCCCC.
         DD.
            E.
    BBBBB.
       CC.
         D. 
    BBBBBBBBB.
       CC.
  AAAAAAAAAA.
  AAAAAAA.
    BBBB.
       CCCCCCCCCCCC.
          DDD.
              EE.
          DD.
              EE.
          DDDDD.
              E?
       CCCCCCC.
          DDDDDD.
              EE.
          DDDDD.
              EE.
    BBBBBBBB.
  AAAAAA.
  AAAA.

See how the 1st message- message “A”- is divided all over the page? The responses are similarly divided.

And notice how it’s easy to lose track of the causality of the conversation? As you read from the top of the page to the bottom, time jumps forwards and backwards. It’s easy to get confused.

It’s also common to encounter “serial responses,” that say the same thing. Serial responses may take the form of “Again, the same argument,” or something like:

  So, Apples are Red.
    But not all apples are red. Some are green.
  Some balls are red.
    And there are also green balls, too.
  There are red lights on top of control towers.
    But not always- some are white.
  Thus, everything is red.
    So, how do you account for the things that were green, and the white lights?

We get serial responses because we structure our conversation by the order of the flow of the text, not by the key points of the text.

So let’s recall the advantages and problems of InterruptedThreadMode.

Advantages:

  • easy to write- respond where inspiration strikes while reading
  • responses close to inspiring comments

Disadvantages:

  • DivergingThreads?, DivergingArguments
    • (argument whack-a-mole)
    • (wild divergence)
    • (lack of thread prioritization)
  • readers suffer
    • arguments are scattered
    • chronology is confused

Note that in some mediums, InterruptedThreadMode isn’t so bad.

In E-mail or UseNet, for example, readers don’t suffer. The chronology isn’t scattered, because you can easily go back and watch the argument develop. Furthermore, there is “quoting” (putting a “>” in front of older message contents), making it easier to determine what is fresh, and what is not, provided there is some consistency in whether participants use TopPosting with their quotes, or not. These two things, an intact chronology (see also RememberAndAppreciate) and coherent quoting, together make it much easier to collect arguments, and keep the chronology straight.

  e-mail 1:

  AAAAA.
  AAA.
  AAAAAAA.

  e-mail 2:

  > AAAAA.
  BB.
  > AAA.
  BBBBBBB.
  > AAAAAAA.
  BB.

  e-mail 3:

  >> AAAAA.
  > BB.
  CC.
  >> AAA.
  > BBBBBBB.
  CCC.
  > BB.
  C.

If you’re reading e-mail 3, and want to see what “B” was looking at and responding to, you can go back to e-mails 2 and 1. You can recognize the entire argument, by starting with #1, then reading #2, than going on to #3.

However, DivergingThreads? remains a problem, even in E-mail, or on Usenet, if people are interacting by InterruptedThreadMode.

On wiki, it’s also hard to remember just where you need to respond. It can be easy to get lost in indentations. There is no quoting. So, the wiki page doesn’t exactly shout out “respond here!” You have to scan for the deepest indentation, to keep track of where you are going to respond.

Interrupted thread mode is also known as Wiki:InterleavedParallelThreadMode.

Responding by interruption is easy: You just read through the inspiring message, and insert comments wherever inspiration strikes. The reader of your responses can see exactly what you are responding to.

However, InterruptedThreadMode can become very troublesome. You can end up playing whack-a-mole with arguments. After a couple of rounds of response, the threads of discussion can wildly diverge. Prioritization of threads generally does not happen, beyond “let’s discuss this,” or “let’s not.” (See DivergingArguments for more on these problems.)

Readers (as opposed to participants) of InterruptedThreadMode suffer the most. Readers have great difficulty following arguments, because arguments are fragmented over the page, and because the sense of temporal flow is hard to gather.

Consider 5 exchanges:

  A - 1st exchange   B - 2nd exchange   C - 3rd  D - 4th  E - 5th

  AAAAA.
    BBBBB?
       CCCCC.
         DD.
            E.
    BBBBB.
       CC.
         D. 
    BBBBBBBBB.
       CC.
  AAAAAAAAAA.
  AAAAAAA.
    BBBB.
       CCCCCCCCCCCC.
          DDD.
              EE.
          DD.
              EE.
          DDDDD.
              E?
       CCCCCCC.
          DDDDDD.
              EE.
          DDDDD.
              EE.
    BBBBBBBB.
  AAAAAA.
  AAAA.

See how the 1st message- message “A”- is divided all over the page? The responses are similarly divided.

And notice how it’s easy to lose track of the causality of the conversation? As you read from the top of the page to the bottom, time jumps forwards and backwards. It’s easy to get confused.

It’s also common to encounter “serial responses,” that say the same thing. Serial responses may take the form of “Again, the same argument,” or something like:

  So, Apples are Red.
    But not all apples are red. Some are green.
  Some balls are red.
    And there are also green balls, too.
  There are red lights on top of control towers.
    But not always- some are white.
  Thus, everything is red.
    So, how do you account for the things that were green, and the white lights?

We get serial responses because we structure our conversation by the order of the flow of the text, not by the key points of the text.

So let’s recall the advantages and problems of InterruptedThreadMode.

Advantages:

Disadvantages:

Note that in some mediums, InterruptedThreadMode isn’t so bad.

In E-mail or UseNet, for example, readers don’t suffer. The chronology isn’t scattered, because you can easily go back and watch the argument develop. Furthermore, there is “quoting” (putting a “>” in front of older message contents), making it easier to determine what is fresh, and what is not, provided there is some consistency in whether participants use TopPosting with their quotes, or not. These two things, an intact chronology (see also RememberAndAppreciate) and coherent quoting, together make it much easier to collect arguments, and keep the chronology straight.

  e-mail 1:

  AAAAA.
  AAA.
  AAAAAAA.

  e-mail 2:

  > AAAAA.
  BB.
  > AAA.
  BBBBBBB.
  > AAAAAAA.
  BB.

  e-mail 3:

  >> AAAAA.
  > BB.
  CC.
  >> AAA.
  > BBBBBBB.
  CCC.
  > BB.
  C.

If you’re reading e-mail 3, and want to see what “B” was looking at and responding to, you can go back to e-mails 2 and 1. You can recognize the entire argument, by starting with #1, then reading #2, than going on to #3.

However, DivergingThreads? remains a problem, even in E-mail, or on Usenet, if people are interacting by InterruptedThreadMode.

On wiki, it’s also hard to remember just where you need to respond. It can be easy to get lost in indentations. There is no quoting. So, the wiki page doesn’t exactly shout out “respond here!” You have to scan for the deepest indentation, to keep track of where you are going to respond.

Interrupted thread mode is also known as Wiki:InterleavedParallelThreadMode.

TurnBasedThreadMode

Recursive include of TurnBasedThreadMode!

Now, let’s consider TurnBasedThreadMode.

TurnBasedThreadMode is where you take turns exchanging messages, but do not write within one another’s text.

For example:

  (message #1)

  So, Apples are Red.
  Some balls are red.
  There are red lights on top of control towers.
  Thus, everything is red.

  (message #2)

  Nah nah nah. Not all apples are red, some are green.
  Some balls are green. And I've seen white lights on
  top of control towers.
  If everything is red, how do you account for those things?

  (message #3)

  I demand proof. You must //show// me green apples,
  green balls, and white lights. I've heard people talk
  of these things, but none has proved it. They were all
  obviously //paid// to assert those things. It's all
  propaganda.

TurnBasedThreadMode has different advantages and disadvantages.

Advantages:

  • DivergingThreads? solved:
    • the message has a focus (prioritization, no “whack-a-mole”, no wild divergence)
  • easy for readers:
    • clear chronology
    • message has integrity- it’s structure is clear, the message is not fragmented

Disadvantages:

  • harder to write- have to hold structure of response in your mind while writing
  • if you reach a dead end in an argument, you need to back-track to plan a strategy of response- you can’t just look at the tree structure

Implications for Wiki ThreadMode Conversation

On Wiki, we tend to favor TurnBasedThreadMode.

  • Pages are relatively permanent, (WikiIsDocumentBased,) thus we must pay more attention to readers, even in our ThreadMode conversation.
  • Until we have WikiFeatures:BuiltinThreading?, chronology is too confusing. Wiki doesn’t quote previous messages. We rely on indentation. It’s hard to know where to respond, and what changed.

Contributors

LionKimbro

Now, let’s consider TurnBasedThreadMode.

TurnBasedThreadMode is where you take turns exchanging messages, but do not write within one another’s text.

For example:

  (message #1)

  So, Apples are Red.
  Some balls are red.
  There are red lights on top of control towers.
  Thus, everything is red.

  (message #2)

  Nah nah nah. Not all apples are red, some are green.
  Some balls are green. And I've seen white lights on
  top of control towers.
  If everything is red, how do you account for those things?

  (message #3)

  I demand proof. You must //show// me green apples,
  green balls, and white lights. I've heard people talk
  of these things, but none has proved it. They were all
  obviously //paid// to assert those things. It's all
  propaganda.

TurnBasedThreadMode has different advantages and disadvantages.

Advantages:

Disadvantages:

Implications for Wiki ThreadMode Conversation

On Wiki, we tend to favor TurnBasedThreadMode.

Contributors

LionKimbro


CategoryOnlineDiscussion CategoryThisWiki

Discussion

One takes turns in a discussion. On the other hand, when writing a document one may indeed take turns temporally, but the goal is for the document not to reveal that turn-based nature in its structure. A page that has been written in DocumentMode is naturally edited in a fashion that might grow to look like InterruptedThreadMode. This is a problem with advocating DocumentMode as the default mode, but dismissing NeutralPointOfView as a SuperordinateGoal. What starts as a document gets turned, by dribs and drabs, chaotically, into a discussion studded with disjointed threads. If one can write from the outset with an aim of NPOV, and welcomes expansive correction and addition to that document without getting into a discussion about the points, DocumentMode can be preserved. Otherwise it might be better to start off with no intention at all to work in DocumentMode.

When considering other discussion-oriented pieces of SocialSoftware, one can make the distinction between linear conferencing systems and threaded conferencing systems. This conception of turn-based vs interrupt-based thread mode maps very well to that (though in the former case the term “thread” is used as a distinguishing mark, applied to one but not the other, whereas the latter case uses thread for both, and the distinction applies at the level of thread-vs-document.) PicoSpan (the software that the WELL started with) is linear/turn-based. Slashcode is threaded/interrupt-based. – anon

:There is an analogy, but I’m not sure if it maps well. One can have TurnBasedThreadMode which is “threaded”, or TurnBasedThreadMode which is “unthreaded” (one might call the latter “SingleThreadMode?, because there is typically one single thread per page, without subthreads). **There is an analogy here over exactly the same subject: WikiFolks(interrupt-based) & WikiDe:BaumListing? (turn based). [de]man braucht beide. [en]one needs both. --sigi :By indenting this reply, I am using “threaded” TurnBasedThreadMode. By indenting, I indicate that this post replies to the previous comment. This provides more information than if I had not indented it, in which case I might just be replying to the DocumentMode text, or to the “entire discussion”.

:However, this post is NOT using InterruptedThreadMode. I didn’t interrupt the parent post, I started my own separate post after it. The difference is that TurnBasedThreadMode forces you to “target” your parent post at the level of granularity of entire posts; you cannot “reply to” part of a post. By contrast, InterruptedThreadMode allows one to reply to part of a post.

:– BayleShanks

BayleShanks: For contrast, this post uses our DenotingAuthor system, which does not allow indentation. So, this encourages only “unthreaded” TurnBasedThreadMode. There is no way for me to “reply to” a single post; based on indentation, it looks like I’m just chiming into the discussion, maybe to reply to the parent post, maybe just to say something new.

LionKimbro:

re: DocumentMode

It seems when we collaborate over DocumentMode, we either:

  • Edit the document directly, if we think everyone would agree.
  • We add annotations, if we disagree. (“Interruptions.”)
  • We start threads at the bottom of the page, if we disagree. (“Turns.”)

Perhaps we should use a little symbol, meaning “see discussion section below,” to make annotations that point to threads at the bottom of the page.

But this page was intended just to talk about dedicated ThreadMode conversation, not DocumentMode conversation. (Perhaps we should write: “DisagreementsInDocumentMode?,” on how we like to handle those situations.)

We have some problems, because “Threads” means different things in different contexts. Perhaps we need to rectify our names.

AlexSchroeder: On this wiki, the conventions we use for DenotingAuthor automatically favors turn-based thread-mode. Interesting. Never thought of it.

LionKimbro: Oh wow; I never noticed either. Neat!

MattisManzel: The conventions we use here automatically favor TurnBasedThreadMode. How comes? The speaker and listener friendly mode, letting someone finish his thought, before arguing, the polite-, the cultural-way. Why is it favoured by some little pictures? Is the illusion of beeing on a common camp fire, of seeing each other, of feeling warmth, feeling security really this strong?

BayleShanks: No, I think it is due to the graphical layout.

We are really talking about two different things here (see my above posts). The interface discourages InterruptedThreadMode; if you interrupted someone, either you would not use new::, and your post would be easily missed, or you would use new::, and you would not be able to indent your interruption, and besides the huge picture would make even a small comment into a big interruption, so you’d feel more bad about interrupting.

However, the interface also discourages subthreads in TurnBasedThreadMode:

  • If you use new::, your picture goes at the left-hand side of the screen; you cannot indent your post.
  • You are discouraged from replying without using new::, because the background behind your text doesn’t change color, and that combined with the color change at the next new:: makes it look like your post is just part of the parent post.

See the two example posts I made above just now. In one case, I didn’t use the new:: primitive, and it is easy to miss my comment. In the other case, I used the new:: primitive, but I couldn’t indent (I couldn’t reply-to a specific post).

I would prefer if the software were modified so that “threaded” TurnBasedThreadMode were allowed. Specifically, allow indentation to work with new::.

AlexSchroeder: Actually I think I would prefer it if people reorganized the page, using headings to mark the start of a new thread, or move to a new page entirely. I feel pages that are full of interruptions are difficult to read both for newcomers and for old hats like me. I think the current solution is nice (eye candy is important) if used in exactly the way intended – and thus good style is encouraged. I guess we’d have to check why we’d like to encourage InterruptedThreadMode. What do you like about it?

piranha: my background is usenet, lots and lots of it, and i love threading there (which is interrupt-based). i started out quickly disliking a lot of discussions on wikis because they were a royal pain to plow through, and thought at first it was the lack of good threading, but i’ve since clarified my ideas on it. it’s not that i actually dislike TurnBasedThreadMode – i like it just fine here, and i find myself getting annoyed on pages where people don’t start their contributions with the “new::” thingie. What i don’t like is the mixture of interrupted threading and turn-based threading without a clear indication of what’s been changed, without time-stamps, without author denotation. the wikis i’ve seen all do not handle tree-based threads well enough by far, and i am therefore coming around to gasp wanting to actually discourage them, unless something in the underlying infrastructure gets written to make changes more easily visible. the layout is really clean here, and i find it much easier to follow what’s going on, even though i have to scroll more as well, and might have to write slightly wordier comments to include more context.

i think each written page should have a “discussion” section underneath, and once discussion has died down somewhat, somebody ought to edit the main body and incorporate what has been learned, and the discussion can get moved off onto a historical page, or something, but the section header left for future discussion of the resultant document. i realize refactoring is much harder for a lot of people than originally writing a page, but it’s one of the very strongest features of wikis IMO, and i think it should get done more frequently.

BayleShanks: Well, by my lights, I don’t want to encourage what I called InterruptedThreadMode. But I do want to encourage what I call ““threaded” TurnBasedThreadMode”. (I’d be fine using different terminology if you’d prefer, but I do need to disambiguate “threaded” TurnBasedThreadMode from InterruptedThreadMode; you are calling both of those InterruptedThreadMode).

The reason is that it makes it easier for the reader to skip over parts of a discussion that they don’t care about (i.e. replies to a given post which they are uninterested in). This saves the reader time.

I think disallowing indentation is moving backwards, not forwards. What I want eventually is WikiFeatures:BuiltinThreading? . I want the features that a WikiEngine has to be a superset of the features that DiscussionBoard? software has.

AlexSchroeder: Maybe we need an easy way to link to replies so that at the end of a comment, you can jump to answers, maybe skipping unrelated comments in between… Maybe another macro suchs as [<nowiki>reference</nowiki>]. When you then use [<nowiki>new::</nowiki>] elsewhere on the page, all the instances of [<nowiki>reference</nowiki>] will be replaced by links to the new comment.

HeatherJames:

Vis a vis Alex’s remarks above, on how we can actually design for the preferred mode of interaction… I’m introducing the concept of WikiAffordances

TedErnst: Bayle’s post above relys on : to indent which doesn’t seem to work on this wiki. That makes for a strange situation where the comments rely on being indented and they are not. Can this be fixed in code or this comment rewritten? Please. :-)


FridemarPache: Due to the fast changing technological context, there are often surprising solutions, not yet taken into account:

A combination of annotations, graphics and wiki is in the air. – FridemarPache 2006-12-14 21:10 UTC

LionKimbro:

Of course. That is already accounted for in the page.

This page explains why, in email, or usenet, interrupted communication is (by and large) preferred.

And why, in wiki, we think it’s better to use turn-based communications.

Every medium will have it’s optimal methods for whatever your purposes or values are.

Wiki, by and large, use turn-based communications. For the reasons explicitly explained in this document.

FridemarPache: Hi Lion, the surprising part is, that we can reconcile turn-based communication, with other forms, that are not disturbing the textflow of the base wiki, e.g. making additional annotations like this one. – FridemarPache 2006-12-14 21:40 UTC

LionKimbro: I don’t understand what you’re saying.

Sure, you can do things in parallel. You can annotate whatever you want. It doesn’t mean that it’s a good idea.

This page is full of explanations and justifications. I’m not hearing any argument from your end, providing an explanation or a “why.”

FridemarPache: My point is, that it becomes more and more an illusion, thinking that we solve the problem of optimal communication style, by making rules. If we rule out other thinking and communication styles by defining a fixed grammar, this may be shocking for other communities. – FridemarPache 2006-12-14 21:57 UTC

LionKimbro: “More and more an illusion,” over time. Of course that is true.

But it is not yet sufficiently “illusion” that TurnBasedThreadMode is in most cases superior to InterruptedBasedThreadMode?.

If you think that it is, then you need to provide reason about why now, a different system will work better.

Do you have reasons, now, that, with the tools available, it would be better for everyone on CommunityWiki to decide to use DiiGo instead of commenting in pages?

We haven’t ruled out anything. On CommunityWikiGovernment, we’re talking about, at most, mere endorsement.

What we are, is SelectivelyOpenMinded. We will listen to reasons on this issue. What we don’t do, and what it seems like you’re doing, is just saying: “Technology! Everything is different! Capitulate to the new way! I don’t need to explain myself!”

It’s been 3 years. The Singularity is fast, I’ll grant that. It may even be “that fast,” which is why I have, myself, re-examined about the possibilities of us upgrading to include a WebAnnotation system.

I thought about it, and figured, “Well, there are some things we could do.” There are opportunities. Will we just up and shift to DiiGo? No.

GroupServer would be closer in line, I think. But I’d need convincing (with reasons, discussion, hearing) before suffering a CommunityWiki / DiiGo split.

Recognize that my principle dictum here is: Provide Reasons. Discuss. Answer our questions. You’re not doing that. You’re just saying: “Singularity.” Yes, singularity. Now: the reasons. Answer challenges and questions.

Note that I may elect not to respond, (now,) because I’m busy. There is an agenda here. CommunityWikiGovernment is highest priority.

LionKimbro: Best: Prove the form somewhere.

Evaluate it’s strengths and weaknesses: surely it must have both.

Then, evangelize it from there. When people say, “No, for these reasons,” recognize that they may be good reasons, and that you simply need to evangelize to a different audience, with different needs.

There are places where WebAnnotation is extremely useful. I just don’t think commenting on CommunityWiki is the place.

Please respond on WebAnnotation, if it’s not about TurnBasedVsInterruptedThreadMode.

FridemarPache: Lion, I feel fine with TurnBasedThreadMode, the mode, that has stabilized here and that is gently supported by the new:: syntax.

You are right, there is currently so much community work to be done, that it is surprising that we all are still alive and in good humor.

Yes, the topic WebAnnotation is the right place for continuing the discussion, but for now, I think it is optimal to help each other to get their primary goals realized. :-)FridemarPache 2006-12-14 23:43 UTC

LionKimbro:

Thank you. 😊


See

LionKimbro:

A problem I see in my brief skim of ReplyToTheWholePost (I may be in error…) is that it takes a somewhat essentialist position on how people should talk.

This page takes a different position; It presents analysis and arguments for TurnBasedThreadMode as a result of how wiki works. It also presents arguments for why InterruptedThreadMode works so well in e-mail, and in usenet, where the environment is different.

The optimal way of communication is a function of the tools used to communicate, not some platonic ideal of “Turn-Based” or “Interrupted” conversation. 1

So while I prefer the title of ReplyToTheWholePost (“TurnBasedVsInterruptedThreadMode” is just aweful,) I would not link to that page specifically to talk about what we mean.

Renaming this page to “ReplyToTheWholePost” would be a good thing, I think, though; If you want to do the work, just don’t forget to also change the rest of the links of the wiki to point to this page. It’d be good to see if the LinkLanguage “sounds right” when the replacements are done, as well…

BayleShanks: By the way, I have recently been using TurnBasedThreadMode for “substantive” comments, but InterruptedThreadMode for very short replies like “thanks”, stupid jokes, etc. I guess my current criterion is to use InterruptedThreadMode for comments which:

  • are very short
  • aren’t very important, and can be removed in reworking (i.e. a joke or a “thanks”)
  • are direct replies to an earlier comment

In these cases, I figure that the cost of effort for the reader in terms of the small loss of continuity are outweighed by the costs of looking back to the earlier comment if the comment was placed at the bottom (for example, if you see a post that just reads, “Alex: 😊”, and you have to scroll up a screen and a half to find Alex’s comment, the “parent”. In such a case, you’d probably prefer to find “😊 – Bayle” inserted directly after Alex’s comment).

HansWobbe: I believe that breaking this page up into smaller (MicroContent) chunks will make it easier to edit and improve this page. Hence, I’m not sure why there would be an “regrets”.

MattisManzel:

Hmm. A while ago that we have been writing this page. Still. The quest here - the “search for a Magellhan projection of human communication” - is similar to the one on the chain-video-wiki I started a while ago inspired by the German kettenvideo.de project. Their system of allowing to fork a thread whenever whereever and continue at whichever of its current ends (or before) seems interesting to me. A nice technical solution enabling it on wiki would likely help both: written communication and chain-videos.

TimurIsmagilov:

This discussion above is a perfect example of why TurnBasedThreadMode is bad. It is stated in the document above that it is easy for a reader. Here I am, a reader, more than 10 years later. It is hard for me to read. To understand a message, I have to understand every message before it, understand the connections and quotations, etc. I don’t really want to read the long discussion formatted in such a unfriendly way.

On contrary, InterruptedThreadMode are easily read and understood. Also, it is easy to refactor them. See lambda calculus where I compared lambda calculus to how easy it can be to refactor interrupted threads.

P.S. Whenever I comment on an old page, a lot of old markup is broken. It’s not exciting to fix it. Why and when has it been broken? And what is modern equivalent to :-offseting? Bullet lists are not the best element for tree discussions, perhaps.

Now I’m going to comment the presented advantages and disadvantages of both approaches. I’ll do it right here, in this comment. A reader would have to go back and forth to have all the needed context.

  • Interrupted
    • Advantages:
      • It is indeed easy to write
      • Related responses are indeed close to each other
    • Disadvantages:
      • DivergingThreads?, DivergingArguments are real problems but they are easily solved by moving lines around
      • Thread prioritization is not present but that is not a problem. All threads are important. If they are not, it is time to β-reduce them :-)
      • Readers suffer. In fact, they do not
      • Arguments are scattered. I’d say they are placed where they belong
      • Chronology is indeed confused but why care about chronology at all? We live in WikiNow
  • TurnBasedThreadMode
    • Advantages:
      • The message indeed has a focus
      • Easy for readers. Except it’s not.
      • Clear chronology (which is not really needed)
      • Message indeed has integrity but it’s dependent on all messages before it. So, is it really… integrated? Integer?
    • Disadvantages:
      • So hard to write!
      • You can’t just look at the tree structure, which is bad

LionKimbro:

You know, quite honestly, when anybody peppers something I’m writing or saying with little contrary comments everywhere, I feel profoundly disrespected.

I feel like I’m being heckled, and not allowed to say what I have to say, uninterrupted, and to completion. I’d much rather say what I have to say, and feel like I’ve been read, in my original sense.

Now if you want to build a map of the argument, somewhere in the DocumentMode, for your own tracking, and for the tracking for the future, separate from the threaded discussion, be my guest. I think that’d be a great thing to do.

But interrupting what other people are saying, – I think that’s bad form.

I agree with you about the burden of, “Well, there’s all this content out there, – can’t we condense it?” And I think most everybody who ever contributed on this wiki, myself and Alex included, agrees with this thought. That’s why we spent so much time and effort exploring CategoryReworking.

And we can have that conversation about, “Well, how do we make sure that things get reworked?” and “How do we keep articles improving?”

But I go somewhere very different with that discussion, than this piece on whether turn-based is a good idea or not.

It’s thoroughly clear to me that turn-based is a good idea, because it preserves the integrity of what people are saying, as they are participating in conversation with one another.

Alex Schroeder: I also agree that interspersing an existing message with inline comments, branching of into more discussions, doesn’t work well. Now, if we had a way to annotated a conversation, it might work better. I still hate the “citation needed” annotations on Wikipedia, though. But it’s better than writing it right there into the text. Perhaps if we had [[Marginalia?]]. I think I might like marginalia.

As for reworking a text, I think it is sometimes valid – on a wiki! – to take all the discussion, delete most of it, and write something different instead, provided some principles are adhered to. Sadly, I don’t know these principles. But I suspect they’re something like this:

  • treat all contributions with respect
  • this includes giving statements time – be patient 🧘
  • feel free to remove points that are redundant, outdated, contradicted, etc (but keep in mind to treat them all respectfully)
  • feel free to remove questions and answers if they seem no longer pertinent (most easily done by simply integrating the synthesis of question and answer into the main text)

There are probably some more such guidelines. 😃

TimurIsmagilov:

To Kimbro:

You know, quite honestly, when anybody peppers something I’m writing or saying with little contrary comments everywhere, I feel profoundly disrespected.

I understand that.

It’s thoroughly clear to me that turn-based is a good idea, because it preserves the integrity of what people are saying, as they are participating in conversation with one another.

Well, yes. It’s an advantage. If the words are not manipulated with, the original meaning is present.

Another advantage I recently found is that you can easily understand what new comments have been added to a page by simply looking at them. With tree comments you’d need to look at every single conversation.

To Alex:

There are probably some more such guidelines. 😃

And they were probably discussed a decade of years ago. Let’s collect all the principles and agree on them.

Footnotes:

1. Though, come to think of it, given infinite flexibility in medium, including the laws of the universe, and clear purpose, it might be possible to find a perfect or optimal communication system. Then again, it might simply end up being manufacturing a perfect copy of yourself, and replacing the other person with your perfect copy. Then again, this is the opposite of common-ication, supposing that the other person has something to teach you, too. We aim to get the best out of both people, after all. EvolutionarySpirituality: Perhaps the entire universe itself is such a communications device, and evolution its vehicle of communication.
(CommunityWikiFooter)

Languages: