I would say so far, while I respect and appreciate the continued Roam focus, it is less of interest to me directly. I had the impression that xxxx’s approach might be more portable, but from what I’ve seen so far it is actually highly dependent on Roam-specific features, UI, etc. That may be great for Roam lovers and existing community members, but it makes the potential scope of book clubs configured this way much more limited due to pricing at the very least, not to mention that outliners in general, and Roam in particular are simply not an approach that everyone “gets”. So again I understand and appreciate why it’s being done this way, it just means it’s of less strong interest to me at the moment.
yeah - you’re right - going the block-level approach is going to impact portability - though I have a feeling knowledge engineers can work at whatever level they are empowered and those who not working at this level can choose other tools.
so I don’t think it is so much about the book map (or even Roam). the larger vision is how to collectively converse around knowledge objects (eg. books) regardless of what platform we are on. we are in an inquiry as to whether Discourse can be the glue?
the challenge in front of is if we can architect a discussion platform such that it works across book clubs no matter how each leader decides to wire their front end.
the page based approach you saw the previous wkd with xxxxx definitely dumbs things down a bit - you noticed the discussion section and we talked about whether we could prototype a back & forth conversation with an author (let’s say Priya Parker) who do not use Roam
one of the points we developed on Sat is we all wear different hats - those who chose to encode the knowledge may choose Roam but this choice doesn’t need to be exposed to experts out there in the field who wish to simply chime in.
i don’t know if this makes sense - i would really like to diagram this with you and anyone else who is interested in ironing out information flow at this level.
Well, that’s just articulating the problem again though, and doesn’t that very definition (“knowledge engineers”) largely exclude many in audiences you are interested serving, such as the dance community? Put another way, it feels to me as though this approach to a book club is very particular in who it is serving and who can benefit from it. If that is accepted or even intentional, then that’s fine. I just had the impression that the hope/intention was to be broadening the potential community/participant pool.
I agree, absolutely! I just thought that I’d be seeing at least some acknowledgement of that, even just tacitly, in the meeting on Saturday and I didn’t get any sense of that. It was very unquestioningly Roam-focused from my outside perspective.
But I do feel like a possible next step is to try to test out an alternative/reimagining of that workflow in the context of another tool, like Discourse. There are at least two questions to my mind. First and most fundamentally, does it work to adapt the general concepts and workflow? Can you use the provided tools in Discourse to approximate (or even improve on) the approach used to reach the goals of the techniques used in Roam? And then secondarily, as it pertains to the relevance of Discourse to RBC itself and the Roam-driven book clubs, does Discourse feel good/useful/interesting in actual use to at least some subset of the Roam people doing RBC?
The problem is it would take a fair bit of work to effectively adapt the structure/model/approach to Discourse. I can definitely see it’s quite possible, I have plenty of ideas already for how to do it. But the devil is in the details, and I can easily imagine running into having to spend a lot of time trying to fully duplicate the workflow. Time I unfortunately don’t have time for at the moment. Maybe that simply suggests a “proof of concept”, 80/20 rule implementation": outline the broad strokes of how it might work in Discourse, see if people see any promise in it.
There is also the separate question that you were speaking to of a more hybrid approach, which might e.g. use Discourse for just the “discussion” element of it, and feed back into Roam, or go bidirectionally. I guess that’s strongly correlated with my secondary goal outlined above, because the point of whether Roamans like Discourse and the feel of using it really probably comes down to its use in concert with Roam. We’re not trying to move people off a tool if they like how it’s serving them…
Definitely thinking out loud here, apologies if it’s a bit unfocused…
we’re on the same page. what I am starting to see newly is accepting the fact that only a subset of a dance community are technically proficient and a subset want to do knowledge engineering work.
that said, there are plenty who will participate in a “facebook style” discussion (we already in the bay area have the problem of “trash fires” that my co-organizers are always commenting on and wondering how to transform)
the pain point being is too simple of a tool - wide audience - too complex - it becomes niche.
so how do we as “architects” of conversation provide multiple interfaces to the same data set?
only a small % like you & me are committed to this!
ps. I know you are not a dancer so this is also a good example of how the puzzle is how to bridge cultures.
I sense xxxxx is on our side of the fence. she is already wanting to give Matt feedback in a “nice” way it seems…
nothing against xxxx - I want to get what he sees and we can then think implementation newly once we get to the bottom of what he is conveying (which happens through experience)
yes I see MVP - a few questions across Roam and maybe Obsidian (less emphasis here but important to appease non-roam TFT folks) and the data in Discourse as threads as we touched upon. the demo is showing information flow and making the point why each tool is important contributing from that vantage point.
not attached to roam - modelling the behavior between a TFT and discussion platform and why it matters I think is the building block!
Yes, definitely interested in bridging cultures and providing multiple interfaces to the same data! It’s a challenging problem though, and as is often the case (Markdown is a good example), it will probably require some amount of “dumbing down”, at least at first. One easier route to being able to visualize core data in multiple ways is to simplify to the most basic and flexible primitives. That’s something markdown does very well, and so it’s not surprising (and is helpful) that it’s an export/storage format for both Roam and Discourse…
Yes, absolutely. We are in an early phase still, and figuring out workflows probably happens best, at least initially, in a single tool. Xxxx is still in the figuring out workflow phase. Once he’s figured out something he thinks is reasonably optimized, it can maybe be adapted then. Maybe I just came to all this a bit early. 
I still would like to know if he (Xxxx) is actually even interested in more tool options for people to implement his methodologies though.
Interesting! Yes, showing the power of markdown for multi-tool interop would be pretty darn cool. And totally should be do-able. Although I don’t know about Obsidian simply because it doesn’t have a web-exposed API AFAIK.
Yeah, that sounds like a good core goal/problem description. Who might be our best collaborators/testers?
1 Like
I like what you’ve done here!
I am super curious while we are in a world where we aren’t operating off a unified data store (not yet, I included you on a tweet that help lay promising foundation! 
- who’s “job” it is to move across mediums like you have done?
I admittedly was in a time crunch so as much as I wanted to personally traverse myself, it wasn’t the cards I dealt with!
I feel in an ideal world, one could mass thread in Slack and some automation would see Slack threads as an “event trigger” and “render” our conversation threads here in Discourse.
I suspect each thread would be its own topic for manageability & get there are pros and cons!
ok based on our last conversation, sounds like if either you or I run into the need to long-form respond on any instant messaging platform (text, Slack, Discord, etc.), we agree to hop over to Discourse which gives the capacity for either of us to quote respond and do the divergence/convergence dance
I’m also going to err on using instant messengers dedicated to the task for DMs and err less on using the private message function here (including chat) so we have the maximum flexibility around using the advanced features of Discourse to move things around (which we discovered is limited in private messages).
I’d say if at any time, we notice a major upgrade to how private messages and/or chat works, we can revisit these again
Yeah, that’s what I was envisioning/hoping for too! But I don’t have the skills to create it, nor am I confident that anyone else would really want that or care about it, hah. But it does make me think, for example, if such a thing had existed while the Roam Discourse instance was still alive. Perhaps it could have better harmonized the Slack with the Discourse… Still I think it might be a niche use case, and I think it’s important to point out that really the only reason I did it here is because we stayed in Slack, rather than moving to Discourse to continue discussion in the first place. In other words due to inertia we stayed in Slack, I found Slack conversation and threading to be getting confusing, felt that Discourse would be an improvement, so I moved stuff over here to continue it, and also just to demonstrate the conceptual mapping of threads to quotes and replies.
I do think however that it could be an interesting model for a more generalized concept of how to do interop between varying communications mediums. A big question like that which has come up is exemplified by e.g. how do you harmonize a Twitter 280 character self-reply-based threading model with something like Discourse, and what I’ve discovered and tested here with Slack-to-Discourse might be an early example of one approach. Ultimately I hope that the “fediverse” type stuff will tackle not only the ability to get content back and forth, but the actual conversion of “conversational” or “writing” models, if that makes sense. E.g. how do you instantiate conversation in a threaded conversation system into one without threads, and not lose a lot of important meaning, context, etc. This may be a partial early answer…
That may be the compromise we have to go by, sure. But personally I pretty well dislike Slack (I like Discord more, but only a bit). I’d be happy to leave it behind as soon as possible. I just left my one work-related Slack so I’m ready. I’m willing to stay there to continue our discussions as-needed, but the critical concern I have, and the reason I installed Chat here and love Discourse’s goals with that (if not its current implementation/nav/“feel”) is this: you never know when “important” or “long form” discussion is going to happen! IF you can be self-disciplined enough to intentionally move over when it happens, then sure, it’s fine I guess to be split across tools for short vs. long form. But it’s an artificial and unnecessary split, at least conceptually. And in the long-term I hope to solve it.
Practically speaking of course you have things anchoring you in Slack. I don’t really, but we all have to compromise to make communications work sometimes, and so I stay. 
But I would certainly hope that you just remain mindful of when you actually have a lot to say, or the conversation seems to be getting complicated - such that managing it in Slack without good quoting ability and without good “convergent” conversation tools (such as quoting) is becoming cumbersome - and consider moving things over here. We can experiment with what that is actually like, e.g. does it involve copy/paste, or just a link to where the last message about the topic was posted in Slack and continued here from that point, etc.
Even if we’re disciplined about moving here when called for, it still leads to fragmentation, where a conversation ultimately happens in multiple places, and you need to jump around to fully reconstruct it. Hopefully that’s more of a problem in concept than in reality. But I also hope in the long-term to be able to avoid it more…