[[Presentation]] about [[How to Build a Collective Brain with AI]] at [[Clouds on Mars|CoM]] ![[How to Build a Collective Brain with AI.png]] > An effective mind - human or machine - can’t and shouldn’t hold every detail in working memory. It filters aggressively, abstracts, and encodes, yet stays ready to recover the right detail at the right moment. The leverage was never in how much you know; it’s in how well you administer what you already have. A shared brain extends that principle from one head to many - people, teams, and AI navigating the same legible structure. Not a bigger archive - a better-organized one, built so the right knowledge surfaces for whoever needs it. So the question isn’t how much your organization knows. It’s whether anyone - or anything - can find it when it matters. ## Questions > Czy do Obsydiana da się łatwo zaimportować nasze notatki z innych narzędzi w stylu google keep czy one note, i czy taki import ma sens?  > Szerzej - jak do tematu podejść żeby nie robić wszystkiego "od zera"? - da się, i to bez ręcznej roboty - Obsidian ma oficjalny plugin [[Obsidian Importer|Importer]], który obsługuje wprost oba wymienione narzędzia: [[Google Keep]] (z paczki Google Takeout) i OneNote (loguje się na konto Microsoft i zaciąga notesy), a poza tym Notion, Evernote, Apple Notes, Bear, Craft, Roam, HTML i CSV - gdyby narzędzia nie było na liście, to dopiero wtedy ręcznie - wystarczy wrzucić pliki [[Markdown|markdownowe]] do folderu i wskazać go Obsidianowi, bo vault to zwykły katalog na dysku - wąskim gardłem jest zawsze eksport, nie import - [[Obsidian Importer|Importer]] przeczyta tylko tyle, ile narzędzie źródłowe zgodzi się wypuścić - w ostateczności eksport do formatu, jaki narzędzie daje, i LLM do konwersji na [[Markdown]] - można nawet poprosić o wygenerowanie grafu, podobnie jak [[Karpathy method]] - ale "czy ma sens" to ważniejsza połowa pytania, i tu odpowiedź brzmi: importujcie, ale nie do grafu - 5000 notatek z [[Google Keep|Keepa]] wrzuconych hurtem daje archiwum, nie drugi mózg - [[Single Source of Truth]] to nie to samo co wysypisko - traktowałbym import jako materiał źródłowy w osobnym folderze: przeszukiwalny, ale poza strukturą - notatka wchodzi do grafu wtedy, kiedy ktoś realnie jej użyje i ją podlinkuje - inaczej od pierwszego dnia płacicie koszt utrzymania czegoś, czego nikt nie przeczytał > Z obsydian synca korzystam od 3 lat. Z merge konfliktami działa średnio - próbuje rozwiązywać konflikty, pokazuję poprzednie wersję i ich źródło. Proble pojawia się głównie orzy usuwaniu, bo ciężko to znaleźć wtedy. Sync zakłada przede wszystkim synchronizację czasu rzeczywistego. Wszyscy maja mieć dostęp do wszystkiego. Najważniejsze jest ograniczenie plików do 200MB. > Na moje najsensowniejszą strategią organizacyjną jest to, żeby cała organizacja ogarniała GITa (nie znam innej sensownej metody zarządzania plikami współdzielonymi poza wymuszeniem synchronizacji czasu rzeczywistego co się nie skaluje dobrze na większy zespół) w podstawowym poziomie i budowa jakiejś struktury drzewiastej opartej o submodules - na przykład dla marketingu, HRów, klientów (z bazą wiedzy ogólną, projektami realizowanymi i presale). Koniec końców największe wyzwanie tego to będzie rozmiar, bo grupa bardzo szybko zrobi repozytorium na paręset giga i będzie chciała trzymać PowerPointy, grafiki, Excele itp. Będę obserwował co wypracujecie organizacyjnie i jak dużo oporów/wyzwań z adopcją się pojawi, bo z doświadczenia wiem, że adopcja standardu jest najtrudniejsza 😁 - **[[Obsidian Sync|Sync]] i [[Git]] to nie konkurencja, tylko dwie różne funkcje** - u mnie działa jedno i drugie: [[Obsidian Sync]] trzyma aktualną wersję na wszystkich urządzeniach, [[Git]] daje to, czego [[Obsidian Sync|Sync]] nie ma - workflow, pełną historię i review (u mnie [[git worktree|worktree]] dla agentów) - merge conflictu, który musiałbym rozwiązać ręcznie, nie miałem ani razu (mam ustawione auto), a usunięte pliki [[Obsidian Sync|Sync]] przywraca z ustawień, też bulkowo - to nie są argumenty przeciw [[Obsidian Sync|Syncowi]], tylko przeciw traktowaniu go jako jedynego mechanizmu - w organizacji i tak szedłbym w [[Version control|system kontroli wersji]], bo pytanie nie brzmi "jak zsynchronizować pliki", tylko "jak uzgodnić zmianę" - **Rozmiar to nie problem Obsidiana, tylko tego, co do niego wkładacie** - [[Single Source of Truth]] nie oznacza, że wszystko fizycznie leży w jednym miejscu, tylko że wszystko da się stamtąd odnaleźć - [[Blob|bloby]] (PowerPointy, Excele, grafiki) zostają na OneDrive czy SharePoint, a w Obsidianie ląduje link - w [[Git|Gicie]] jest to zresztą ostrzejsze niż w Obsidianie: [[Blob|binarka]] wrzucona raz zostaje w historii na zawsze, a każda kolejna wersja to pełna kopia, więc repo puchnie nieodwracalnie - tekst i tylko tekst, i wtedy te paręset giga nie ma prawa się pojawić - drzewko na [[Git submodules|submodules]] jako kierunek jest OK, ale [[Git submodules|submodules]] są uciążliwe w codziennej pracy (detached HEAD, podwójne commity) i osoby nietechniczne się na nich wykładają - rozważyłbym raczej osobne repo per domena i cienki vault-indeks, który spina je linkami - **Najtrudniejsza nie jest adopcja standardu, tylko założenie, że standard się adoptuje** - doprecyzowałbym "cała organizacja ogarnia [[Git|Gita]]" na "ogarnia [[Version control|system kontroli wersji]]" - sam [[Git]] jest prosty jak cep, trudne jest to, jak zespół nim pracuje: [[Gitflow|gitflow]] czy [[Trunk-based development|trunk-based]], kto robi [[Code review|CR]], gdzie gatekeepujemy i jak wprowadzić w to ludzi, którzy dotąd narzędzia nie znali - dokładnie o tym jest moja prezentacja - narzędzie samo z siebie nie rozwiązuje problemu, bo problem siedzi w metodzie - w Twoim ostatnim zdaniu jest zresztą odpowiedź, dlaczego to jest tak trudne :D - "[[Adoption|adopcja]] standardu" zakłada, że my znamy odpowiedź i ją narzucamy, a inni mogą mieć inne zdanie i rację - widziałem N razy, jak ktoś wprowadzał standard odgórnie i dupa, bo to jest ciało obce i long-termowo się nie przyjmie - działa co innego: pokazać na małej grupie, że podejście pomaga ([[Lead by example]]), i skalować to, co samo zaczyna się przyjmować. Rolą [[Leadership|leadershipu]] jest budowanie środowiska, w którym te standardy wyłonią się jako [[Emergent property|własność emergentna]], a nie zostaną ogłoszone - zwykle problemem jest kierunek zmian (narzędzie - metoda, standard - komunikacja), czyli zabieramy się do rzeczy od ~~dupy~~ niewłaściwej strony - dlatego zanim wdrożycie cokolwiek, warto zapytać: "dlaczego dotąd tego nie robiliśmy?" - z odpowiedzi zwykle wychodzi, że narzucany standard i tak nie trafia w prawdziwą przyczynę ^jan