Спасибо! Нам интересны любые комментарии :)

Спасибо, посмотрю обязательно )

Коллеги, я только начала изучать вопрос «Можно ли вести базу знаний не в Confluence?». В конф мне удобно и хорошо, но попросили поискать другие инструменты. Ткните меня в подобные обсуждения, если они были. Пожалуйста

Сформулирую иначе: Confluence достаточно достойный инструмент, чтоб его отстаивать и другие варианты не искать? Мне нужно несколько пространств, ссылки, метки и поиск, разграничение прав

Тут скорее вопрос "а зачем?") Конфа ван лав)

Экономия, мать ее. Компания не жадная и не бедная, но есть в ней любители экономить

То есть, эти любители хотят аналог конфлюенса за бесплатно?

Можно канеш попробовать бесплатный вики-движок типа dokuwiki или Wiki.js, но окупятся ли затраты на его допиливание под нужные требования по сравнению с оплатой конфы - ну хз...

Вот @AbashkinIvan рассказывал свой путь про внедрения баз знаний

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

Около 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.

Я немного не догоняю, поясни плиз, если можешь

Создаём репу в гитлабе. Но вместо .мд файлов создаём там .аскидок файлы, так?

Скорее всего, но я думаю автор поста более подробнее может сказать @AbashkinIvan

Ребят, скажите, кто-нибудь работает с иностранными компаниями через ИП? Хочу узнать подводные камни)

Ох, спасибо! Самое смешное, что Git есть и активно пользуемся

Я работала три месяца

Мне древовидный список из аутлайнера Dynalist (в формате OPML или HTML Formatted text или MD) нужно импортировать в Obsidian как связанные заметки.
То есть, нужен скрипт, который пройдется по списку и для каждой ветки создаcт md файл, в тело которого пропишет имя родительской ветки.
Скрипты я пишу не часто. Для такого рода ETL операций какой язык и среду рекомендуете? Чтобы подобные задачи в одном месте решать.

Я работал почти 3 года. Задавайте свои ответы

Так (хоть я и не афтор) ) И гитлаб и гитхаб замечательно кушают адок

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