В последнее время Confluence и sharepoint стали почти безраздельно править на рынке баз знаний. Системы отличные, не спорю, но лично мне не хватает их гибкости да и в целом как-то не срослось: вики-возможности sharepoint остались где-то на уровне 2005 года (про работу с офисными документами молчу, с ними все гуд), а Confluence в силу своих особенностей с ростом числа статей неумолимо превращался в свалку, в которой невозможно найти что-либо нужное (но, может, проблема была во мне).
Не умаляя достоинства этих систем, хотелось бы рассказать о том, какие возможности есть у Mediawiki в роли корпоративной базы знаний. Само собой, mediawiki подойдет не всем — в ней нет модной интеграции с jira/tfs/etc, перенос документов с картинками из пакета Microsoft Office доставляет кучу неудобств, да и сама она написана на PHP, что в последнее время служит отпугивающим фактором для некоторых айтишников. Тем не менее, платформа живее всех живых и над ее развитием работает изрядное количество людей, коль скоро на ней базируется семейство проектов фонда Викимедиа.
Сама по себе вики довольно скупа на возможности, но для нее написано огромное множество расширений. Большая часть интересного функционала кроется именно в расширениях, так что изрядная часть статьи будет именно про них. И да, не могу не отметить, что есть специальная корпоративная версия Mediawiki — BlueSpice, которой я не пользовался, а потому не могу судить об ее адекватности.
QA включает в себя не только/не столько тестирование, сколько обеспечение качества в широком смысле. И среди прочих значений этого самого широкого смысла затесалась такая штука, как управление знаниями. По этой теме довольно много абстрактных статей и книг, повествующих о принципах Knowledge management, но на удивление мало конкретных рекомендаций и практически применимых идей, во всяком случае сколько-нибудь свежих. Это заставляет меня думать, что или все пользуются тем, что дают всем известные компании и радуются, или не пользуются ничем и страдают, или пилят свой тайный велосипед, о котором неловко рассказывать в приличной компании. Мне тоже неловко, но я расскажу.
Сперва про фишки самой mediaiwki
Прежде чем говоритиь о расширениях, стоит упомянуть о том, какие вообще особенности есть у самой mediawiki. Если на вашем счету тысяча правок на википедии, то вряд ли вы узнаете что-то новое из этой части, ее можно смело пропустить.
Первая и одна из самых ощутимых плюшек — категории. Страницы можно добавлять в категории, сами категории можно добавлять в категории. В отличие от файловой структуры (забудем про симлинки), страница/категория может находиться сразу в нескольких категориях. Использование категорий препятствует росту хаоса с ростом числа статей. Особенно если просматривать периодически списки некатегоризованных статей и некатегоризованных категорий
Пространства имен. Идеология вики гласит о том, что все является страницей (даже категория или изображение). Для того, чтобы отделять страницы разных типов, была добавлена идея пространств имен. При желании можно добавлять свои пространства имен, чтобы отделять знания разного типа (к примеру, отдельные пространства имен для информации о продукте, утилит, гайдов, описания процессов, иной служебной информации).
Также вики поддерживает шаблоны — вики-страницы, которые впоследствии можно включать в другие страницы. Шаблоны поддерживают работу с параметрами, что превращает их в нечто большее, чем простые текстовые вставки: при желании на языке шаблонов можно написать несложный скрипт. К слову, говорят, что язык шаблонов может быть полным по Тьюрингу.
В дополнение к шаблонам расширение Scribunto позволяет использовать lua-модули внутри вики. Модули вместе с шаблонами позволяют реализовать многие вещи, даже не обращаясь к написанию своих расширений.
К примеру, навигационные таблицы построены на базе этого дуэта. Навигационная таблица — это, например, вот эта штука, которую обычно можно увидеть внизу страницы:
Они хоть и не являются стандартным функционалом, но зарекомендовали себя как удобное средство навигации и наведения порядка и используются сейчас почти повсеместно.
Не могу не упомянуть Mediawiki:Common.css и Mediawiki:Common.js файлы, позволяющие добавить небольшую кастомизацию вики — для больших вещей лучше использовать расширения.
Редакторы
Одна из самых важных частей вики — это редактор. Крайне сложно внедрить вики, если в ней нет визуального редактора, потому как учить вики-разметку согласится только очень инициативный человек.
Visual Editor
Сравнительно свежее расширение — VisualEditor решает проблему с визуальным редактированием статей. У него есть свои косяки, но для большинства задач его хватает. Из самых заметных проблем — там не самая удобная вставка изображений.
Появление визуального редактора тесно свзяано с появлением Parsoid — сервиса конвертации между Mediawiki синтаксисом и html. Задача эта оказалась крайне нетривиальной в силу того, что mediawiki синтаксис развивался хаотично и не был строго определен. Подробнее можно почитать в прекрасном посте официального блога.
Среди расширений, интегрирующихся с VisualEditor, можно выделить Graph для редактирования графов, Math для редактирования математических формул и SyntaxHighlight для подсветки синтаксиса фрагментов кода.
WikiEditor
WikiEditor — простой редактор викитекста. Некоторые хитрые вещи все еще удобнее делать через редактор викитекста, в некоторых местах все еще не поддерживается визуальное редактирование. Как бы то ни было, WikiEditor облегчает работу с викитекстом, а еще его довольно просто кастомизировать.
Конфликты редактирования
Кто пользовался в прошлом Mediawiki, тот помнит, какой болью становилось каждое разрешение конфликтов редактирования.
TwoColConflict со включенным по умолчанию бета-режимом сильно упрощает решение проблемы. В случае возникновения конфликта можно посмотреть на те места, где имеет место конфликт, и выбрать нужную версию спорного фрагмента. Если обе версии не полны, то можно дополнить одну из них. Как-то так это выглядит в деле:
Можно попробовать самому на тестовой странице.
Формы для добавления однотипного контента
Расширение PageForms позволяет добавлять на вики однотипный контент при помощи форм. В своей практике я использовал формы для добавления на вики реестровых ключей, таблиц БД и других подобных типовых вещей.
Это расширение раскрывает свою мощь при использовании Semantic Mediawiki или его аналогов. Семантическая медиавики позволяет добавлять на страницу свойства страницы или объекты со своими свойствами. Задаются свойства примерно так (на примере страницы Германия):
[[Имеет столицу::Берлин]]Эти свойства и объекты после можно получить при помощи запроса ask или через api.
Из полученных свойств можно выводить таблицы, строить графики и делать много других крутых вещей. К примеру, в моем случае на основе таблиц, добавленных через формы, строятся простейшие схемы бд. При этом схему можно строить не для всего продукта, а для конкретной категории. И в схеме можно отразить помимо очевидных FK/PK связей еще и неявные связи, которые не увидеть стандартными средствами построения диаграмм.
Для реестровых ключей из тех же свойств вытаскивается ключевая информация для того, чтобы на ее основе можно было бы генерировать .reg файл с заданным значением.
Дерево категорий
PageForms поддерживает возможность добавления поля с деревом категорий, так что для добавления страницы в нужные категории будет достаточно только кликнуть по нужным чекбоксам.
С другой стороны, когда у нас уже есть разложенные по категориям статьи, их можно отобразить на любой странице в виде дерева:
Дерево грузится динамически, так что оно работает и для большого числа статей, и для зацикленных категорий, если такие вдруг кому-то нужны.
LDAP/AD авторизация
Расширение Ldap Authentication поддерживает авторизацию через домен, ограничение доступа для определнных групп и маппинг групп юзеров mediawiki на группы ldap. Можно настроить сразу несколько доменов. Довольно утомительная в вопросах настройки, но, к счастью, в интернетах есть очень даже неплохие инструкции.
Гранулярные права доступа
Вот тут все плохо. Если задача стоит в том, чтобы ограничить доступ неавторизованным пользователям, то это просто. Если среди этих пользователей нужно выделить отдельные группы с особыми правами доступа, то это сложно.
Есть много разных расширений, но они не решают фундаментальную проблему: mediawiki не была создана как CMS. Для поддержки прав доступ придется патчить код Mediawiki, маниакально добавляя
$title->userCan('read')во все, что не должно отдаваться без проверки прав. То же самое касается и всех расширений: для каждого добавленного расширения придется вручную добавлять все необходимые проверки.
Для себя я решил проблему самодельным расширением, построенном на идее из PermissionACL и пачки патчей для разных расширений и самой mediawiki. К счастью, мне не был нужен продвинутый ACL, хватило и примитивных проверок для нескольких групп.
Для поддержки того же самого для изображений придется завернуть обращения к файлам в Img_auth.php. А последний использует стример файлов от mediawiki, который не умеет отдавать partial content (на момент mediawiki 1.31), так что для поддержки воспроизведения видео придется приделывать другой стример файлов.
Поддержка видео
Поддержка видео не входит в стандартную поставку, но тривиально решается установкой расширения TimedMediaHandler. Обычный видеоплеер, ничего особого. Вставка видео на страницу абсолютно аналогична вставке изображения.
Поиск
Одна из раздражающих меня лично вещей в Confluence — это поиск. Стандартный поиск Mediawiki еще хуже, но к счастью есть сторонние расширения. Из поисковых расширений самые популярные — это CirrusSearch и SphinxSearch. Последним я никогда не пользовался, но с первым мне довелось познакомиться очень плотно, он же, кстати, используется и в проектах фонда викимедиа
CirrusSearch работает на базе elasticsearch, для работы расширения придется еще поставить промежуточный интерфейс — расширение Elastica.
CirrusSearch поддерживает безумное число параметров и довольно активно развивается. Например, меня очень порадовало, что в ветке 1.32 заработал поиск по CamelCase.
Еще один момент, который мне приглянулся — это возможность добавить словарь синонимов. Словарь хорошо работает с устоявшимся внутренним корпоративным жаргоном, аббревиатурами, типичными опечатками или различными транслитерациями. Но словарь нужно сперва написать, что может оказаться не самой простой задачей. Если не затачивать словарь под конкретную компанию, можно попробовать существующие словари в духе WordNet, но не факт что они подойдут лично вам.
Расширение не поддерживает добавление синонимов на уровне конфига LocalSettings, но это несложно решить правкой кода расширения — см AnalysisConfigBuilder.php и инструкцию по настройке синонимов elasticsearch.
При желании можно добавить на главную страницу поисковую строку через расширение InputBox, после чего к нему можно прикрутить автодополнение по инструкции.
Кстати, AdvancedSearch поможет привести в порядок вид страницы поиска, с ним она не будет выглядит как жертва любителя чекбоксов.
Аналитика
Звучит смешно, конечно, но аналитика крайне полезна даже для внутренней базы знаний, которую посещает в месяц сотня человек. Она позволяет понять, как пользователи взаимодействуют с интерфейсом, что ищут, что читают, чем пользуются. Если в планах есть дальнейшее развитие базы знаний, статистика будет просто бесценной.
Для интранета есть крайне достойное расширение Matomo (ex Piwik). Соответствующее расширение для интеграции — MatomoAnalytics.
Matomo собирает статистику по поисковым запросам, источникам трафика, загрузкам, переходам по ссылкам (можно посмотреть частоту перехода по ссылкам с наложением на саму страницу) и множество других метрик. Статистику можно собирать как с привязкой к конкретным пользователям, так и анонимную, чтобы не смущать никого.
Прочее
Помимо перечисленного есть немало расширений, которые просто облегчают жизнь. Например, GuidedTour для обучения новичков основам работы с интерфейсами, Popups для предпросмотра статей по наведении на ссылку, MultimediaViewer для более кофмортного просмотра полноразмерных изображений и многое-многое другое.
Что в итоге?
Перечисленный джентельменский набор расширений покрывает значительную часть потребностей при создании базы знаний, но не все. Mediawiki не годится в качестве универсальной единой базы знаний. Но в качестве универсальной системы также плохо справляются и все остальные — sharepoint, confluence, олдскульные папочки outlook, поиск по которым занимает полчаса и т.д. Mediawiki же на их фоне отличается своими возможностями кастомизации и отличной масштабируемостью.
В противовес всем перечисленным плюсам mediawiki постоянно требует допиливания напильником функционала под нужды конкретной компании, так что ее администратору стоит быть морально готовым разбираться в php, js и lua коде. Но если это не пугает и если вы согласны разделять работу с офисными документами и работу с вики статьями по разным платформам, mediawiki в качестве базы знаний может оказаться весьма недурной затеей.
Комментарии (63)
dempfi
26.01.2019 10:07ТС, обратите внимание на notion — там из коробки есть почти все что вы описали + лучше права доступа и куча классных функций именно для командной работы. Ну и вообще инструмент создавался для решения этой самой проблемы обмена знаниями (включая типизированные) в коллективе и отлично ее решает.
Единственное чего ещё нет — API для расширений.
skymal4ik
26.01.2019 10:56Спасибо за ссылку, выглядит интересно!
К сожалению, насколько я понял, не self-hosted и хотят денег за продвинутые фишки.
Сам использую dokuwiki на своей vps-ке, но не очень нравится взаимодействие с ней, думаю перейти на confluence. Он хоть и не бесплатен, но хотя бы self-hosted.
Ps да, я люблю чтобы всё хостилось у меня. И никто не мог мне ничего отключить или поменять условия или поднять цену :)
HSerg
26.01.2019 15:14Не забудьте погонять Confluence на предмет требований к железу, а то он весьма прожорливый (особенно после dokuwiki).
sentyaev
26.01.2019 16:21-1не self-hosted
Почему интересует именно self-hosted решение? В статье я не увидел такого требования, да и в наше время гораздо дешевле платить небольшие деньги сервису, чем держать что-либо у себя (это ведь и за сервера платить, и за администрирование).skymal4ik
26.01.2019 16:29+2Этого требования и не было в статье, вы правы. Это уже я делюсь своими мыслями о Notion.
Выделенный сервер у меня уже есть и поднять еще одну виртуалку — не сложно. Так что это не было бы проблемой, если бы notion был self-hosted. Про причину я уже писал выше:
Ps да, я люблю чтобы всё хостилось у меня. И никто не мог мне ничего отключить или поменять условия или поднять цену :)
Renaissance
26.01.2019 10:41Я бы в джентльменский набор расширений добавил бы еще интеграцию с draw.io, без этой штуки очень сложно жить.
Ну и из личных наблюдений: вики это классно и хорошо, но лично у меня руки опустились уже, потому как пишешь-пишешь туда, а толку нет. Все равно потом звонят и спрашивают о том, что уже описано, мотивируя «мне лень читать, ты лучше объясни».
Как с этим бороться, не знаю. Нельзя заставить человека читать вики, если он не хочет этого делать.usego
26.01.2019 10:51+1Отвечать исключительно ссылками на вики не вариант? Даже с начальством прокатывает.
Renaissance
26.01.2019 12:01Отвечать по телефону ссылками? Это как? Или имеется ввиду вместо ответа просто ссылку в почту высылать? Аргумент «мне лень читать, ты лучше объясни» все равно не перебить этим…
В почту и чаты стараюсь отвечать ссылками, если предмет уже был описан.usego
26.01.2019 12:50>Аргумент «мне лень читать, ты лучше объясни
Такое решается административными мерами. Тут уж выбирать — или работать самому, или работать за других.
dempfi
26.01.2019 16:43+1В одной прошлой компании где я работал я решал эту же проблему. Компания была удалённая и большая — вся коммуникация в slack. Решение само напросилось: каждый раз когда кто-то задавал вопрос в чатах, бот находимо подходящий ответ в базе знаний и постил в чат. Если информации не было, и кто-то давал ответ в чате, то одной командой можно было добавить пару вопрос/ответ в базу для следующих поисков.
Штукой этой было реально удобно пользоваться — никуда из слэка выходить не нужно было и месяца через два люди вообще сами перестали спрашивать в группах а спрашивали бота напрямую.
vassabi
26.01.2019 23:09о, круто!
А вот это — просто бжественно:
Если информации не было, и кто-то давал ответ в чате, то одной командой можно было добавить пару вопрос/ответ в базу для следующих поисков.
Если не секрет — на чем бот был написан?dempfi
26.01.2019 23:28На TypeScript и nodejs. Я тогда создал удобный модульный фреймворк для написания этого бота (да и кучи других ботов для внутренних нужд компании). Его можно посмотреть у меня в гитхабе https://github.com/dempfi/xene. Для распознавания вопросов и поиска ответа использовал https://js.tensorflow.org.
В проекте есть мой заброшенный PR в котором можно подсмотреть простую распозновалку с нейронкой — хотел добавить в стандартную поставку фреймворка.
Только предупреждаю: я фреймворк давно не обновлял. Парни из моей команды его форкнули и продолжают поддерживать но уже внутри компании. Не в OSS из-за чисто юридической подоплёки — форк поддерживают в рабочее время, а все что пишется в рабочее время принадлежит компании.
t38c3j
26.01.2019 10:47Мы в одно время начали использовать gitbook для вики но сейчас ищем куда можно переехать, компания растет и стало не хватать уже функционала того что есть но редактирование, поиск, аналитика, история правок нам безумно в нём нравится.
conopus
26.01.2019 11:33+1Почему не DokuWiki, которая ориентирована на тех. документацию? Открытое API, 1200+ плагинов и шаблонов на все случаи жизни. «Из коробки» работающий поиск, авторизация через NTLM, нетребовательность к хостингу (нужен только PHP, обойдется даже без SQL-сервер). Например, некоторое время хостил свою wiki на домашнем NAS. Кроме того, что MediaWiki более известна и рассчитана на высокие нагрузки, — других преимуществ не вижу.
Coob Автор
26.01.2019 13:51Неоднократно слышал о нем, но не пробовал в деле. На первый взгляд смутило отсутствие визуального редактора (CKGEdit — это несколько другое). Но перечисленные вами вещи звучат здорово. Судя по тому, что вижу в комментах, много кто пользуется ею.
Кстати, у вас не было опыта работы dokuwiki с большим числом статей, как она ведет себя на условных 5-10 тысячах страниц?
На данный момент у меня порядка 6000 страниц, так что приходится привередничать и смотреть не перфоманс и общую масштабируемость тех или иных решени. Уже неоднократно приходилось отказываться от тех или иных расширений и писать их аналоги из соображений отвратительного быстродействия. Любопытно, как с этим в dokuwiki.Tsvetik
26.01.2019 14:03+1У меня в wiki около 3000 страниц. Хостится все на ноутбуке с Asus eee pc 1021 с процессором atom и 2 Гб памяти.
Правда, нагрузи никакой.Coob Автор
26.01.2019 14:20Спасибо за ответ, будет интересно поковырять dokuwiki на предмет возможностей.
В моем случае порядка 300-400 юзеров разной степени активности, нагрузка в рабочие часы довольно ощутимая и не все удается решить простым добавлением ресурсов. Не википедия, но и мириться с загрузкой хитрых визуализаций по несколько минут не хочется, приходится выкручиваться.conopus
26.01.2019 15:12+1У меня высокой нагрузки не было. Вот здесь человек задается вопросами производительности DokuWiki при индксировании. Но там речь о 200К страниц.
nikolay_karelin
26.01.2019 17:30+1Сталкивался с падением производительности на некоторых расширениях dokuwiki, название не помню, например, в расширении, которое дерево страниц выводит слева от основного текста.
Tsvetik
26.01.2019 11:36Я некоторое время назад прошерстил довольно много wiki движков и остановился на dokuwiki. Из-за его легковесности и простоты бэкапов и развертывания. Но он не идеален.
Самое главное, чего не хватает у всех wiki* — это семантических плагинов.
Это расширение понятия категорий. Каждой статье можно добавить неограниченное количество параметров различных типов. А потом по этим параметрам делать выборки, фильтровать и представлять в виде списков и таблиц, экспортирвоать в удобные форматы.
Для mediawiki есть плагин semantic-wiki. Для dokuwiki есть плагины типа strata, data.
К сожаление ни одна из известных мне wiki не поддерживает геоданные в качестве параметров.Coob Автор
26.01.2019 13:57Семантические поя могуь быть любыми, в том числе и геоданными. Как пример — Extension:Maps .
Правда, не уверен, подходят ли в вашем случае существующие решения. Если не секрет, какая задача потребовала хранения геоданных?Tsvetik
26.01.2019 14:01Extension:Maps умеет хранить только точки в виде их координат. Это, конечно, хорошо, но хотелось бы хранить еще и линии и полигоны.
Я веду небольшой сайт, посвященный горным перевалам Тянь-Шаня. Перевалы их параметры и фотографии хранятся в DokuWiki. С другой стороны хребтовка, на которой эти перевалы нанесены сделана в QGIS, а параметры хранятся в гео-базе данных.
Получается два совершенно разных хранилища, которые фиг синхронизируешь.
сайт: http:/pereval.cc
Хребтовка: nakarte.me/#m=13/41.93874/77.55507&l=O/Mt
Coob Автор
26.01.2019 14:08Линии и полигоны, вроде, тоже можно выводить при помощи параметров lines и Polygons:
Extension:Maps/Displaying_maps
За счет поддержи «под-объектов» и иже с ними в семантической медиавики можно хранить сложные данные.Tsvetik
26.01.2019 14:21Это немного не то. Тут полигоны и линии собираются из имеющихся точечных объектов.
Tiendil
26.01.2019 11:47Рассматриваю mediawiki как базу для организации портала по своей игре, но хочу чтобы это была не только типичная энциклопедия, но и источник данных об объектах игрового мира. Например, чтобы можно было отредактировать свойства монстра и они отразились в игре (или, например, добавить нового монстра). Поскольку проект у меня открытый, это выглядит очень интересным решением.
Возникло несколько вопросов, с которыми пока не разобрался.
1. Возможно ли организовать в медиавики систему веток страниц как в git-e?
Поскольку сама игра обновляется всё-таки по версиям и при разработке новой версии может потребоваться существенно менять контент (как формализованный так и просто текст на страницах с описанием мира). Обычный способ, когда на одной странице пишется что-то вроде «для версии 2.4 у нас справедливо это, а в 2.5 уже вот это» плохо подходит.
2. Наткнулся на www.wikidata.org но не до конца понял какую именно роль wikidata должна играть в инфраструктуре wikimedia. Вы пробовали с ней работать?
Выглядит так, что её можно использовать как чистую базу знаний (для редактирования и поиска), а сами страницы генерировать своим кодом на основе запросов к ней. Но из того, что я пока увидел в её документации, она не рассчитана на работу с большими текстами.Tsvetik
26.01.2019 11:51Из того, что мне попадалось, для такого сайта надо поставить
mediawiki + sematicwiki, либо dokuwiki + data plugin
Но у них у всех свой специфический формат записи свойств в БД.
Еще как вариант можно использовать сайтогенераторы типа Jekyll или Hugo. Там на скриптах можно сделать вообще любое взаимодействие с БД, а хостить на гитхабе. Но придется много всего скриптить руками
Coob Автор
26.01.2019 14:02Системы веток там нет, только линейная история правок. Этого действительно не хватает.
1.
Можно имитировать ветки при помощи подстраниц, но не уверен, насколько это удобно будет. Гранулярный мерж между страницами будет невозможно сделать автоматически, только переносить целиком контент страницы из одной подстраницы в другую.
2.
С викидата я не работал, но базовая идея там та же, что у semantic mediawiki, cargo и иже с ними — дать возможность хранить структурированные и осмысленные данные, чтобы потом с ними можно было работать при помощи апи и вики-запросов.
Tiendil
27.01.2019 12:29С викидата я не работал, но базовая идея там та же, что у semantic mediawiki, cargo и иже с ними
Я вот, кстати, никак не пойму, зачем столько дублирования функциональности? Вроде бы ж это всё в рамках одного проекта (вики) делается? Или нет?Coob Автор
27.01.2019 12:47+1Расширения частоп млят независимые разработчики в своих нуждах. Некоторые потом используют в проектах фонда викимедиа, некоторые нет. Викидата появилась, как я понимаю, из тех соображений, что википедия не может себе позволить на несколько дней уйти в ридонли для обновления БД. Им пришлось писать свой хитрый способ решения проблемы.
ganqqwerty
27.01.2019 16:36+1Это не единственная причина, там еще довольно мощное Semantic Web лобби действовало, плюс викидата — это все-таки именно база данных, а не куча текста.
Tiendil
28.01.2019 10:23мощное Semantic Web лобби действовало
А сейчас не действует?
Darth_Biomech
26.01.2019 19:31+1Интересная идея. Но не приведет ли это к возможности злоупотребления? Отредактировать статы оружия чтобы оно выдавало овер 9000 повреждений, к примеру.
b1ora
26.01.2019 12:02Лично использую DokuWiki. Описал всю ит инфраструктуру. Всё сгруппировал, все удобно. Но ее удобно редактировать не большой группой человек. Остальным только читать.
sha4
27.01.2019 14:47Поясните пожалуйста, почему с dokuwiki удобнее работать только небольшой группой? (тоже делаем базу знаний)
mwambanatanga
26.01.2019 15:55+2О, а я как раз пилю под dokuwiki аналог mediawiki-шаблонов.
ganqqwerty
26.01.2019 23:16+1ссылочку?
Vanger
27.01.2019 11:39пожалуй да, поддержу
mwambanatanga
27.01.2019 11:54+1Надеюсь, НЛО не сочтёт за рекламу: https://www.dokuwiki.org/plugin:wst
- Форматирование работает плохо — шаблон выделяется как отдельный абзац.
- Функций (if, ifexist, switch и пр.) нет.
- Переменных (CURRENTYEAR и пр.) нет.
reinvent
26.01.2019 17:57+1Мне больше приглянулся zoho connect. Confluence перегружен не нужными для базы знаний функциями. У Zoho, конечно, сыроватый продукт, но они его активно допиливают.
Darth_Biomech
26.01.2019 19:03+2Театр одного актера, конечно, да ещё и не про IT, но мне в организации своих заметок, информации и прочих данных по своему проекту mediawiki сервер обеспечил незаменимую помощь. Возможность организации всей своей информации в нелинейную структуру c перекрестной навигацией и визуальным оформлением существенно упрощает работу и общую оценку контента — где не хватает информации, где требуется ещё один раздел, и так далее.
UksusoFF
26.01.2019 21:28Первая и одна из самых ощутимых плюшек — категории.
Только вот не всегда удобно пачкой переносить/переименовывать/удалять их. ИМХО лучше сразу ставить шаблоны которые уже будут включать статьи в категории.
Coob Автор
27.01.2019 00:25ReplaceText спасает, но переименование и удаление категорий действительно сделано не особенно удобно.
UksusoFF
27.01.2019 08:56Да, но тогда на всех страницах отобразятся изменения. Возможно не особо критично для корпоративных вики которые ведут 1-2 человека. Но не очень хорошо если кто-то еще следит за изменениями.
Coob Автор
27.01.2019 12:48Мне помогает использование ботов, их удобно фильтровать при просмотре истории правок.
UksusoFF
27.01.2019 13:24Расскажите про ботов подробнее? Я видел только тех что Википедии используются и как их настраивать на сторонних вики не особо понятно.
Coob Автор
27.01.2019 13:38+2На самом деле бот с точки зрения вики — это просто юзер: www.mediawiki.org/wiki/Manual:Bots
Можно задать юзера, о имени которого будут делаться правки в replaceText через параметр
$wgReplaceTextUser = "MyReplaceTextBot";
в LocalSettings.php
Т.е. достаточно создать юзера, сделать его ботом и назначить его как автора всех правок, проведенных через replaceText.
Другие массовые скрипты обычно тоже так или иначе поддерживают осуществление правок от имени ботов.UksusoFF
27.01.2019 20:30Про это не подумал. Так действительно удобнее.
Но я имел ввиду работу и настройку вот этих ребят:
https://meta.wikimedia.org/wiki/InternetArchiveBot
https://github.com/cyberpower678/Cyberbot_II
ganqqwerty
26.01.2019 23:15+1Мне кажется, что так сказать корпоративную медиавику очень тормозит применение в википедии — например, желание быть совместимыми со всеми-всеми браузерами.
Ну и как ветеран SMW, реквестирую статьи про семейство семантических расширений и расширений, используемых в Wikidata.Coob Автор
27.01.2019 00:29Отчасти соглашусь. Самому приходится допиливать расширения для того, чтобы повысить удобство в ущерб тем вещам, которые некритичны для внутреннего портала. С другой стороны, масштабируемость и еще раз масштабируемость.
По семантике — я еще не успел поработать с wikidata, но пожелание учту.
ganqqwerty
26.01.2019 23:17+1Вопрос автору — на ваш взгляд, денежное ли это дело — быть викоидом, вики-консультантом и разработчиком? Как хорошо это продается в 2К19? Я вот пять лет назад перешел из вики-ниндзей в обычный фронтенд, но постоянно оглядываюсь назад.
Coob Автор
27.01.2019 00:39Те, кто хотят потратить деньги, обычно пользуются более безопасными для себя решениями от крупных компаний. Обычно мало кого парит, что в системе нет нужных конкретно им плюшек, по крайней мере так мне показалось из своего опыта.
Медиавики ставят только те, кто хочет или решить свою проблему бесплатно, или те, кому это действительно интересно. И в том, и в другом случае это не особенно приносит денег сторонним вики-разработчикам.
Впрочем, я могу ошибаться: в конце концов база знаний — это не основная моя деятельность, а скорее пет-проект с пользой для компании. Я не пробовал всерьез зарабатывать на этом деньги.
Кстати, а можете поделиться своим опытом бытия викимастером в прошлом? Как вы искали заказы и чем занимались? Если не секрет, конечно.
gnomeby
27.01.2019 12:06+1В своё время, обалдев от того, что HR`ы информацию о собеседованиях заносят XLS файлы и друг с другом ими обмениваются, собрал на основе MediaWiki и плагинов им простенькую систему для одновременной совместной работы: github.com/gnomeby/hrwiki-ru
При этом допрограммировать пришлось 0 строк, только настройками обошёлся.
Alex_Arkhipov
27.01.2019 18:36+1У нас в качестве базы знаний используется Jive. Нечто среднее между социальной сетью, форумом, Google Docs, поисковиком, иерархическим хранилищем, менеджером проектов. Из плюсов позволяет легко добавлять файлы MS Office и синхронизировать их с локальным компьютером, осуществлять совместное редактирование несколькими пользователями, что в корпоративной среде удобно. Также позволяет вести профили компетенций пользователей — можно найти не только информацию, но и человека, которой в данной теме хорошо разбирается.
Coob Автор
27.01.2019 18:47Профили компетенций звучат очень интересно. Пока не нашел для себя решения этой проблемы — просто веду табличку фича/человек, но это не очень удобно.
Godless
27.01.2019 22:14Безусловно дело привычки, но мне уж очень нравится синтаксис вики redmine. С картинками почти везде какие-то неудобства. Перепробовал штук 20 разных. Какие то сразу сносил. Из запомнившихся — dokuwiki, mediawiki. первая оч легкая и простая. Вторая как комбайн.
пользуем на ворке redmine. Но не только как вики.
ЗЫ: Кто нить знает рабочий standalone аналог с textile?
surly
28.01.2019 20:05+1Пробовал однажды (лет 10 назад) для ИТшной базы знаний внедрить именно MediaWiki. Столкнулся с тем, что эта система плохо приспособлена к разграничению доступа. Может сейчас есть более удобные средства, но в то время права можно было назначать только на пространства имён. Каждую ссылку приходилось оформлять в виде [[Пространство: Название статьи|Название статьи]], чтобы скрыть пространство имён — иначе ссылка выглядела уродством. Это в итоге и меня самого выбесило, и коллег подсадить на ведение системы не удалось.
Если бы внедрял подобную систему сейчас, в первую очередь смотрел бы на что-нибудь подобное FosWiki.
md_pitbul
29.01.2019 12:39Как очень хорошую альтернативу, могу предложить посмотреть в сторону mindtouch (deki-wiki в детстве)
К сожалению, версия mindtouch core, уже не поддерживается разработчиком, это бесплатная версия и вроде все о чем вы говорили есть сразу в коробке. это self-hosted решение.
ovsale
тоже считаю идею иерархических категорий (тегов) лучшим способом организовать базу знаний / хранилище файлов. рекомендую ознакомиться со следующим подходом: файловый менеджер на основе иерархических тегов. на мой взгляд там наиболее красиво реализована работа с иерархическими категориями.