Loomio

Github/Obsidian Experiment

RH Ronen Hirsch Public Seen by 7

A container for discussing the unfolding of the proposal from @Josh Fairhead to transition from CollectiveOne to version-controlled Github/Obsidian in order to facilitate flowing collaboration.

JF

Josh Fairhead Sat 11 Sep 2021 1:08PM

@Ronen Hirschs response in the poll

Thank you @Josh Fairhead for responding to the need and for the clear proposal.

I am open to this experiment assuming we remember that it is just that ... an experiment ... done with a sacrificial spirit.

I haven't thought this all the way through (I'm kind of relying on you) ... but here are some considerations/questions that come to mind:

  1. How do the cards convert to Github? Is each sequence a file or is each card?

  2. If cards are separate files how do they come to be in sequence?

  3. How are sequences arranged in sequences/groups/subgroups? Or does this need to be reconsidered in the github paradigm?

  4. While I feel I've understood Github for some years I've never been able to get it to work (even when I was using atom.io as my IDE) ... so I'm relying on you to be able to walk me (and everyone else) through getting it setup and learning to work within it

My response in Discord as I couldn't reply:

Thanks, I'm aware I made the mistake. I figured trying to repair it would make things worse (like the mandala) by confusing people with multiple mails that looked the same etc. I figured it best to deal with by discounting the votes of non-members rather than making noise. I also couldn't figure out how to edit participants which sealed the deal... Anyway, to respond to your questions here (as again Loomio says no):

>>> How do the cards convert to Github? Is each sequence a file or is each card? 2. If cards are separate files how do they come to be in sequence? 3. How are sequences arranged in sequences/groups/subgroups? Or does this need to be reconsidered in the github paradigm? While I feel I've understood Github for some years I've never been able to get it to work (even when I was using atom.io as my IDE) ... so I'm relying on you to be able to walk me (and everyone else) through getting it setup and learning to work within it.<<<

1. Each card becomes a markdown file in Obsidian. Cards are atomic pages. On github this just looks like a repo with .md files, the cards wont link together well on Github (thats what Obsidian is for) but they can be navigated to for comment.

2. Sequences can be maintained (at multiple levels of scale) through index files or in folders. We get to pick. I generally like folders for highest level encapsulation and partitioning things but index pages for navigation. Tags and so forth can also be used but I honestly think they are probably overkill.

3. I don't understand the question properly. Obsidian (not github) is non prescriptive so I can preserve the current structure of cards and folders.

Re: Github, I'm confident enough that I can get it to work as far as our needs go. Github is fairly straightforward and just a place to store things. I've never been the maintainer before but I've worked collaboratively with them and its grand. Using Git (the tool) is the tricky thing really but again I've got the basics and have a desire to master it.

RH

Ronen Hirsch Tue 14 Sep 2021 9:40AM

Since I don't have direct experience with Github ... and I'm not sure if anyone has tried what we are going to try on Github ... my questions may come from ignorance.

I feel some concern about the sequencing aspect. Sequences are a key ingredient in this work. Cards are sequences in a generative sequence. Generative Sequences are sequenced within groups of sequences. And Groups of sequences are also sequenced.

If I understand you correctly, you are saying that sequence does not exist on Github, that it exists in how I arrange discrete objects in my view of Obsidian. Does this mean that the sequence does not make it through to Github and by implication to other collaborators? If I make a change to the order of cards in a sequence, that makes no change ni Github? If someone else wants to change the order of cards in a sequence, do they have no way of communicating that to me?

If that is the case, I am wondering (out loud) if it isn't better to make the sequence itself (a collection of ordered cards) the basic building block/document in Github? We may lose the ability to, for example, comment on a single card - the comment thread may have to be integrated for the entire sequence (this is where small advantages start to become noticeable in CollectiveOne) ... but that seems like a "reasonable" price for capturing sequence.

JF

Josh Fairhead Tue 14 Sep 2021 5:47PM

Hey Ronen, I feel I understand your concern and that it won't be an issue for us. However its probably easier for me to show you why, rather than explain. None the less I shall try to do so :)

Github is just like an external drive. Its completely indifferent to how you structure the file system and just replicates whatever one puts on it from their computer. Tonnes of folders = Tonnes of folders, no folders = no folders.

Obsidian acts like a file system and this is replicated to github. It's non-prescriptive in its structure, and one can create a structure of choice. It's essentially a docstore if you know what that is. Assuming you don't, the important thing to know is that it has the most open structure possible (more affordances/more life). Everything is a document, the attributes of which are then user defined.

So I can create hierarchical structures, or associative horizontal/rhizomatic structures. In our case I will do the following:

  • Create folders for each of us (folders give clear boundaries)

  • Create a folder for the GP that has a group consensus on the contents

  • Within these folders I'll replicate the structures on C1 (sub folders)

  • In each sub folder I'll replicate the cards as markdown files

  • For each collection of cards (gathered in appropriate folders) I'll create an index that references all the cards contained within as well as useful links for traversing to other indexs in other folders.

If I make a change to the order of cards in a sequence, that makes no change ni Github? If someone else wants to change the order of cards in a sequence, do they have no way of communicating that to me?

This is why I would create an index that references other cards in the folder. You can change the sequence and it will change in github for collaborators.

