Контрибьютер что это

Программа поддержки контрибьюторов

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

Руководство программы

Программой сотрудничества с контрибьюторами игры руководит специальная международная команда внутри компании Wargaming.net. Руководство программы оставляет за собой право:

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

Таким образом, главный принцип программы — взаимоуважение и тесное взаимодействие между командой игры и контрибьюторами. Если у вас есть какие-то проблемы, мы готовы их обсуждать.

Преимущества для контрибьютеров

Участнику программы сотрудничества с контрибьюторами игры полагаются следующие бонусы и привилегии [1] :

доступ к каналу программы в Discord;
ранний доступ к контенту, предусмотренному программой (в основном корабли); так контроибьютор сможет делать эксклюзивные предварительные обзоры по утверждённому графику;
своя группа на форуме;

эксклюзивные внутриигровые предметы [2] :

особый флаг в игре;
особая нашивка (фон и символ);
специальной эмблемой (в зависимости от продолжительности сотрудничества);
эксклюзивный камуфляж.

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

Кроме того, возможны дополнительные бонусы:

появление созданного контрибьютором контента в игре и на портале (для этого, возможно, понадобится подписать важные документы — это связано с юридической стороной процесса);
возможность пригласить разработчиков игры на интервью;
совместные стримы с командой игры;
приглашения на офлайн-мероприятия и в офис в Санкт-Петербурге (за счёт разработчиков);

особые внутриигровые награды и розыгрыши, в частности за:

особую активность (под этим подразумевается две и более качественные публикации, связанные с игрой, в неделю; это могут быть стримы, видео или статьи);
рост числа подписчиков YouTube или Twitch и достижение определённых целей;
день рождения контрибьютора.

Становимся контрибьютером в PostgreSQL

PostgreSQL Logo

В этой статье я хотел бы рассказать о том, как выглядит процесс разработки PostgreSQL глазами одного из контрибьютеров в этот самый PostgreSQL. Заниматься разработкой этой СУБД я начал в декабре 2015 года, когда устроился работать в компанию Postgres Professional. То есть, не так уж давно. А значит, еще свежи воспоминания о моментах, которые поначалу казались мне не вполне очевидными. Хотелось бы их законспектировать, чтобы новым людям, приходящим в нашу команду, а также всем тем, кто желает попробовать себя в роли разработчика открытой реляционной СУБД, было легче. Я расскажу о том, как выглядит процесс разработки PostgreSQL, какие инструменты я использую в своей повседневной работе, как следует оформлять патчи, и так далее. Заинтересовавшихся прошу проследовать под кат.

Набор инструментов

Вопрос, который будоражит умы миллионов — какую IDE или текстовый редактор использовать? 🙂 Практика показывает, что разрабатывать PostgreSQL можно в чем угодно. Кто-то из моих коллег использует Sublime Text, кто-то предпочитает Vim, кто-то Emacs, также есть пользователи KDevelop и Visual Studio Code. Я лично первое время вполне успешно использовал CLion, сейчас же перешел на Vim + ctags. В общем и целом, главное, чтобы в редакторе была подсветка синтаксиса, переход к определению, возможно какие-то простые вещи вроде переименования переменных и проверки орфографии. Какие-то навороченные автоматические рафакторинги вам вряд ли понадобятся. Дело в том, что патч с результатом таких рефакторингов вряд ли так просто примут.

Второй не менее волнительный вопрос — какую ОС или дистрибутив Linux выбрать? У нас в компании многие разработчики используют Ubuntu. Также есть пользователи MacOS. Под Windows, вроде, никто не сидит — для разработки под эту платформу обычно запускают виртуалку. Есть один пользователь Arch Linux. Я лично долгое время пользовался Ubuntu, но недавно ударился головой и перешел на FreeBSD. В общем и целом, любая *nix система должна подойти.

PostgreSQL успешно компилируется GCC, CLang и Visual Studio, возможно и какими-то другими компиляторами (Intel C++ Compiler?). Более того, сообщество стремится поддерживать совместимость кода со всеми этими компиляторами. Так что компилятор вы можете использовать любой. Также вы можете использовать свой любимый отладчик, будь то GDB, LLDB, что-то встроенное в вашу IDE или какой-нибудь WinDbg.

