| > It's a good point, that different interpretations of the same sentence can lead to pointless debate. I'd take it even further -- different interpretations of the same sentence always lead to pointless debate except to the extent that such debate is expressly aimed at maximizing mutual understanding of the semantic interpretations (rather than the derivative views) of all parties involved. The focus should be on dissolving the question[1], then opinion comes into the picture whenever dissolution fails. > Unfortunately, I guess the main way to improve semantic clarity around an argument would be with more information up front, which would simultaneously raise the barrier to entry. True. Right now the size of the discussion is inversely proportional to its complexity. I think we all overestimated how much that would change due to the architecture of the internet. > Perhaps the answer is to allow 'splitting' an debate when it becomes clear that more than one issue is really being discussed. That would mean you could retain the simplicity and low barrier to entry, while avoiding situations where discussions get off topic. It makes me really optimistic that your mind went directly to that. "Semantic threading" as a replacement to "people threading" is the core of what I'd like see in a discussion platform that actually hopes to achieve the goal of "meaningful, balanced debates". Taking that to the extreme, I've long wanted a platform that takes the form of a single discussion, where structured branching and merging from various parts in the discussion makes a lot of the actual writing redundant. Though I'm not sure what sort of effects on motivation that would have -- people like to feel like they're contributing in a more substantive manner than "me too", and there's often an unwillingness to quote oneself which could dramatically slow down conversation when the community is still small. If I ever get around to specifying a protocol or building a service like that myself, I suspect that it would make the most sense to specify the protocol as an extension of git or build the service on top of github. [1] http://lesswrong.com/lw/of/dissolving_the_question/ |