Comments 63
Первая и одна из самых ощутимых плюшек — категории. Страницы можно добавлять в категории, сами категории можно добавлять в категории. В отличие от файловой структуры (забудем про симлинки), страница/категория может находиться сразу в нескольких категориях. Использование категорий препятствует росту хаоса с ростом числа статей.
тоже считаю идею иерархических категорий (тегов) лучшим способом организовать базу знаний / хранилище файлов. рекомендую ознакомиться со следующим подходом: файловый менеджер на основе иерархических тегов. на мой взгляд там наиболее красиво реализована работа с иерархическими категориями.
ТС, обратите внимание на notion — там из коробки есть почти все что вы описали + лучше права доступа и куча классных функций именно для командной работы. Ну и вообще инструмент создавался для решения этой самой проблемы обмена знаниями (включая типизированные) в коллективе и отлично ее решает.
Единственное чего ещё нет — API для расширений.
К сожалению, насколько я понял, не self-hosted и хотят денег за продвинутые фишки.
Сам использую dokuwiki на своей vps-ке, но не очень нравится взаимодействие с ней, думаю перейти на confluence. Он хоть и не бесплатен, но хотя бы self-hosted.
Ps да, я люблю чтобы всё хостилось у меня. И никто не мог мне ничего отключить или поменять условия или поднять цену :)
Этого требования и не было в статье, вы правы. Это уже я делюсь своими мыслями о Notion.
Выделенный сервер у меня уже есть и поднять еще одну виртуалку — не сложно. Так что это не было бы проблемой, если бы notion был self-hosted. Про причину я уже писал выше:
Ps да, я люблю чтобы всё хостилось у меня. И никто не мог мне ничего отключить или поменять условия или поднять цену :)
Ну и из личных наблюдений: вики это классно и хорошо, но лично у меня руки опустились уже, потому как пишешь-пишешь туда, а толку нет. Все равно потом звонят и спрашивают о том, что уже описано, мотивируя «мне лень читать, ты лучше объясни».
Как с этим бороться, не знаю. Нельзя заставить человека читать вики, если он не хочет этого делать.
В одной прошлой компании где я работал я решал эту же проблему. Компания была удалённая и большая — вся коммуникация в slack. Решение само напросилось: каждый раз когда кто-то задавал вопрос в чатах, бот находимо подходящий ответ в базе знаний и постил в чат. Если информации не было, и кто-то давал ответ в чате, то одной командой можно было добавить пару вопрос/ответ в базу для следующих поисков.
Штукой этой было реально удобно пользоваться — никуда из слэка выходить не нужно было и месяца через два люди вообще сами перестали спрашивать в группах а спрашивали бота напрямую.
А вот это — просто бжественно:
Если информации не было, и кто-то давал ответ в чате, то одной командой можно было добавить пару вопрос/ответ в базу для следующих поисков.
Если не секрет — на чем бот был написан?
На TypeScript и nodejs. Я тогда создал удобный модульный фреймворк для написания этого бота (да и кучи других ботов для внутренних нужд компании). Его можно посмотреть у меня в гитхабе https://github.com/dempfi/xene. Для распознавания вопросов и поиска ответа использовал https://js.tensorflow.org.
В проекте есть мой заброшенный PR в котором можно подсмотреть простую распозновалку с нейронкой — хотел добавить в стандартную поставку фреймворка.
Только предупреждаю: я фреймворк давно не обновлял. Парни из моей команды его форкнули и продолжают поддерживать но уже внутри компании. Не в OSS из-за чисто юридической подоплёки — форк поддерживают в рабочее время, а все что пишется в рабочее время принадлежит компании.
Кстати, у вас не было опыта работы dokuwiki с большим числом статей, как она ведет себя на условных 5-10 тысячах страниц?
На данный момент у меня порядка 6000 страниц, так что приходится привередничать и смотреть не перфоманс и общую масштабируемость тех или иных решени. Уже неоднократно приходилось отказываться от тех или иных расширений и писать их аналоги из соображений отвратительного быстродействия. Любопытно, как с этим в dokuwiki.
Правда, нагрузи никакой.
В моем случае порядка 300-400 юзеров разной степени активности, нагрузка в рабочие часы довольно ощутимая и не все удается решить простым добавлением ресурсов. Не википедия, но и мириться с загрузкой хитрых визуализаций по несколько минут не хочется, приходится выкручиваться.
Сталкивался с падением производительности на некоторых расширениях dokuwiki, название не помню, например, в расширении, которое дерево страниц выводит слева от основного текста.
Самое главное, чего не хватает у всех wiki* — это семантических плагинов.
Это расширение понятия категорий. Каждой статье можно добавить неограниченное количество параметров различных типов. А потом по этим параметрам делать выборки, фильтровать и представлять в виде списков и таблиц, экспортирвоать в удобные форматы.
Для mediawiki есть плагин semantic-wiki. Для dokuwiki есть плагины типа strata, data.
К сожаление ни одна из известных мне wiki не поддерживает геоданные в качестве параметров.
Правда, не уверен, подходят ли в вашем случае существующие решения. Если не секрет, какая задача потребовала хранения геоданных?
Я веду небольшой сайт, посвященный горным перевалам Тянь-Шаня. Перевалы их параметры и фотографии хранятся в DokuWiki. С другой стороны хребтовка, на которой эти перевалы нанесены сделана в QGIS, а параметры хранятся в гео-базе данных.
Получается два совершенно разных хранилища, которые фиг синхронизируешь.
сайт: http:/pereval.cc
Хребтовка: nakarte.me/#m=13/41.93874/77.55507&l=O/Mt
Extension:Maps/Displaying_maps
За счет поддержи «под-объектов» и иже с ними в семантической медиавики можно хранить сложные данные.
Возникло несколько вопросов, с которыми пока не разобрался.
1. Возможно ли организовать в медиавики систему веток страниц как в git-e?
Поскольку сама игра обновляется всё-таки по версиям и при разработке новой версии может потребоваться существенно менять контент (как формализованный так и просто текст на страницах с описанием мира). Обычный способ, когда на одной странице пишется что-то вроде «для версии 2.4 у нас справедливо это, а в 2.5 уже вот это» плохо подходит.
2. Наткнулся на www.wikidata.org но не до конца понял какую именно роль wikidata должна играть в инфраструктуре wikimedia. Вы пробовали с ней работать?
Выглядит так, что её можно использовать как чистую базу знаний (для редактирования и поиска), а сами страницы генерировать своим кодом на основе запросов к ней. Но из того, что я пока увидел в её документации, она не рассчитана на работу с большими текстами.
mediawiki + sematicwiki, либо dokuwiki + data plugin
Но у них у всех свой специфический формат записи свойств в БД.
Еще как вариант можно использовать сайтогенераторы типа Jekyll или Hugo. Там на скриптах можно сделать вообще любое взаимодействие с БД, а хостить на гитхабе. Но придется много всего скриптить руками
1.
Можно имитировать ветки при помощи подстраниц, но не уверен, насколько это удобно будет. Гранулярный мерж между страницами будет невозможно сделать автоматически, только переносить целиком контент страницы из одной подстраницы в другую.
2.
С викидата я не работал, но базовая идея там та же, что у semantic mediawiki, cargo и иже с ними — дать возможность хранить структурированные и осмысленные данные, чтобы потом с ними можно было работать при помощи апи и вики-запросов.
С викидата я не работал, но базовая идея там та же, что у semantic mediawiki, cargo и иже с ними
Я вот, кстати, никак не пойму, зачем столько дублирования функциональности? Вроде бы ж это всё в рамках одного проекта (вики) делается? Или нет?
Расширения частоп млят независимые разработчики в своих нуждах. Некоторые потом используют в проектах фонда викимедиа, некоторые нет. Викидата появилась, как я понимаю, из тех соображений, что википедия не может себе позволить на несколько дней уйти в ридонли для обновления БД. Им пришлось писать свой хитрый способ решения проблемы.
Лично использую DokuWiki. Описал всю ит инфраструктуру. Всё сгруппировал, все удобно. Но ее удобно редактировать не большой группой человек. Остальным только читать.
Первая и одна из самых ощутимых плюшек — категории.
Только вот не всегда удобно пачкой переносить/переименовывать/удалять их. ИМХО лучше сразу ставить шаблоны которые уже будут включать статьи в категории.
Да, но тогда на всех страницах отобразятся изменения. Возможно не особо критично для корпоративных вики которые ведут 1-2 человека. Но не очень хорошо если кто-то еще следит за изменениями.
Мне помогает использование ботов, их удобно фильтровать при просмотре истории правок.
Расскажите про ботов подробнее? Я видел только тех что Википедии используются и как их настраивать на сторонних вики не особо понятно.
Можно задать юзера, о имени которого будут делаться правки в replaceText через параметр
$wgReplaceTextUser = "MyReplaceTextBot";в LocalSettings.php
Т.е. достаточно создать юзера, сделать его ботом и назначить его как автора всех правок, проведенных через replaceText.
Другие массовые скрипты обычно тоже так или иначе поддерживают осуществление правок от имени ботов.
Про это не подумал. Так действительно удобнее.
Но я имел ввиду работу и настройку вот этих ребят:
https://meta.wikimedia.org/wiki/InternetArchiveBot
https://github.com/cyberpower678/Cyberbot_II
Ну и как ветеран SMW, реквестирую статьи про семейство семантических расширений и расширений, используемых в Wikidata.
Медиавики ставят только те, кто хочет или решить свою проблему бесплатно, или те, кому это действительно интересно. И в том, и в другом случае это не особенно приносит денег сторонним вики-разработчикам.
Впрочем, я могу ошибаться: в конце концов база знаний — это не основная моя деятельность, а скорее пет-проект с пользой для компании. Я не пробовал всерьез зарабатывать на этом деньги.
Кстати, а можете поделиться своим опытом бытия викимастером в прошлом? Как вы искали заказы и чем занимались? Если не секрет, конечно.
При этом допрограммировать пришлось 0 строк, только настройками обошёлся.
пользуем на ворке redmine. Но не только как вики.
ЗЫ: Кто нить знает рабочий standalone аналог с textile?
Если бы внедрял подобную систему сейчас, в первую очередь смотрел бы на что-нибудь подобное FosWiki.
К сожалению, версия mindtouch core, уже не поддерживается разработчиком, это бесплатная версия и вроде все о чем вы говорили есть сразу в коробке. это self-hosted решение.
Почему строить базу знаний компании на основе mediawiki — недурная затея