Код PostgreSQL живет в Git. Помимо официального репозитория еще есть зеркало на GitHub, но это чисто зеркало. Открывать там issues и слать туда пуллреквесты бессмысленно. Во время разработки патча никому нет дела, какую систему контроля версий вы используете. Но патч обычно посылают в виде вывода команды git diff.

В первом приближении, вроде, ничего не забыл. Время от времени я также использую perf, tcpdump, strace/truss, dtrace, rr, lcov, различные статические анализаторы и другие инструменты. Но потребность в них возникает скорее в порядке исключения. Основные инструменты разработки — это текстовый редактор, git, компилятор, отладчик и, конечно же, мозг. Да, и еще почтовый клиент. Но об этом я расскажу ниже.

Сборка, прогон тестов и так далее

В настоящее время PostgreSQL использует Autotools. Autotools сам по себе не очень приятная штука. К тому же, не рассчитанная на Windows. Поэтому для сборки PostgreSQL под эту платформу предусмотрен специальный набор Perl-скриптов, что несколько костыльно. Мой коллега Юрий Журавлев пытается протолкнуть патч, переводящий PostgreSQL на CMake. Но там все непросто, так как текущая система расширений PostgreSQL сильно завязана на Autotools.

Все проекты, использующие Autotools, собираются примерно одинаково:

./configure --prefix=. make -j4 -s make check make install

Для быстрого локального развертывания PostgreSQL я использую такой набор скриптов, многими из которых со мной поделился Стас Кельвич.

Тонкий момент, на который налетают все начинающие контрибьюторы в PostgreSQL без исключения — если вы внесли изменение в .h файл, не забудьте прогнать make clean. По умолчанию при изменении .h файла зависящие от него .c файлы не пересобираются. Если этого не знать, можно пронаблюдать широчайший спектр занимательнейших магических эффектов 🙂

Идея для первого патча, и как еще можно помочь проекту

Часто человека, находящегося в поисках идеи для патча, отправляют к списку TODO. На мой взгляд, это довольно вредный совет, по целому ряду причин. Во-первых, этот список не всегда находится в актуальном состоянии. Во-вторых, там есть пункты, про которые никто точно не знает, как их правильно сделать, и потому было решено просто добавить пункт в TODO, авось когда-нибудь придет прозрение. Наконец, в третьих, большинство задач из этого списка довольно сложны. Я бы советовал начать с чего-то попроще.

Проще всего поискать в коде и документации опечатки. Их там действительно много. Так происходит по той причине, что перед мержем предложенных патчей коммитеры часто их слегка переписывают, совсем чуть-чуть. В результате получается совершенно новый патч, который никто не вычитывал, отсюда и опечатки. Можно просто следить за новыми коммитами и каждую неделю присылать 1-2 патча. Исправлением комментариев к коду сложно что-то сломать, поэтому ваш патч охотно примут.

Бывает так, что какие-то куски кода можно немного отрефакторить. Это тоже довольно простое изменение. Делаем код красивее и правильнее, прогоняем тесты, если ничего не сломалось — предлагаем патч.

Исправление багов. В рассылку pgsql-bugs@ регулярно репортят баги (как правило, минорные). Обычно исправление бага — это халява. Пишем тест, воспроизводящий баг. Переписываем код так, чтобы тест больше не падал. Шлем патч.

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

Улучшение документации и комментариев. Например, вы пытаетесь понять, как работает код, но не понимаете. Похоже, вы нашли место, где комментарии к коду можно улучшить!

Часто можно найти, что запатчить, собрав проект каким-то необычным компилятором (например, очень старой или очень новой версией GCC), на необычной платформе (ARM, PowerPC, . ) под необычной операционной системой (NetBSD, OpenIndiana). Тесты обычно не сыпятся, но пара варнингов при компиляции может проскочить. Еще часто помогает прогнать по коду какой-нибудь статический анализатор.

