Попробуй obsidian.md , там заголовки в ссылках меняются

Его и пробовал)

Не понравилось что там визивига нет, кстати

а чего б не вики какая-нибудь? media/doku, под них md-плагины есть, визивиг есть.

Я сейчас активно пользуюсь обсидианом. В нем офигенно просто создавать новые заметки и линковать их. Если бы я делал это через какие-то CMS или визивиги (да даже тот же Roam Research), то я бы больше времени на оформление тратил. А сейчас трачу на написание заметок.

Markdown и доп функции обсидиана постепенно изучаются, и заметки становятся “богаче”. Кажется, визивиг и не нужен =)

- Notion слишком тяжеловесный, неудобный (в нем все работает не так, как ожидаешь увидеть в текстовом редакторе), медленный.
- Roam довольно “некрасивый”. Глубоко не копал. Я пробовал его совместно с обсидианом и обсидиан порадовал своим интерфейсом больше.
- Confluence неудобный (многое спрятано за менюшками и плагинами), и есть “ожидание”, что страница в конфлю должна быть “завершенной”, оформленной. Сразу представляешь сколько времени ты потратишь на одну заметку и уже не хочешь ее писать.
- Notes, Bear и аналоги лишены удобного инструмента линковки. Но очень опрятны и просты (как обсидиан)


То есть, в обсидиане для меня очень низкий порог для написания новой заметки. Я не задумываюсь об оформлении сразу. Потом, когда мысли оформятся в текст, тогда и займусь оформлением

