This dates back to 2014 where Turkey was still struggling with the aftermath of widespread civil unrest. The entire nation found itself highly polarized while debates were fueled with mutual anger and disbelief.
Taiwan use it for their multi-stakeholder decision making to find points of agreement. Their application of it to the Uber vs Taxis situation was quite interesting.
That does sound interesting. Also for the fact that I'd never seen clojure and javascript living in the same codebase, I was expecting python for data handling.
But I digress.
I believe there's a lot to do to find reason in out fundamental unreason as human beings and looks like lots of smart people have ventured into solving this problem.
Arguman's fallacy system is really an anti-feature. It's impossible to separate the claim that a specific argument is a fallacy from a counter-argument. Many people seem to think that you can just take a word describing a kind of a argument, attach "fallacy" to it, and you have refuted it.
Agreed. While logical fallacies are useful to teach people to avoid critical thinking pitfalls they are not useful to sift through the merits of arguments.
But is that a problem with the tool, or the lack of sufficient contribution on the topic from sufficiently interested and invested people like subject matter experts?
For sake of completeness, this field has been processed both by theory and and practical applications before. Formerly, those system were known as Issue-Based Information Systems (IBIS).
The wikipedia article gives some background and references to (mostly abandoned) tools.
Now there's a name I've not heard in a long time. As an early career developer poring over Usenet in the late 80's, I thought IBIS would be The Answer to working out requirements in a large team.
This is magnificent, thank you for the link!
Interestingly, Argdown appears to use a different model: it has statements and arguments, where IBIS has issues, positions, and arguments.
This is not limited to software development. Try being involved in Wikipedia and you'll eventually have the displeasure of experiencing the same lack of structure and rigor in arguments. (I'll say, though, that the author mentions GitHub, which does seem particularly bad in comparison to the average Bugzilla instance, say, 10+ years ago, and it's part of why I avoid GitHub, purely for my own sanity and productivity.) It's these experiences that make you appreciate the role of a judge if you've ever sat in court or read through trial transcripts.
What we're all really aching for is a solution to the ratiocination problem. pron put together a nice overview of some of the history of thought in that area a couple years back[1]. There's also the Toulmin model[2].
This is fascinating and a very cool concept to be able to clearly respond to specific points in a technical discussion. I agree that sometimes these discussions are hard to follow and sometimes get derailed by minor quibbles. I'm plenty responsible for starting to debate about minutiae in a meeting when it really doesn't advance the conversation meaningfully. (That's more of a synchronous issue, this works at improving asynchronous communication, if I understand it correctly).
One thing that isn't immediately clear to me is how to associate specific individuals to a comment. Sometimes knowing who made an argument is very important. I like to believe that people are a little more careful about forming their reasoning when they are debating with the author or maintainer of a project, for example.
Perhaps, not knowing the author of a point is a feature? I'm often engaged in discussions where the authorship hurts more than it helps. Ideas are being referred to as "John's idea", conflating objective ideas with subjective positions. I recall explicitly asking WebGPU group to not consider an idea to be "mine" but rather just discuss it objectively for what it is.
Also, I regularly play the advocatus diaboli to ensure we are thinking through a particular position. Not necessarily because I believe it, but because if we can address the relevant concerns we'll have a more robust system. But having the position opposite of your own, be labeled yours, since you happened to bring it up, can be pretty annoying.
Yeah, I think there are two sides of it. One is as you say, people need to keep an open mind and accept good ideas on their merits.
I try to limit my online discourse because I know I'm prone to knee-jerk reactions. A _very_ long time ago I wondered to myself why this mbostock person knew so much about d3. A little while later it clicked, haha!
Combine `argdown` with something similar to `roam research` and you have the makings of a 21st century platform for knowledge production.
When we have conversations in person, there is a natural Clarify -> Challenge -> Refine loop that hopefully ends in some resolution. One of the major issues with long run, asynchronous, online platforms is that they don't enable newcomers to easily contribute novel thoughts to that cycle. As an outsider viewing discussion around async rust that occurred on here and on reddit, by far the most common reply was "not a new thought- already discussed HERE".
But as OP pointed out, those HERE links were hundreds of posts you'd have to read through and reconstruct the clarify -> challenge loop in your head before figuring out whether your question had been addressed.
Yesterday in my mad dash to slurp down whatever good stuff I can find in the ACM library while the window is still open, I ran across a paper about using hypertext for "Representing the structure of a legal argument" (haven't been able to give it any real attention yet, though, since the candle is still burning down).
I would love to see some more rich voting options than just up and down.
Allowing users to vote using tags like "Great Summary", "I agree", "I disagree but strong argument", "Sources check out", etc could really help users filter. People often upvote/downvote based on agreement rather than the quality of the content.
If you have an in-progress discussion that's still finding its way, that's not going to happen. And the curators may or may not have their own agenda.
Perhaps technical discussions are just messy because the problems are messy and don't have obvious solutions.
In the context of Rust, the bigger problem, IMO, is that things that aren't Mozilla/Firefox driven don't get driven to conclusion/completion. The discussion simply peters out with no resolution and then remains open indefinitely (look at how many issues from Rust 1.0 are still open with no conclusion, discussion or resolution.)
I'm curious, what kinds of things do you see that are being prioritized for Firefox or Mozilla over things the community wants? I can't think of anything, but I am also extremely biased.
> (look at how many issues from Rust 1.0 are still open with no conclusion, discussion or resolution.)
Issues for the project are prioritized based on need and ability to complete them, not age.
> I'm curious, what kinds of things do you see that are being prioritized for Firefox or Mozilla over things the community wants?
It's not about prioritizing over--aka "Mozilla wants X and community wants Y and those are in conflict." I don't think I've seen that even though it probably has happened at some point.
It's more about "Mozilla wants X and allocates resources so that goes to completion while community wants Y and languishes because maybe one or two people are actually qualified to work on it and they have full-time jobs."
> Issues for the project are prioritized based on need and ability to complete them, not age.
Quite a few of the Rust 2019 announced objectives saw very little progress, and yet people wanted to move onto new objectives in 2020. Erm. Why did those 2019 objectives see so little progress when they were important? Why are they now unimportant in 2020? Apparently Mozilla didn't seem to think those objectives were too important as they didn't seem to allocate resources to attack most of them.
However, this isn't a new problem. For example, you transferred a bunch of issues for the 1.0 timeline. Some of them were transferred into things like "This should be a library". Okay.
Someone later wrote that library. It has become a de facto crate solution and people use it. Yet that RFC/Library issue still stands open. The library author may not even be aware that such an RFC/Library issue exists. Whose job is it to close that issue and anoint that library/crate as "The One(tm)"?
Some of these issues have been untouched for 4+ years. No one is fooled that these are "in progress". They're dead and closed even if Github still marks them green. They might as well be closed out anyway as the language is so different from that milestone that many of them aren't even relevant anymore.
None of this is new nor specific to Rust. However, Rust is getting hit with it a bit more strongly because it's in a growing-phase where there is far too much work to do and far too few hands to do it.
(Funny you should pipe up. I'm sorry, I am certain I filed a Github issue on a Rust library issue asking for one such library to get a pronouncement from you, but the issue seems to have simply disappeared down the memory hole. It is a little unnerving that Github can just wipe out something I filed without reference or history.)
Thanks, this is helpful. I still disagree with a lot of the characterization here, but it’s much more reasonable than what I thought you were saying, and regardless of my opinion on your opinion, I’ll try to think about why things may appear that way.
Thanks for giving me the slack. This probably sounds harsher than I intend. Putting negative information into text almost always comes off worse than the speaker intended.
"Timeliness in process" is extremely difficult. Python does better than most, but even they have issues with RFCs that never achieve consensus. Also, one of the Python koans is "The standard library is where modules go to die" so Rust pushing things out of stdlib has some advantages (as well as disadvantages).
Part of this is also probably personal frustration on my part. I'm apparently using Rust in a lot of ways that are "off the happy path" and I bump into "Here Be Dragons" sections of the Rust landscape quite a lot.
I haven't paid attention to the yearly goals, but the story you are telling is quite believable (and also sad). To me it sounds like a disconnect between people who do planning and people who implement things. Thank you for sharing!
I find the HN structure very effective in following discussions and it is really the same structure that the author creates, just spread vertically instead of horizontally.
Has anyone used this for their company internal discussions? I'm keen on giving it a try. I've even grabbed the last published HN source code to give this a try.
Surprised that 4chan isn't mentioned here. IMO the linear structure combined with references gives you the best of both worlds. You can follow the discussion linearly, but also jump around to check references.
This dates back to 2014 where Turkey was still struggling with the aftermath of widespread civil unrest. The entire nation found itself highly polarized while debates were fueled with mutual anger and disbelief.
This is an "argument analysis platform", as they call it, and it is open source, too, maintained at https://github.com/arguman/arguman.org .
The basic premise is the construction of an argument map, "arguably" a common utility to practice critical thinking.
More info on that at https://en.wikipedia.org/wiki/Argument_map .