Если у вас нет идеи для своего патча, вы можете существенно помочь проекту, сделав code review и/или протестировав чужой патч. Программисты, как правило, очень любят писать код, но не особо любят ревьювить и тестировать его. Поэтому ревьюверов в сообществе PostgreSQL прямо реально не хватает. Ревьювером, кстати, быть довольно просто. Нужно убедиться, что патч применяется, код после этого компилируется и проходит тесты, а также что задача, которую перед собой ставил автор, при этом решена. Если вам не ясно, как это проверить, возможно, автор недостаточно хорошо это описал. Это повод задать вопрос автору в соответствующем треде и перевести патч в состояние waiting on author. А если при этом вы еще и в состоянии читать код и давать адекватные советы по переименованию переменных и разбиению процедур на несколько, то вам просто цены нет! О code review, выставлении патчей на коммитфест и различных состояниях патчей речь пойдет далее.

Про мейлинг листы и блоги

Все общение разработчиков PostgreSQL происходит в рассылке pgsql-hackers@. Еще имеет смысл подписаться на pgsql-committers@. Туда прилетают уведомления о последних мержах в мастер, иногда завязывается обсуждение конкретного коммита. Трафик в этих двух мейлинг листах не такой уж большой, это вам не LKML. Их вполне реально читать со своего основного ящика без каких-либо фильтров (правда, я читаю далеко не все треды подряд). Я лично получаю их все на рабочий e-mail.

Еще может иметь смысл подписаться на pgsql-general@ (общие вопросы) и уже упомянутый pgsql-bugs@ (багрепорты). Но, строго говоря, для разработки это не требуется.

По поводу выбора почтового клиента. В принципе, подойдет любой. Многие используют Thunderbird. Я долгое время сидел на Claws Mail, а сейчас переполз на Mutt. Видел, как кто-то из коллег использует GMail.

Хорошим тоном является не слать в рассылку HTML-письма. Текст письма по ширине стоит ограничить 72-я символами. Понятное дело, использовать можно только английский язык. Использовать аттачи, в отличие от того же LKML, не запрещается. Тяжелые аттачи лучше куда-нибудь заливать, а не слать напрямую в мейлинг лист.

В сообществе PostgreSQL, насколько мне известно, нет какого-либо code of conduct. Но это не отменяет необходимости быть вежливым, не использовать сарказм, никогда не переходить на личности, и так далее. Электронные письма, особенно на английском языке, часто получаются несколько сухими. Поэтому неплохой идеей будет использовать в тексте побольше слов вроде please, thank you, и так далее. Я лично стараюсь начинать любое письмо словами вроде «Thank you everyone for great comments!» и заканчивать чем-то вроде «As always, please don’t hesitate to share any thoughts on this topic!». Попробуйте, и вы удивитесь, насколько дружелюбнее к вам станет сообщество.

Возможно, стоило бы сказать пару слов про основных действующих лиц в рассылке, таких, как Tom Lane, Simon Riggs, Robert Haas, Andres Freund, Alvaro Herrera, Bruce Momjian, и других. Но проблема в том, что действующих лиц довольно много, и кто конкретно заинтересуется вашим патчем заранее сказать трудно. Поэтому скажу лишь, что неплохой идеей будет первое время читать подписи людей, которые вам отвечают, смотреть, на каких доменах находятся их e-mail, поискать их имена в git log ну или в Google в конце-то концов.

Кстати, некоторые люди из сообщества PostgreSQL ведут блоги (которые как раз можно найти благодаря Google), на которые не лишено смысла подписаться. Я лично в настоящее время подписан на следующие связанные с PostgreSQL RSS-фиды:

# PostgreSQL http://postgresmen.ru/news.xml http://planet.postgresql.org/rss20.xml http://habrahabr.ru/rss/company/postgrespro/blog/ http://www.postgrespro.ru/rss http://www.postgresql.org/news.rss http://postgresweekly.com/rss/1ijl6aaa http://postgres-edu.blogspot.com/feeds/posts/default http://feeds.feedburner.com/depesz http://rhaas.blogspot.com/feeds/posts/default http://amitkapila16.blogspot.com/feeds/posts/default http://obartunov.livejournal.com/data/rss

Заметьте, что в список входит Планета PostgreSQL, которая агрегирует многие блоги, которых нет в списке.

Как послать патч

