CMS
Website development
Crowdsourcing
Comments 63
0
Первая и одна из самых ощутимых плюшек — категории. Страницы можно добавлять в категории, сами категории можно добавлять в категории. В отличие от файловой структуры (забудем про симлинки), страница/категория может находиться сразу в нескольких категориях. Использование категорий препятствует росту хаоса с ростом числа статей.

тоже считаю идею иерархических категорий (тегов) лучшим способом организовать базу знаний / хранилище фа��лов. рекомендую ознакомиться со следующим подходом: файловый менеджер на основе иерархических тегов. на мой взгляд там наиболее красиво реализована работа с иерархическими категориями.
0

ТС, обратите внимание на notion — там из коробки есть почти все что вы описали + лучше права доступа и куча классных функций именно для командной работы. Ну и вообще инструмент создавался для решения этой самой проблемы обмена знаниями (включая типизированные) в коллективе и отлично ее решает.


Единственное чего ещё нет — API для расширений.

+1
Спасибо за ссылку, выглядит интересно!

К сожалению, насколько я понял, не self-hosted и хотят денег за продвинутые фишки.

Сам использую dokuwiki на своей vps-ке, но не очень нравится взаимодействие с ней, думаю перейти на confluence. Он хоть и не бесплатен, но хотя бы self-hosted.

Ps да, я люблю чтобы всё хостилось у меня. И никто не мог мне ничего отключить или поменять условия или поднять цену :)
0
Не забудьте погонять Confluence на предмет требований к железу, а то он весьма прожорливый (особенно после dokuwiki).
-1
не self-hosted

Почему интересует именно self-hosted решение? В статье я не увидел такого требования, да и в наше время гораздо дешевле платить небольшие деньги сервису, чем держать что-либо у себя (это ведь и за сервера платить, и за администрирование).
+2

Этого требования и не было в статье, вы правы. Это уже я делюсь своими мыслями о Notion.


Выделенный сервер у меня уже есть и поднять еще одну виртуалку — не сложно. Так что это не было бы проблемой, если бы notion был self-hosted. Про причину я уже писал выше:


Ps да, я люблю чтобы всё хостилось у меня. И никто не мог мне ничего отключить или поменять условия или поднять цену :)
+4
Я бы в джентльменский набор расширений добавил бы еще интеграцию с draw.io, без этой штуки очень сложно жить.

Ну и из личных наблюдений: вики это классно и хорошо, но лично у меня руки опустились уже, потому как пишешь-пишешь туда, а толку нет. Все равно потом звонят и спрашивают о том, что уже описано, мотивируя «мне лень читать, ты лучше объясни».

Как с этим бороться, не знаю. Нельзя заставить человека читать вики, если он не хочет этого делать.
+2
Отвечать исключительно ссылками на вики не вариант? Даже с начальством прокатывает.
0
Отвечать по телефону ссылками? Это как? Или имеется ввиду вместо ответа просто ссылку в почту высылать? Аргумент «мне лень читать, ты лучше объясни» все равно не перебить этим…

В почту и чаты стараюсь отвечать ссылками, если предмет уже был описан.
+1
>Аргумент «мне лень читать, ты лучше объясни

Такое решается административными мерами. Тут уж выбирать — или работать самому, или работать за других.
+1

В одной прошлой компании где я работал я решал эту же проблему. Компания была удалённая и большая — вся коммуникация в slack. Решение само напросилось: каждый раз когда кто-то задавал вопрос в чатах, бот находимо подходящий ответ в базе знаний и постил в чат. Если информации не было, и кто-то давал ответ в чате, то одной командой можно было добавить пару вопрос/ответ в базу для следующих поисков.


Штукой этой было реально удобно пользоваться — никуда из слэка выходить не нужно было и месяца через два люди вообще сами перестали спрашивать в группах а спрашивали бота напрямую.

0
о, круто!
А вот это — просто бжественно:
Если информации не было, и кто-то давал ответ в чате, то одной командой можно было добавить пару вопрос/ответ в базу для следующих поисков.

Если не секрет — на чем бот был написан?
0

На TypeScript и nodejs. Я тогда создал удобный модульный фреймворк для написания этого бота (да и кучи других ботов для внутренних нужд компании). Его можно посмотреть у меня в гитхабе https://github.com/dempfi/xene. Для распознавания вопросов и поиска ответа использовал https://js.tensorflow.org.


В проекте есть мой заброшенный PR в котором можно подсмотреть простую распозновалку с нейронкой — хотел добавить в стандартную поставку фреймворка.


