Из того, о чем часто слышал и с чем сам сталкивался, могу выделить:
Ставка на технологию и платформу, а не на процессы. Недостаточно просто установить вики и ждать, когда начнут пользоваться. Нужно построить процессы или сообщество вокруг нее.
Ожидание быстрых результатов. Если нет инициативы "сверху" и официальных процессов, завязанных на Вики, то ее внедрение может быть небыстрым. Нужно пройти через несколько релизных циклов, чтобы коллеги увидели Профит и начали участвовать. Если релизные циклы большие, процесс может затянуться: у нас в фирме это заняло года два (до этого люди активно читали, но редактировали лишь единицы). Стоит запастись терпением
Внедрение изменений вслепую. Поставьте сервер статистики с самого начала, чтобы понимать, какие фичи, методы продвижения и процессы работают, а какие нет. Сэкономите много времени и сил.
Страх неактуально/неполного/неточного контента. Иногда этот страх приводит к тому, что люди вообще не пишут на Вики, иногда -- к премодерации (она на раз отбивает желание добровольно вносить правки). Лучше иметь хоть какую-то документашку, чем совсем никакую.
Это, кстати, странно, ибо в клинике Шиловой в типовом договоре на операцию несколько страниц описаний возможных рисков (я сам после прочтения сильно сомневался, подписывать ли). Или автор не придал им внимания, раз они не были проговоренв на словах?
Делал сам у Шиловой почти полгода назад. У меня было примерно -3.5 и сильный астигматизм. До этого носил только очки.
Диагностикой очень доволен. В Чехии мне говорили, что все ок, но тут указали на проблемы со рвущейся сетчаткой (прижгли ее заодно, это очень больно)
По смайлу есть много вещей, о которых не читал: операция может быть болезненной несмотря на обезбол (с одним глазом долго возились, и это было прям больно). Сама операция ощутимо неприятная, хоть и длится недолго в норме. Первую неделю я видел сильно хуже, чем до: мутные пятна, проблемы с фокусировкой, светобоязнь. На идеальное зрение через день как у Boomburum не надейтесь.
После нескольких месяцев зрение отличное, но осталась заметная светочувствительность (я не могу ярким днём без темных очков). Для меня это не проблема, но для кого-то может быть неприемлемым.
В итоге я доволен, но нюансы стоит учесть. Любимое теперь развлечение на природе - облака рассматривать (красивые, оказывается, заразы)
Сильно зависит от расширения. Как описал комментатор выше, некоторые просто не загрузятся, некоторые приведут к ошибке на странице, некоторые не дадут загрузиться сайту.
Отключить расширение — дело пары секунд, но если это критично, то лучше обкатывать на препроде. Скажем, апгрейд на следующую версию MediaWiki требует апгрейда всех расширений под эту версию и тут без препрода или заметного даунтайма не обойтись.
Вынужден признать, что MediaWiki в этом плане не так хорошо работает «из коробки», как конфла. Ручных манипуляций нужно много.
Годный подход! Когда есть возможность интегрировать в процессы, это вообще здорово. Отдельные команды у нас приходят к чему-то похожему, что и у вас.
Когда стал тимлидом, для своей команды ввел необходимость подбивать документацию сразу после релиза (после релиза как раз становится немного посвободнее со временем). У QA есть своя специфика, но опыт говорит, что в итоге примерно одно и то же будет интересно и девелоперам, и QA, и техписателям, и техподдержке.
Конференция действительно вышла достойной. И доклады это полдела, было здорово пообщаться с таким количеством очень толковых специалистов по разным сферам KM. Часть ребят как будто прилетела из будущего, настолько продвинутые подходы.
Расширения частоп млят независимые разработчики в своих нуждах. Некоторые потом используют в проектах фонда викимедиа, некоторые нет. Викидата появилась, как я понимаю, из тех соображений, что википедия не может себе позволить на несколько дней уйти в ридонли для обновления БД. Им пришлось писать свой хитрый способ решения проблемы.
Те, кто хотят потратить деньги, обычно пользуются более безопасными для себя решениями от крупных компаний. Обычно мало кого парит, что в системе нет нужных конкретно им плюшек, по крайней мере так мне показалось из своего опыта.
Медиавики ставят только те, кто хочет или решить свою проблему бесплатно, или те, кому это действительно интересно. И в том, и в другом случае это не особенно приносит денег сторонним вики-разработчикам.
Впрочем, я могу ошибаться: в конце концов база знаний — это не основная моя деятельность, а скорее пет-проект с пользой для компании. Я не пробовал всерьез зарабатывать на этом деньги.
Кстати, а можете поделиться своим опытом бытия викимастером в прошлом? Как вы искали заказы и чем занимались? Если не секрет, конечно.
Отчасти соглашусь. Самому приходится допиливать расширения для того, чтобы повысить удобство в ущерб тем вещам, которые некритичны для внутреннего портала. С другой стороны, масштабируемость и еще раз масштабируемость.
По семантике — я еще не успел поработать с wikidata, но пожелание учту.
С учетом профиля компании (Национальная Медиа Группа владеет половиной СМИ в России) топик начинает звучать очень иронично.
Из того, о чем часто слышал и с чем сам сталкивался, могу выделить:
Ставка на технологию и платформу, а не на процессы. Недостаточно просто установить вики и ждать, когда начнут пользоваться. Нужно построить процессы или сообщество вокруг нее.
Ожидание быстрых результатов. Если нет инициативы "сверху" и официальных процессов, завязанных на Вики, то ее внедрение может быть небыстрым. Нужно пройти через несколько релизных циклов, чтобы коллеги увидели Профит и начали участвовать. Если релизные циклы большие, процесс может затянуться: у нас в фирме это заняло года два (до этого люди активно читали, но редактировали лишь единицы). Стоит запастись терпением
Внедрение изменений вслепую. Поставьте сервер статистики с самого начала, чтобы понимать, какие фичи, методы продвижения и процессы работают, а какие нет. Сэкономите много времени и сил.
Страх неактуально/неполного/неточного контента. Иногда этот страх приводит к тому, что люди вообще не пишут на Вики, иногда -- к премодерации (она на раз отбивает желание добровольно вносить правки). Лучше иметь хоть какую-то документашку, чем совсем никакую.
Могу рассказать про MediaWiki, Semantic MediaWiki и, конечно, про все связанное с корпоративными базами знаний. Варюсь в этом семь лет
Восстановил справедливость за вас.
Это, кстати, странно, ибо в клинике Шиловой в типовом договоре на операцию несколько страниц описаний возможных рисков (я сам после прочтения сильно сомневался, подписывать ли). Или автор не придал им внимания, раз они не были проговоренв на словах?
Делал сам у Шиловой почти полгода назад. У меня было примерно -3.5 и сильный астигматизм. До этого носил только очки.
Диагностикой очень доволен. В Чехии мне говорили, что все ок, но тут указали на проблемы со рвущейся сетчаткой (прижгли ее заодно, это очень больно)
По смайлу есть много вещей, о которых не читал: операция может быть болезненной несмотря на обезбол (с одним глазом долго возились, и это было прям больно). Сама операция ощутимо неприятная, хоть и длится недолго в норме. Первую неделю я видел сильно хуже, чем до: мутные пятна, проблемы с фокусировкой, светобоязнь. На идеальное зрение через день как у Boomburum не надейтесь.
После нескольких месяцев зрение отличное, но осталась заметная светочувствительность (я не могу ярким днём без темных очков). Для меня это не проблема, но для кого-то может быть неприемлемым.
В итоге я доволен, но нюансы стоит учесть. Любимое теперь развлечение на природе - облака рассматривать (красивые, оказывается, заразы)
Отключить расширение — дело пары секунд, но если это критично, то лучше обкатывать на препроде. Скажем, апгрейд на следующую версию MediaWiki требует апгрейда всех расширений под эту версию и тут без препрода или заметного даунтайма не обойтись.
Вынужден признать, что MediaWiki в этом плане не так хорошо работает «из коробки», как конфла. Ручных манипуляций нужно много.
Правда, уже почему-то удалено, вроде
А зачем разбивать статью на части? Вроде, не очень большая.
Когда стал тимлидом, для своей команды ввел необходимость подбивать документацию сразу после релиза (после релиза как раз становится немного посвободнее со временем). У QA есть своя специфика, но опыт говорит, что в итоге примерно одно и то же будет интересно и девелоперам, и QA, и техписателям, и техподдержке.
Обожаю PowerShell за возможность работать с .net библиотеками (включая поддержку работы с приватными полями и методами)
https://blog.netspi.com/using-powershell-and-reflection-api-to-invoke-methods-from-net-assemblies/
Это ооочень расширяет возможности.
Можно задать юзера, о имени которого будут делаться правки в replaceText через параметр
в LocalSettings.php
Т.е. достаточно создать юзера, сделать его ботом и назначить его как автора всех правок, проведенных через replaceText.
Другие массовые скрипты обычно тоже так или иначе поддерживают осуществление правок от имени ботов.
Мне помогает использование ботов, их удобно фильтровать при просмотре истории правок.
Расширения частоп млят независимые разработчики в своих нуждах. Некоторые потом используют в проектах фонда викимедиа, некоторые нет. Викидата появилась, как я понимаю, из тех соображений, что википедия не может себе позволить на несколько дней уйти в ридонли для обновления БД. Им пришлось писать свой хитрый способ решения проблемы.
Медиавики ставят только те, кто хочет или решить свою проблему бесплатно, или те, кому это действительно интересно. И в том, и в другом случае это не особенно приносит денег сторонним вики-разработчикам.
Впрочем, я могу ошибаться: в конце концов база знаний — это не основная моя деятельность, а скорее пет-проект с пользой для компании. Я не пробовал всерьез зарабатывать на этом деньги.
Кстати, а можете поделиться своим опытом бытия викимастером в прошлом? Как вы искали заказы и чем занимались? Если не секрет, конечно.
По семантике — я еще не успел поработать с wikidata, но пожелание учту.