Минусы обсидиана:
- Пока отсутствует синхронизация. Я решил через яндекс диск. Но нельзя держать на двух компьютерах обсидиан открытым, начинают конфликтовать.
- Нет приложения под мобильные платформы. И пока никак не решил =(

Из плюсов, недавно опубликовали плагин Publish и теперь как-то и куда-то можно публиковать свои заметки. Выглядит пристойно https://publish.obsidian.md/help/Add-on+services/Obsidian+Publish

Ещё есть coda.io - очень удобная штука, проще чем notion, и уж тем более проще wiki движков

Ребят, в чате про Zettelkasten (@Zettelkasten_ru) меня попросили описать свой опыт по накоплению "заметок". Одна из его частей про накопление "заметок" в компании.

Рассказ выродился в лонгрид из трёх постов. Я сюда перепощу, надеюсь будет кому-нибудь интересно

История про базу знаний внутри компании.

Около 5 лет я выстраивал службу поддержки клиентов. Сфера технически сложная. Много нюансов в инженерной части. Небольшие вариации обстановки у Клиента в корне могут поменять процесс работы над его проблемой. Поэтому специалистам поддержки очень много информации необходимо держать в голове, чтобы в онлайн-режиме подстраивать диалог, направляя его в нужное русло.
Продукты, которые мы поддерживали, так же технически сложные. Необходимо помнить как именно работают эти штуки их ттх и нюансы взаимодействия с внешним миром.

В компании была развернута MediaWiki, но ею никто не пользовался - слишком муторно.
В то время я уже использовал Evernote для ведения собственной базы знаний по работе. Предложил коллегам воспользоваться моими наработками. Получил от них положительные отзывы, некоторые даже начали писать туда свои статьи.
Потихоньку база знаний в Evernote наполнялась и был реально заметен эффект от её существования.

Но я всё равно был не доволен. В коллективе знания продолжали теряться. Люди из раза в раз ходили по одним и тем же граблям.

Я обратился к подходу Knowledge Centered Support (KCS). Его основная идея состоит в том, чтобы сотрудник после решения проблемы клиента, оставлял в системе ссылку на статью, по которой решается эта проблема. Если такой статьи нет, то сотрудник обязан её написать, законспектировав каким именно способом он решил проблему.

Параллельно внутренней базе знаний я взялся за организацию внешней: портала поддержки, где пользователи могли сами найти ответы.
Статьи в общем доступе должны быть качественные. Проработанные, понятные, красивые. Совсем не такие, какие мы позволяли себе вести во внутренней БЗ.

Нужно было выстраивать процесс по накоплению знаний. Когда сначала человек делает себе заметку. Потом превращает заметку в статью для коллег во внутренней БЗ. А потом выбираются наиболее популярные статьи и прорабатываются до уровня возможности выложить их на публику.

Чтобы всё это работало, нужно иметь несколько разных инструментов:
- Система, в которой определяется востребованность статей. (У нас это было специализированное ПО, в котором сотрудники общались с клиентами. По количеству и типу вопросов можно было оценить, что наиболее востребовано клиентами)
- Система, позволяющая быстро создавать личные заметки. (Здесь у нас до поры, до времени отлично справлялся Evernote)
- Система, позволяющая разворачивать личные заметки в более подробные статьи (Тут Evernote то же справлялся, но уже хуже. Для понимания на каком этапе находится конкретная заметка, нужно было учить сотрудников работе с определенной системой тегов, а они тяжело в это въезжали. Так же напрягало, что было не отследить кто и когда внёс какие изменения. Тяжело было откатить версию статьи назад).
- Процесс работы над превращением внутренних статей в статьи для внешних пользователей.  (Здесь нам помогали технические писатели)
- Система, в которой выполнялась публикация статей для внешних пользователей. Она должна была хорошо индексироваться поисковиками и подсказывать клиентам о существовании статьи по их вопросу.
(В качестве системы для внешних пользователей мы сначала использовали Copiny, а потом переехали на UserEcho)

Зоопарк изрядный. Всё это работало довольно хреново. Тяжело было за всем следить.

Вскоре всплыл ещё один момент - необходимо было отказаться от Evernote. Это был прекрасный инструмент. В нём было легко искать информацию и легко её создавать.
Но дело в том, что политика компании запрещала привязываться к облачным сервисам (в целях безопасности и для того, чтобы не зависеть от работоспособности сторонней инфраструктуры).
Работа с Evernote у нас была по собственной инициативе и как-бы из под полы. Неофициально.
А для Knowledge Centered Support мне необходимо было создать официальные регламенты, которые необходимо было бы соблюдать всем сотрудникам.

На замену Evernote я рассматривал всяческие Wiki-движки, корпоративные порталы по накоплению знаний. Сервисы документирования:
После отсева остались вот такие варианты:
- Atlassian Confluence
- Xwiki
- Bookstack
- И вариант, который выиграл.

Atlassian Confluence
Это был топ жир. Система специально предназначенная, чтобы большие компании вели там свою документацию. Отточенная, отлаженная, с большим сообществом. Дорогая. Связывающая руки.
В тот момент мы не могли себе позволить потратить такие деньги, которые требовались за 20-50 лицензий на Конфлюенс.

Xwiki
Корпоративная Open-Source замена Конфлюенсу.
Тяжелая, глючная, сложная. Бесплатная.
Мы в неё копнули, но вынуждены были остановится из-за непреодолимых приступов тошноты.

Bookstack
Прекрасный Open-Source аналог и Confluence и XWiki. Красивая, простая, удобная система с контролем доступа. Там даже можно нативно подключить draw.io для рисования блоксхем и совместного их редактирования.
Погоняли её, но не взлетела.
Два нюанса:
- По какой-то причине движок разметки ломал оглавление на длинных документах
- На тот момент было всего два уровня вложенности каталогов и народ не понимал как распихать текущие проекты на такую бедную структуру.

Вариант который выиграл
Это текстовые файлики. Вернулись обратно к истокам.
В тот момент у нас развернули корпоративный портал - Bitrix24. Там можно было создавать аналог яндекс.диска, но по проектам.
Мы делали общий шаренный диск, куда складывали файлы в удобном нам формате.
Там же можно было отследить историю изменений.
Битрикс это не только корпоративный портал, но и система управления задачами. Поэтому жизненный цикл статьи мы выстараивали через задачи.
Правда тут речь уже не шла о "выращивании" статей из зародышей. Тут уже были запросы "сверху" на написание той или иной статьи исходя из потребностей.
Поиск по базе файликов выполнялся с помощью DocFetcher.

Но Битрикс система глючная. То и дело у кого-то случался конфликт синхронизаций. Процесс работы со статьями вызывал споры из-за разных форматов. Написание статей по запросам попахивало бюрократией и не позволяло статьям появляться органичным образом.
База со статьями разросталась и вместе с ней рос её размер. Это создавало проблемы на компьютерах с заканчивающимся жестким диском.
DocFetcher был костылём, который люди тяжело воспринимали.
Ну и весь этот подход не очень пересекался с идеей KCS.

А я размышлял. Людям явно зашла работа с простыми файликами. И тут мы в отдел разработки установили GitLab.
Вот  оно!
Репозиторий со статьями в Markdown-формате. Гит как контроль версий. Поиск по всем репозиториям!  Ишью! Теги!

Сейчас мы перевели всю базу внутренних и внешних статей в Git-репозитории.
Новые статьи пишем сразу туда. Чуть позже накатим на них какой-нибудь генератор статических сайтов и откажемся от стороннего сервиса UserEcho в качестве хостинга статей для клиентов.

Параллельно прорабатываем вопрос по работе с документацией как с кодом. Идея в том, чтобы техпис работал с текстовым файлом и языком разметки и не заморачивался по поводу форматирования. Форматирование будет выполнять машина по заранее заданному шаблону.
В общем, всё то же, что и в абзаце выше, только более богатый язык разметки. Вместо markdown - asciidoc

Ведение статей и документации в простом языке разметки в git развязало нам руки, для того чтобы полноценно внедрить KCS.

Но я всё не унимаюсь. Меня всё таращит.
Что если попробовать создать корпоративный Зеттелькастен. Положить его в репозиторий да и научить ребят развивать идеи.
На мой взгляд это сильно поможет увязать все знания об оборудовании в одном месте и сильно ускорит процесс взросления статьи из обычной заметки на бегу к продукту, который можно показывать пользователям.

спасибо большое, что поделились!

Иван, спасибо за интересный опыт

Перед моей группой стоит похожая задача

Друзья, если интересно узнать про Зеттелькастен, то в двух словах это способ думать, обрабатывать и изучать информацию.

Подробнее рекомендую почитать вот в этих статьях:
https://vas3k.club/post/3040/
https://habr.com/ru/post/508672/

Программ для ведения цифрового Зеттелькастена - много. Лично я очень рекомендую:
obsidian.md

Как использовать этот метод коллективно, предлагаю подумать в @Zettelkasten_ru
Мне думается, что напрямую метод для личного использования для коллектива работать будет плохо. Но можно попробовать адаптировать.

Да, отлично, спасибо за ссылки

^ это Ник Милтон.

он конкретных формул бы дал, а так обо всё и ни о чём)
Tangible - должна быть формула, иначе это intangible

но опрос у него интересный, это факт