Только предупреждаю: я фреймворк давно не обновлял. Парни из моей команды его форкнули и продолжают поддерживать но уже внутри компании. Не в OSS из-за чисто юридической подоплёки — форк поддерживают в рабочее время, а все что пишется в рабочее время принадлежит компании.

0
Мы в одно время начали использовать gitbook для вики но сейчас ищем куда можно переехать, компания растет и стало не хватать уже функционала того что есть но редактирование, поиск, аналитика, история правок нам безумно в нём нравится.
+3
Почему не DokuWiki, которая ориентирована на тех. документацию? Открытое API, 1200+ плагинов и шаблонов на все случаи жизни. «Из коробки» работающий поиск, авторизация через NTLM, нетребовательность к хостингу (нужен только PHP, обойдется даже без SQL-сервер). Например, некоторое время хостил свою wiki на домашнем NAS. Кроме того, что MediaWiki более известна и рассчитана на высокие нагрузки, — других преимуществ не вижу.
+1
Неоднократно слышал о нем, но не пробовал в деле. На первый взгляд смутило отсутствие визуального редактора (CKGEdit — это несколько другое). Но перечисленные вами вещи звучат здорово. Судя по тому, что вижу в комментах, много кто пользуется ею.

Кстати, у вас не было опыта работы dokuwiki с большим числом статей, как она ведет себя на условных 5-10 тысячах страниц?

На данный момент у меня порядка 6000 страниц, так что приходится привередничать и смотреть не перфоманс и общую масштабируемость тех или иных решени. Уже неоднократно приходилось отказываться от тех или иных расширений и писать их аналоги из соображений отвратительного быстродействия. Любопытно, как с этим в dokuwiki.
+1
У меня в wiki около 3000 страниц. Хостится все на ноутбуке с Asus eee pc 1021 с процессором atom и 2 Гб памяти.
Правда, нагрузи никакой.
+1
Спасибо за ответ, будет интересно поковырять dokuwiki на предмет возможностей.
В моем случае порядка 300-400 юзеров разной степени активности, нагрузка в рабочие часы довольно ощутимая и не все удается решить простым добавлением ресурсов. Не википедия, но и мириться с загрузкой хитрых визуализаций по несколько минут не хочется, приходится выкручиваться.
+1

Сталкивался с падением производительности на некоторых расширениях dokuwiki, название не помню, например, в расширении, которое дерево страниц выводит слева от основного текста.

0
Я некоторое время назад прошерстил довольно много wiki движков и остановился на dokuwiki. Из-за его легковесности и простоты бэкапов и развертывания. Но он не идеален.

Самое главное, чего не хватает у всех wiki* — это семантических плагинов.
Это расширение понятия категорий. Каждой статье можно добавить неограниченное количество параметров различных типов. А потом по этим параметрам делать выборки, фильтровать и представлять в виде списков и таблиц, экспортирвоать в удобные форматы.

Для mediawiki есть плагин semantic-wiki. Для dokuwiki есть плагины типа strata, data.

К сожаление ни одна из известных мне wiki не поддерживает геоданные в качестве параметров.
+1
Семантические поя могуь быть любыми, в том числе и геоданными. Как пример — Extension:Maps .

Правда, не уверен, подходят ли в вашем случае существующие решения. Если не секрет, какая задача потребовала хранения геоданных?
0
Extension:Maps умеет хранить только точки в виде их координат. Это, конечно, хорошо, но хотелось бы хранить еще и линии и полигоны.

Я веду небольшой сайт, посвященный горным перевалам Тянь-Шаня. Перевалы их параметры и фотографии хранятся в DokuWiki. С другой стороны хребтовка, на которой эти перевалы нанесены сделана в QGIS, а параметры хранятся в гео-базе данных.

Получается два совершенно разных хранилища, которые фиг синхронизируешь.

сайт: http:/pereval.cc
Хребтовка: nakarte.me/#m=13/41.93874/77.55507&l=O/Mt

+1
Линии и полигоны, вроде, тоже можно выводить при помощи параметров lines и Polygons:

Extension:Maps/Displaying_maps

За счет поддержи «под-объектов» и иже с ними в семантической медиавики можно хранить сложные данные.
0
Это немного не то. Тут полигоны и линии собираются из имеющихся точечных объектов.
+2
Рассматриваю mediawiki как базу для организации портала по своей игре, но хочу чтобы это была не только типичная энциклопедия, но и источник данных об объектах игрового мира. Например, чтобы можно было отредактировать свойства монстра и они отразились в игре (или, например, добавить нового монстра). Поскольку проект у меня открытый, это выглядит очень интересным решением.