If someone else wants to change the order of cards in a sequence, do they have no way of communicating that to me?

They just edit the sequence in the index and push to github. When others pull it will update on their computers.

If that is the case, I am wondering (out loud) if it isn't better to make the sequence itself (a collection of ordered cards) the basic building block/document in Github?

Yes, this is what I mean by an index; an ordered map of content. A collection of links to atomic cards.

We may lose the ability to, for example, comment on a single card - the comment thread may have to be integrated for the entire sequence

Actually no. We will have both cards and indexes on which we can comment on. An index that captures the sequence is essentially just a meta card.

I hope my explanation is sufficient in alleviating any concerns you are holding. I'll put this together and show you (in a sacrificial spirit) that there is no reason for concern. Worry not amigo, you'll love this toy once the works done :)

RH

Ronen Hirsch Thu 16 Sep 2021 9:42AM

I am looking forward to experience what will manifest :)

I want to propose a phased transition:

  1. Creating personal spaces where we can each setup the tool and play around.

  2. Creating a shared exploration space which will first be populated with Metagen. This will allow us to try collaboration.

  3. Finally, create the "consented shared space" where the core GP can be transferred.

This will allow for:

  1. A gradual transition

  2. To keep working on the GP on CollectiveOne until we are equipped and ready to make a clear-cut transition (hopefully a short period in which we don't make any more changes on C1) to working in the Obsidian.

JF

Josh Fairhead Thu 16 Sep 2021 9:59AM

That's pretty much the exact structure I was going for Ronen. If people can NOT use C1 over the next few days (or at least minimise their use) I'm happy to get started porting everything over today/tomorrow. I feel a phased transition could get messy so I'll try to do it all lickity split in a moment of downtime.

RH

Ronen Hirsch Thu 16 Sep 2021 10:33AM

I think you may have missed my point :)

Because we have no experience yet in being in this new environment, I was suggesting two intermediate steps which would give us individually & collectively experiential time in it. This is BEFORE committing to NOT working on and TRANSITIONING the core GP.

However, since you are the one "paying the sacrificial price" it is up to you to decide if you want to take a more gradual path or just jump into the deep end with the GP.

If you decide to go full on, I suggest a message on Discord announcing "hands off GP" followed by, when you are ready, a message "hands on GP" :)

JF

Josh Fairhead Thu 16 Sep 2021 11:14AM

Your right yeah, I did miss the point - my plan was to move everything in one go. The issue I think were navigating is the "canonical source of truth" issue. Basically we need a single place which represents our shared reality, but two tools. This requires change management as you implicitly suggest, and the proposed method is a good one IMO.

I'll duplicate personal spaces and the metagen for now.

RH

Ronen Hirsch Wed 27 Oct 2021 1:14PM

On October 25th @Josh Fairhead kindly escorted me into the Obsidian/Github space.

We discussed the fact that currently each of us has an individual fork from the core space but that we are not currently synchronizing with each other. Each of our individual Obsidian applications is currently committing changes into our personal forks but our personal forks are not committing changes to the core version.

There are numerous reasons for this. One is that this prevents (intentional or accidental) modification to each personal space by others. Another is that this requires governance decisions around the central repository that Josh did not want to make unilaterally. However, in effect, this is a policy, and one which does not allow us to synchronize our forks and collaborate. So, Josh and I discussed this and decided on behalf of the crew that a permissive policy is a better default policy because it will enable collaboration which is why we moved into this space. Then, we can have, if and when needs or wishes arise, discussions about a more refined governance model.

Josh and I are planning to have another conversation during which Josh will show me around Obsidian itself.

Right now, I am feeling a bit uneasy in the space. It is clear to me that collaboration is indeed a powerful capacity in this space. However, I currently don't know how to use the space effectively for something as simple as a reading of the GP. The current fragmented arrangement, in which each card is a separate file, does not (within my beginner understanding of Obsidian) seem to permit experiencing a sequence as a whole. Additionally, the file-browser creates a potentially misleading perception because the order of the files does not match the order of the steps in the sequence!

RD

Robert Damashek Fri 29 Oct 2021 1:25AM

I had similar concerns until @Josh Fairhead took me through the functionality of Obsidian, and I saw how to hide the markdown elements and view it as an organized whole. At that point, it became just about as easy for me to see the sequence of the GP and to read the GP as it had been in Collective One. However, it does seem from your discussion above that we need to come up with an effective and intuitive way to enter into proposals for governance that would involve commenting on, proposing changes to, and forming consensus on those changes to the GP.

JF

Josh Fairhead Fri 29 Oct 2021 11:19AM

So assuming a new process where everyones a maintainer on the SoCoDoJo org - effectively making all actions permissionless - it should be a matter of just pushing changes to update everyone else (there might be merge conflicts to handle in this scenario). A workflow there might be to copy notes into personal spaces (or transclude them) and make changes there (this would change our own work for everybody, but since its our own space that should be acceptable). Anything getting changed in the shared space would also be changed for all. I personally think that should be a consent process rather than consensus process; suggest changes, if no objections they can be added. This was kinda the direction we were heading with the Socratic process anyway. I see consensus as useful in relation to the "being" of a group and while I'd rather avoid it as a modality for everything else (e.g. initiatives like consulting), I can see that the GP is close to this fuzzy boundary.

Load More