В общем случае, прежде, чем начинать работу над каким-то большим патчем, не лишено смысла написать в pgsql-hackers@ письмо-proposal с описанием того, что вы хотите сделать, как, и зачем. Может оказаться, что это никому особо и не нужно. Или наоборот, что это так нужно, что за последние лет 5 предлагалось несколько решений, о которых вы не знаете, и с которыми стоит предварительно ознакомиться. Ну или вам могут просто дать пару советов по реализации, куда стоит посмотреть, какие граничные случаи учесть, и так далее. Разработчики PostgreSQL — занятые люди, у которых своих дел хватает, так что не стоит бояться, что вашу гениальную идею кто-то тут же украдет. Скорее вам скажут, что это вряд ли будет работать, и предоставят возможность доказать обратное.

По поводу оформления кода. В PostgreSQL используется ANSI C, так что про всякие там С11, C++ или Rust сразу забудьте. Для форматирования кода используется утилита pgindent. Инструкцию по ее сборке вы найдете в исходниках PostgreSQL, в файле src/tools/pgindent/README. Перед созданием патча всегда прогоняйте код через pgindent, иначе его никто даже смотреть не станет. (Но следите за тем, чтобы pgindent не вносил изменения там, где вы ничего не меняли! В этом случае, возможно, код будет проще отформатировать вручную.) В остальном каких-то особо строгих правил нет. Просто смотрите, как оформлен код в районе того места, куда вы вонзаетесь, и старайтесь писать так же.

Когда патч готов, оправьте его в pgsql-hackers@, указав в subject метку [PATCH] и краткое описание. В теле письма расскажите, какую проблему решает патч, и каким образом он это делает. Почитайте архив рассылки, чтобы посмотреть, как это обычно выглядит. Если патч небольшой, например, исправляет пару опечаток, его могут принять сразу и без особых вопросов. В более сложных случаях патч нужно отправить на ближайший коммитфест:

PostgreSQL Commitfest

Коммитфест — это местное название спринта. Один коммитфест длится один месяц. Например, сейчас открыт сентябрьский коммитфест. Все новые патчи добавляются в него. В начале сентября начнется рассмотрение патчей из сентябрьского коммитфеста, а все новые патчи будут добавляться в ноябрьский (в октябре коммитфеста нет, месяц правятся баги и так далее). Так продолжается до марта, всего 4 коммитфеста — в сентябре, ноябре, январе и марте. Затем наступает кодфриз, правятся баги, формируются альфа- и бета-релизы.

Патчи на коммитфесте бывают в разных состояниях. Все они имеют говорящие названия. Needs review означает, что патчу требуется ревьювер. Waiting on author означает, что какие-то действия требуются со стороны автора патча. Ready for committer означает, что патч прошел кодревью и по нему больше нет вопросов. Один из коммитеров может ознакомиться с ним и либо вмержить, либо вернуть автору на доработку. Ну и так далее.

Запаситесь терпением. Если на ваш патч никто не реагирует, это не значит, что он никому не нужен. Просто сейчас все заняты другими патчами. Если ваш патч есть в коммитфесте и не висит в Waiting on author, про него никто не забудет, не переживайте. Если вам ответил ревьювер или коммитер, внимательно прочитайте ответ, внесите соответствующие изменения в патч и отправьте его новую версию. Спорить с ревьюверами или коммитерами, по моему личному опыту, занятие очень неблагодарное. Быстрее исправить код и послать исправленный патч. Более того, нередко потом понимаешь, что ревьювер или коммитер в общем-то был прав, а ты — нет. Впрочем, у некоторых моих коллег иной опыт, и они наоборот считают, что всегда нужно спорить.

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

Заключение

Дополнительные материалы для самостоятельного изучения:

Видеокурс «Hacking PostgreSQL» Анастасии Лубенниковой. Замечательный курс о внутреннем устройстве PostgreSQL. Доступны видео и слайды.
Книга Database System Implementation. Как в ней написано, именно так PostgreSQL и работает.
Основы отладки при помощи GDB. Там же вы найдете ссылки на статьи про отладку при помощи LLDB, использование замечательного инструмента RR, и не только.
О том, как профилировать код с использованием perf, bcc/eBPF и других инструментов. В статьях вы также найдете ссылки на материалы по DTrace и SystemTap.
Туториалы по Valgrind’у и статическим анализаторам для C/C++. Эти инструменты помогают находить различного рода ошибки в коде, крайне полезно уметь ими пользоваться.
Наша компания перманентно нанимает. Работа интересная, хотя и несколько специфичная. Привыкнув к недельным спринтам с еженедельной выкаткой нового кода, мне долгое время было непросто перестроиться.