Возникло несколько вопросов, с которыми пока не разобрался.

1. Возможно ли организовать в медиавики систему веток страниц как в git-e?

Поскольку сама игра обновляется всё-таки по версиям и при разработке новой версии может потребоваться существенно менять контент (как формализованный так и просто текст на страницах с описанием мира). Обычный способ, когда на одной странице пишется что-то вроде «для версии 2.4 у нас справедливо это, а в 2.5 уже вот это» плохо подходит.

2. Наткнулся на www.wikidata.org но не до конца понял какую именно роль wikidata должна играть в инфраструктуре wikimedia. Вы пробовали с ней работать?

Выглядит так, что её можно использовать как чистую базу знаний (для редактирования и поиска), а сами страницы генерировать своим кодом на основе запросов к ней. Но из того, что я пока увидел в её документации, она не рассчитана на работу с большими текстами.
+1
Из того, что мне попадалось, для такого сайта надо поставить
mediawiki + sematicwiki, либо dokuwiki + data plugin
Но у них у всех свой специфический формат записи свойств в БД.

Еще как вариант можно использовать сайтогенераторы типа Jekyll или Hugo. Там на скриптах можно сделать вообще любое взаимодействие с БД, а хостить на гитхабе. Но придется много всего скриптить руками
+1
Системы веток там нет, только линейная история правок. Этого действительно не хватает.

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

2.
С викидата я не работал, но базовая идея там та же, что у semantic mediawiki, cargo и иже с ними — дать возможность хранить структурированные и осмысленные данные, чтобы потом с ними можно было работать при помощи апи и вики-запросов.

0
С викидата я не работал, но базовая идея там та же, что у semantic mediawiki, cargo и иже с ними

Я вот, кстати, никак не пойму, зачем столько дублирования функциональности? Вроде бы ж это всё в рамках одного проекта (вики) делается? Или нет?
+1

Расширения частоп млят независимые разработчики в своих нуждах. Некоторые потом используют в проектах фонда викимедиа, некоторые нет. Викидата появилась, как я понимаю, из тех соображений, что википедия не может себе позволить на несколько дней уйти в ридонли для обновления БД. Им пришлось писать свой хитрый способ решения проблемы.

+1
Это не единственная причина, там еще довольно мощное Semantic Web лобби действовало, плюс викидата — это все-таки именно база данных, а не куча текста.
0
Вяленько действует, но самые мощные ребята разошлись по мегакорпорациям
+1
Интересная идея. Но не приведет ли это к возможности злоупотребления? Отредактировать статы оружия чтобы оно выдавало овер 9000 повреждений, к примеру.
0
Если правильно управлять правами пользователей, то не должно.
+1

Лично использую DokuWiki. Описал всю ит инфраструктуру. Всё сгруппировал, все удобно. Но ее удобно редактировать не большой группой человек. Остальным только читать.

UFO landed and left these words here
+1

Надеюсь, НЛО не сочтёт за рекламу: https://www.dokuwiki.org/plugin:wst


  • Форматирование работает плохо — шаблон выделяется как отдельный абзац.
  • Функций (if, ifexist, switch и пр.) нет.
  • Переменных (CURRENTYEAR и пр.) нет.
+1
Мне больше приглянулся zoho connect. Confluence перегружен не нужными для базы знаний функциями. У Zoho, конечно, сыроватый продукт, но они его активно допиливают.
+2
Театр одного актера, конечно, да ещё и не про IT, но мне в организации своих заметок, информации и прочих данных по своему проекту mediawiki сервер обеспечил незаменимую помощь. Возможность организации всей своей информации в нелинейную структуру c перекрестной навигацией и визуальным оформлением существенно упрощает работу и общую оценку контента — где не хватает информации, где требуется ещё один раздел, и так далее.
0
Первая и одна из самых ощутимых плюшек — категории.

Только вот не всегда удобно пачкой переносить/переименовывать/удалять их. ИМХО лучше сразу ставить шаблоны которые уже будут включать статьи в категории.

0
ReplaceText спасает, но переименование и удаление категорий действительно сделано не особенно удобно.
0

Да, но тогда на всех страницах отобразятся изменения. Возможно не особо критично для корпоративных вики которые ведут 1-2 человека. Но не очень хорошо если кто-то еще следит за изменениями.

0

Мне помогает использование ботов, их удобно фильтровать при просмотре истории правок.

0

Расскажите про ботов подробнее? Я видел только тех что Википедии используются и как их настраивать на сторонних вики не особо понятно.

