Missing Structure in Technical Discussions
kvark.github.io
kvark.github.io
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 .
For example, https://en.arguman.org/there-is-no-such-thing-as-global-warm.... Every argument, good or bad, falls under some sort of fallacy.
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?
Merely allowing fallacies seemingly has an adverse affect on the whole promise.
Thanks for this clarification.
https://pol.is/ https://github.com/pol-is/
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.
https://debconf18.debconf.org/talks/135-q-a-session-with-min... https://blog.pol.is/pol-is-in-taiwan-da7570d372b5 https://blog.pol.is/uber-responds-to-vtaiwans-coherent-blend...
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.
I guess not all is lost yet for humanity!
The wikipedia article gives some background and references to (mostly abandoned) tools.
https://en.wikipedia.org/wiki/Issue-based_information_system
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].
1. https://pron.github.io/computation-logic-algebra
2. https://en.wikipedia.org/wiki/Stephen_Toulmin#The_Toulmin_Mo...
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.
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!
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.
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.
I could see more rigid logic formats than just 'tree' (and am indeed working on this) but the goals here are right
both for ease of reading and truth-seeking
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.)
> (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.
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.)
"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.
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.