Контрибьюторы

Контрибьюторы — это активные участники игрового сообщества, которые не являются волонтерами, но поддерживают Мир кораблей своими видеороликами, статьями, записями в блогах и т.д. об игровых механиках, кораблях и пр. или развлекают других игроков сражениями на стримах. Они являются участниками одноименной программы сотрудничества. Контрибьюторов можно отличить по участию в группе «Видеоблогер» на форуме, а также по особому флагу, камуфляжу, нашивке или эмблеме в игре.

Общая информация

Контрибьюторы это те, кто активно поддерживают Мир кораблей различным интересным и полезным медиа-контентом вне форума:

на сайтах видеохостингах (например, Youtube);
на сайтах видеостримингового сервиса (например, Twitch);
в собственных блогах;
на своих страницх в социальных сетях;
на собственном сайте.

Полезным и интересным другим игрокам медиа-контентом являются:

статьи или видеообзоры по:

кораблям;
обновлениям;
картам.

собственных боев, включая тестирование новой техники;
турниров.

Контрибьюторы являются участниками одноименной программы сотрудничества Мира кораблей, поэтому обладают специальными:

особым флагом;
игровой медалью;

нашивкой:

фоном;
символом.

Внимание! Если игрок лишается статуса контрибьютора, то флаг может быть у него забран.

Заявка на участие в программе сотрудничества с контрибьюторами

Для того, чтобы подать заявку и стать контрибьютором, необходимо:

обладать собственным каналом, сайтом, блогом или страницей в социальных сетях, которые существуют как минимум 3 месяца;
они должны содержать не менее 10 видео, стримов или публикаций, посвящённых Миру кораблей;
контент должен быть качественным;

охват аудитории:

для Youtube канала — среднее количество просмотров роликов за последние 90 дней, посвящённых Миру кораблей, должно быть не менее 300;
для Twitch канала — среднее количество зрителей трансляций, посвящённых Миру кораблей за последние 90 дней, должно быть не менее 30;
для текстовых медиа — вопрос будет решаться индивидуально, но определённый охват аудитории также должен присутствовать.

В случае соответствия вышеуказаным требованиям нужно оставить сообщение-заявку со своего основного аккаунта в соответствующем разделе форума.

В заявке необходимо:

рассказать о себе все, что игрок считает нужным;
рассказать о том, каких целей игрок хочет достичь как участник программы;
указать ссылки на контент (каналы Twitch, YouTube и т.д., сайт, блог и т. д.), чтобы разработчики видели, что игрок делаете для сообщества Мира кораблей;
указать свой Discord-тег, поскольку общение будет происходить именно в нем.

Дополнительно можно указать:

свой размер футболки;
свою дату рождения;
ник на общем тесте.

Заявка будет доступна только написавшего ее игроку, сотрудникам и модераторам. Другие игроки не смогут её увидеть.

После того как разработчики ознакомятся с заявкой (это займёт около 5 рабочих дней), они свяжутся с игроком в Discord и расскажут, что делать дальше.

Критерии отбора очень просты:

качество материалов по игре;
их потенциал;
число подписчиков.

Главный критерий, от которого зависит участие в программе, — качественный контент. Заявка может быть отколнена после оценки качества контента игрока.

ВАЖНО: заявки, которые не содержат ссылок на опубликованные материалы (ролики, статьи) по Миру кораблей, рассматриваться не будут. Программа, в первую очередь, будет поддерживать тех, кто уже делает материалы, связанные с Миром кораблей. Разработчики всегда рады помогать новичкам, но хотят, чтобы игрок показал свою заинтересованность благодаря созданному контенту.

Преимущества для контрибьюторов

Флаг контрибьютора на корабле

Участнику программы сотрудничества с контрибьюторами Мира кораблей полагаются следующие бонусы и привилегии [1] :

