MediaWiki: плагины, дополнения и пользовательские темы

Cooluck, помнится мне, заинтересовался движком от MediaWiki Foundation. Поскольку применяемая в нем технология полностью оупен-сорсовая, то в свободном доступе есть дополнительные модули расширения и темы для движка, которые позволяют повысить функциональность и расширить возможности системы в случае использования ее в компании как основы корпоративной википедии (называть это "базой знаний" я считаю не вполне корректным, а "веб-интерфейсом для хранилища файлов" - вообще кощунством... удивительно также, как постоянно возникают мысли "как бы разграничить доступ", хотя open-source - это основа для СОВМЕСТНОГО, а не РАЗГРАНИЧЕННОГО применения, ну да ладно).

Для начала - напомню, что за зверь является объектом нашего пристального внимания ( и заодно - моего повседневного использования, поскольку я в настоящее время занимаюсь администрированием такой системы по месту работы).

MediaWiki is a web-based wiki software application used by all projects of the Wikimedia Foundation, all wikis hosted by Wikia, and many other wikis, including some of the largest and most popular ones. Originally developed to serve the needs of the free content Wikipedia encyclopedia, today it has also been deployed by companies for internal knowledge management, and as a content management system. Notably, Novell uses it to operate several of its high traffic websites.
MediaWiki is written in the PHP programming language, and can use either the MySQL or PostgreSQL relational database management system. MediaWiki is distributed under the terms of the GNU General Public License while its documentation is released under the GFDL and partly in the public domain, making it free and open source software.

А теперь - небольшая подборка полезных ресурсов по данному движку:

Темы оформления - небольшая подборка тем оформления с простой инсталляцией.
Плагины - набор плагинов под движок.
Расширения - надстройки для расширения функциональности движка.
"Сделать закладку" - скрипт закладок для MediaWiki.

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

MediaWiki, или +1 в резюме и хз сколько плюсов в карму

Сегодня немного о делах и личном эго: своими вот этими вот ручками закончил структурировать и подготовил к окончательному пуску в работу локальный вики-движок. Хотите называйте это "knowledge base", хотите "corporate wiki" или "localized wiki-base" - короче говоря, завершились мои мучения и творческие порывы над кодом, плагинами и страницами для локальной википедии (пафосно звучит-то как, Господи :) )


Кратко расскажу, что же представляет мой "+1" в личную резюмокарму (или карморезюме):

1. Тип движка: MediaWiki (инсталляцию и разворачивание на серваке проводили админы, о технической стороне не знаю ничего, движок с открытым кодом и на лицензии GPL /GNU)
2. Вид работ: введение системы менеджмента файлов и информации в повседневную практику работы менеджеров.
3. Перечень работ, выполненных непосредственно мной:
Создание логической структуры системы.
Контент-менеджмент.
наполнение файлами.
Линк-менеджмент.
Оптимизация меню и навигационных возможностей системы.
Организация политики приватности.
Планирование процессов и внутренних процедур работы с системой.
Поиск слабых мест и оценка с точки зрения usability, customized features, inner changes.

В принципе, вокруг данной системы веду песни-танцы-шаманство с бубном и без уже в течение года. Из "сырого" движка без настройки и кастомизации получилась в итоге вполне симпатичная система, с четкой структурой, массой вручную сделанных ссылок для улучшения навигации и вообще очень гибкий инструмент для менеджера продукта или проджект-менеджера. Откинувшись на спинку кресла, созерцаю дело рук своих, слушая в наушниках Боба Марли :) Весь отличный результат, если учесть, что систему настраивал и кастомизировал в одиночку, и еще - у меня не айтишное образование ;) да здравствует менеджмент информации сцуко и открытый код вики-движков!

bizcase: зачем wikipedia

(с) by Martin Dijkstra


Доброе утро. Понимаю, что воскресенье - не лучшее время для "подумать", однако всё же предлагаю вам небольшой бизнес-кейс. Вызрел в голове по итогам событий пятницы и небольшого внутреннего недопонимания "а собственно, в чём трабл?". И поскольку с утра я выспавшийся и с новой энергией в голове, то вот вам кейс, а я ушел пылесосить квартиру =))


Дано: компания, работающая в сфере телекоммуникаций, на рынке около 20 лет, ряд эффективных разработок, у конкурентов выигрывает за счет сравнительно низкой цены, проигрывает за счет длительной "завязанности" на 1 ключевого клиента, который - впрочем - уже перестает быть ключевым. недостаток - постоянные сбои во внутренней организации процессов и обмена информацией (что типично для украинских компаний).

Условия задачи: Каждый раз одни и те же процессы взятия обще информации повторяются. К их числу относятся: информация о профайле компании, общие данные по ключевым продуктам, вводная часть коммерческих предложений, общие сведения о компании и партнерах, технические характеристики, перечень и география внедрений. При этом было принято решение процессы упорядочить, для чего была внедрена система "корпоративная Википедия" на базе движка МедиаВики (от MediaWiki Foundation) (бесплатный движок с открытым кодом). По идее, применение такого движка должно было сократить затраты времени и упростить доступ к информации. После года эксплуатации движка система превратилась в локальный каталогизатор веб-файлов, но информацией в виде вики-статей не наполняется. Причину четко не формулируют, но есть несколько типовых утверждений, которые всегда звучат в обсуждении системы:

1) "Не все документы должны видеть разработчики"
2) "Не все менеджеры продуктов должны видеть все документы"
3) "Не все вообще должны видеть документы"
4) "Не все менеджеры и разработчики станут размещать информацию самостоятельно"
5) "Кто будет следить за обновлением статей?"
6) "У нас часто меняется видение того, какая информация является открытой, а какая закрытой"
7) "Мы сами не должны делать за менеджеров работу по размещению"
8) "Разработчики и менеджеры (с указанием конкретных лиц) не станут этого сами делать, ты же понимаешь"

Кроме того, ситуацию осложняют так называемые "закрытые разделы" документации, которая постоянно создается "под конкретного заказчика" и зачастую отличается в логике и фактах.

В итоге - потери времени на запрос повторяющейся информации и однотипных документов или фрагментов документов, поиск нужных файлов и повторное их сохранение составляют до 20% рабочего времени (проще говоря: на рабочем компьютере каждого менеджера скапливается неупорядоченный ворох файлов с "версиями", которые у каждого устроены и упорядочены по-разному. В итоге - увольнение сотрудника приводит к тому, что потом еще полгода раскапывают его файлы, а логику структуры каталогов приходится держать "в голове", особенно, если тебе поручен сегмент работы, которой ты до этого не занимался).

Вопросы:

1. Как заставить работать "корпоративную Википедию" именно как Википедию, а не как свалку файлов с древовидной структурой?
2. Как ответить руководству на вопрос "а зачем это нам?"
3. Как донести до менеджеров и разработчиков суть того, что это ПОМОЖЕТ им упорядочить ИХ СОБСТВЕННУЮ деятельность?
4. Надо ли оформлять это как отдельный проект или действовать как всегда по логике "партия сказала "надо", комсомол ответил "есть"?
5. Какие практические рекомендации еще можно дать в такой ситуации?


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