+2
На самом деле бот с точки зрения вики — это просто юзер: www.mediawiki.org/wiki/Manual:Bots

Можно задать юзера, о имени которого будут делаться правки в replaceText через параметр
$wgReplaceTextUser = "MyReplaceTextBot";

в LocalSettings.php

Т.е. достаточно создать юзера, сделать его ботом и назначить его как автора всех правок, проведенных через replaceText.

Другие массовые скрипты обычно тоже так или иначе поддерживают осуществление правок от имени ботов.
+1
Мне кажется, что так сказать корпоративную медиавику очень тормозит применение в википедии — например, желание быть совместимыми со всеми-всеми браузерами.

Ну и как ветеран SMW, реквестирую статьи про семейство семантических расширений и расширений, используемых в Wikidata.
0
Отчасти соглашусь. Самому приходится допиливать расширения для того, чтобы повысить удобство в ущерб тем вещам, которые некритичны для внутреннего портала. С другой стороны, масштабируемость и еще раз масштабируемость.

По семантике — я еще не успел поработать с wikidata, но пожелание учту.
+1
Вопрос автору — на ваш взгляд, денежное ли это дело — быть викоидом, вики-консультантом и разработчиком? Как хорошо это продается в 2К19? Я вот пять лет назад перешел из вики-ниндзей в обычный фронтенд, но постоянно оглядываюсь назад.
0
Те, кто хотят потратить деньги, обычно пользуются более безопасными для себя решениями от крупных компаний. Обычно мало кого парит, что в системе нет нужных конкретно им плюшек, по крайней мере так мне показалось из своего опыта.

Медиавики ставят только те, кто хочет или решить свою проблему бесплатно, или те, кому это действительно интересно. И в том, и в другом случае это не особенно приносит денег сторонним вики-разработчикам.

Впрочем, я могу ошибаться: в конце концов база знаний — это не основная моя деятельность, а скорее пет-проект с пользой для компании. Я не пробовал всерьез зарабатывать на этом деньги.

Кстати, а можете поделиться своим опытом бытия викимастером в прошлом? Как вы искали заказы и чем занимались? Если не секрет, конечно.
+1
В своё время, обалдев от того, что HR`ы информацию о собеседованиях заносят XLS файлы и друг с другом ими обмениваются, собрал на основе MediaWiki и плагинов им простенькую систему для одновременной совместной работы: github.com/gnomeby/hrwiki-ru
При этом допрограммировать пришлось 0 строк, только настройками обошёлся.
+1
У нас в качестве базы знаний используется Jive. Нечто среднее между социальной сетью, форумом, Google Docs, поисковиком, иерархическим хранили��ем, менеджером проектов. Из плюсов позволяет легко добавлять файлы MS Office и синхронизировать их с локальным компьютером, осуществлять совместное редактирование несколькими пользователями, что в корпоративной среде удобно. Также позволяет вести профили компетенций пользователей — можно найти не только информацию, но и человека, которой в данной теме хорошо разбирается.
0
Профили компетенций звучат очень интересно. Пока не нашел для себя решения этой проблемы — просто веду табличку фича/человек, но это не очень удобно.
0
Безусловно дело привычки, но мне уж очень нравится синтаксис вики redmine. С картинками почти везде какие-то неудобства. Перепробовал штук 20 разных. Какие то сразу сносил. Из запомнившихся — dokuwiki, mediawiki. первая оч легкая и простая. Вторая как комбайн.
пользуем на ворке redmine. Но не только как вики.
ЗЫ: Кто нить знает рабочий standalone аналог с textile?
+2
Пробовал однажды (лет 10 назад) для ИТшной базы знаний внедрить именно MediaWiki. Столкнулся с тем, что эта система плохо приспособлена к разграничению доступа. Может сейчас есть более удобные средства, но в то время права можно было назначать только на пространства имён. Каждую ссылку приходилось оформлять в виде [[Пространство: Название статьи|Название статьи]], чтобы скрыть пространство имён — иначе ссылка выглядела уродством. Это в итоге и меня самого выбесило, и коллег подсадить на ведение системы не удалось.
Если бы внедрял подобную систему сейчас, в первую очередь смотрел бы на что-нибудь подобное FosWiki.
0
Как очень хорошую альтернативу, могу предложить посмотреть в сторону mindtouch (deki-wiki в детстве)
К сожалению, версия mindtouch core, уже не поддерживается разработчиком, это бесплатная версия и вроде все о чем вы говорили есть сразу в коробке. это self-hosted решение.
Only those users with full accounts are able to leave comments., please.