доступ к каналу программы в Discord;
ранний доступ к контенту, предусмотренному программой (в основном корабли); так контроибьютор сможет делать эксклюзивные предварительные обзоры по утверждённому графику;
своя группа на форуме;

эксклюзивные внутриигровые предметы [2] :

особый флаг в игре;
особая нашивка (фон и символ);
специальной эмблемой (в зависимости от продолжительности сотрудничества);
эксклюзивный камуфляж.

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

Кроме того, возможны дополнительные бонусы:

появление созданного контрибьютором контента в игре и на портале (для этого, возможно, понадобится подписать важные документы — это связано с юридической стороной процесса);
возможность пригласить разработчиков игры на интервью;
совместные стримы с командой Мира кораблей;
приглашения на офлайн-мероприятия и в офис в Санкт-Петербурге (за счёт разработчиков);

особые внутриигровые награды и розыгрыши, в частности за:

особую активность (под этим подразумевается две и более качественные публикации, связанные с Миром кораблей, в неделю; это могут быть стримы, видео или статьи);
рост числа подписчиков YouTube или Twitch и достижение определённых целей;
день рождения контрибьютора.

Требования к контенту

Важными плюсами станут:

соблюдение чёткого графика публикаций/трансляций [3] ;
готовность создавать контент для разных категорий игроков;
активное взаимодействие с аудиторией;
обратная связь по изменениям в игре как напрямую с разработчикамми через специальные каналы, так и через создаваемый контент;
уважение чужой точки зрения и умение аргументированно отстаивать свою позицию;
содействие развитию игры и сообщества.

использовать выражения, сеющие рознь по расовому или половому признаку;
публиковать оскорбления;
оскорблять других участников программы [4] ;
размещать ложную информацию об игре и прочих продуктах компании;
использовать объекты интеллектуальной собственности компании для рекламы продуктов её прямых конкурентов;
распространять информацию об уязвимостях игрового клиента и запрещённом ПО (просьбы и рекомендации скачать, установить и использовать запрещённое ПО и ошибки игры в любом контексте);
использовать кликбейт и «громкие» заголовки, в особенности связанные с игрой, сотрудниками компании и их деятельностью;
публиковать контент на тему религии, секса, политики и прочих общественно значимых вопросов;
публиковать порнографические материалы, а также материалы, поднимающие темы насилия и жестокости в любом виде;
участвовать в преследовании пользователей или поощрять подобные действия, а также участвовать в действиях, нацеленных на то, чтобы оскорбить, унизить честь и достоинство кого-либо из участников игрового сообщества, разжигать ненависть и пытаться вызвать волнение среди игроков;
распространять информацию (в любой форме, в том числе и в форме рекламы) о любых внешних платных сервисах, связанных с Миром коарблей или кажущихся связанными с Миром кораблей, без нашего разрешения.

Эти требования к контенту относятся, в том числе, к форумам, стримам, видео, прямым трансляциям, публикациям и комментариям на Reddit, в социальных сетях и на прочих публичных площадках и каналах.

Если участники не будут соблюдают вышеуказанные правила и требования, руководство программы примет решение по каждому нарушению в индивидуальном порядке. К участникам могут быть приняты следующие меры:

предупреждение или выговор;
временное исключение из программы;
исключение из программы.

При серьёзных нарушениях Лицензионного Соглашения, Правил Игры и Правил кланов разработчики оставляют за собой право принимать любые из указанных выше мер, помимо стандартных мер, которые обычно принимаются по отношению к игрокам.

Список контрибьюторов

Пользовательский контент является большой и значимой частью проекта для команды Мира кораблей.

На данной странице на Портале (все регионы) собраны ссылки на сторонние фанатские ресурсы. Фанатские ресурсы являются продуктом третьих лиц, не имеющих отношения к команде разработки. Команда Мира кораблей считает данные ресурсы ценными и информативными, но не несёт ответственности за их содержание.

См. также

Сообщество;
Программа поддержки контрибьюторов

Ссылки на интернет источники

Снимай и смотри! Призы для всех.
Прием заявок на участие в программе сотрудничества с контрибьюторами Мира кораблей.
Список фан-ресурсов.
Список контрибьюторов на CIS регионе.

Примечания

↑ Все бонусы зачисляются на основной игровой аккаунт, который игрок использовал для участия в программе, или передаются лично (всё зависит от типа бонуса).
↑ Раз в месяц разработчики готовят список бонусов, которые гарантированно получит каждый участник программы.
↑ Разработчики хотят, чтобы контрибьютор создавал свой контент по наиболее комфортному для него графику, и не собираются торопить его. Они лишь хотят быть уверенными в том, что игрок не пропадёте из виду. Если контрибьютор долгое время не будет выпускать никакого контента, с ним свяжутся. Если ситуация не изменится, сотрудничество будет прекращено.
↑ Указано намеренно. Все отношения внутри программы строятся на основе принципа «Живи и другим не мешай». Контрибьютору не обязательно любить других участников сообщества и он может оспаривать их мнение, но это должно основываться на уважительном отношении друг к другу.

Статья 16. Требования к управлению и контролю поднадзорных контрибьютеров

1. К управлению и контролю, осуществляемым поднадзорным контрибьютером, применяются следующие требования:

(а) поднадзорный контрибьютер обеспечивает, чтобы предоставление входных данных не затрагивалось никаким существующим или потенциальным конфликтом интересов и чтобы в тех случаях, когда требуется какое-либо дискреционное полномочие, оно осуществлялось независимо и честно на основе соответствующей информации согласно кодексу поведения, указанному в Статье 15;

(b) поднадзорный контрибьютер должен иметь систему контроля, обеспечивающую достоверность, точность и надежность входных данных, и предоставление входных данных в соответствии с настоящим Регламентом и кодексом поведения, указанным в Статье 15.

2. Поднадзорный контрибьютер должен иметь эффективные системы и средства контроля для обеспечения достоверности и надежности всех предоставленных администратору входных данных, включая:

(а) контроль в отношении того, кто может представлять входные данные администратору, включая, когда это является соразмерным, контроль процесса утверждения физическим лицом, занимающим должность, более высокую по сравнению с должностью отправителя;

(b) надлежащую подготовку отправителей, предполагающую по крайней мере изучение настоящего Регламента и Регламента (ЕС) 596/2014;

(с) меры по управлению конфликтами интересов, включая при необходимости организационное разделение работников, и рассмотрение вопроса о том, каким образом устранить создаваемые политикой вознаграждения стимулы для манипулирования бенчмарком;

(d) учет в течение соответствующего периода времени сообщений, связанных с предоставлением входных данных, учет всей информации, используемой для того, чтобы сделать возможным для контрибьютера подачу документов, и учет всех существующих или потенциальных конфликтов интересов, включая воздействие контрибьютера на финансовые инструменты, стоимость которых определяется на основе бенчмарка, но не ограничиваясь им;

(е) учет внутренних и внешних аудитов.

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

4. Поднадзорный контрибьютер должен в полной мере сотрудничать с администратором и соответствующим компетентным органом в проведении аудита и надзора за установлением бенчмарка и предоставлять информацию и записи, хранящиеся в соответствии с параграфами 2 и 3.

5. ESMA разрабатывает проекты регулятивных технических стандартов для дальнейшего уточнения требований, касающихся управления, систем и механизмов контроля, а также политик, изложенных в параграфах 1, 2 и 3.

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

ESMA должен представить указанные проекты регулятивных технических стандартов Европейской Комиссии до 1 апреля 2017 г.

Европейской Комиссии делегируются полномочия по принятию регулятивных технических стандартов, указанных в первом подпараграфе, в соответствии с процедурой, изложенной в Статьях 10 — 14 Регламента (ЕС) 1095/2010.

6. В соответствии со Статьей 16 Регламента (ЕС) 1095/2010 ESMA может издать руководство, адресованное поднадзорным контрибьютерам незначительных бенчмарков, в целях уточнения элементов, указанных в параграфе 5 настоящей Статьи.

Кодекс поведения	Раздел III. >> Требования к различным типам бенчмарков
Содержание Регламент Европейского Парламента и Совета Европейского Союза от 8 июня 2016 г. 2016/1011 об индексах, используемых в качестве.