Як зібрати команду модерації Discord: структура, що витримує 2000 учасників

Кожен сервер, що росте, доходить до моменту, коли одна людина вже не може модерувати сама. Що зазвичай відбувається тоді: троє друзів отримують дозволи модератора, бо часто бувають онлайн. Через пів року двоє з них неактивні, ніхто не наважується забрати в них роль, а третій вигорів.

Це не кадрова проблема. Це відсутність зводу правил.

Почни з дозволів, а не з ролей

Звичний порядок перевернутий. Більшість спершу створює ролі, що звучать як звання, а вже потім вирішує, що їм має бути дозволено.

Зроби навпаки. Запиши, які завдання справді існують:

• Хтось має видаляти спам і заспокоювати суперечки
• Хтось має відповідати на запити підтримки
• Хтось має вирішувати, хто приєднується до команди
• Хтось має організовувати події

Лише потім об'єднуй завдання в ролі. Зазвичай виходить менше ролей, ніж ти очікував, і в кожної є чітка мета.

Мінімальні дозволи

Одне правило, яке рятує від багатьох проблем: ніхто не отримує «Адміністратор», якщо йому справді не треба адмініструвати сервер.

Для щоденної модерації цього достатньо:

Завдання	Потрібний дозвіл
Видалити спам	Керувати повідомленнями
Заспокоїти когось	Тайм-аут для учасників
Вигнати когось	Виганяти учасників
Видалити назавжди	Банити учасників

Це все. «Керувати каналами», «Керувати ролями» і «Керувати сервером» належать керівництву, а не модерації. Причина не в недовірі, а в обмеженні шкоди: якщо акаунт зламають, саме цей список вирішує, наскільки погано все буде.

Набору потрібен процес

Поки членів команди набирають за відчуттям, кожна відмова стає особистою. Чіткий процес захищає обидві сторони.

Процес, який себе довів:

1. Заявки через форму, а не через особисте повідомлення. Так усі в керівництві бачать ту саму інформацію.
2. Опублікуй мінімальні вимоги заздалегідь. Наприклад: 30 днів на сервері, мінімальний вік, доступність на тиждень.
3. Випробувальний строк. Чотири тижні з обмеженими дозволами, потім свідоме рішення.
4. Відмова це відмова з причиною. Одного речення достатньо, але воно має бути.

Пункт 3 найважливіший, і його пропускають найчастіше. Випробувальний строк дає природний вихід, за якого ніхто не втрачає обличчя.

Неактивність вирішуй наперед, а не потім

Це найнеприємніша частина, і тому майже всі її відкладають.

Член команди, який три місяці нічого не робив, займає місце й демотивує тих, хто працює. Проблема лише в тому, що без правила кожна розмова про це сприймається як особистий напад.

Запиши правило ще до того, як воно знадобиться. Наприклад:

Кожен член команди опрацьовує щонайменше 10 звернень підтримки на місяць. Хто нижче цього, отримує повідомлення. Хто й наступного місяця нижче, повертає роль.

Дві речі роблять це прийнятним:

Нормальний спосіб повідомити про відсутність. Відпустка, іспити, хвороба. Хто повідомив про відсутність, на цей час не вважається неактивним. Без такого шляху правило несправедливе, і його обходять.

Попередження замість зняття. Перше відставання це повідомлення, а не покарання. Майже всі після цього знову беруться до справи.

Якщо хочеш це автоматизувати: AlphaCloud рахує разом із тобою через записи підтримки або опрацьовані тікети й сам надсилає попередження через перевірку активності. Учасників, що повідомили про відсутність, пропускають.

У попереджень має бути строк дії

Та сама логіка діє і всередині команди. Коли член команди один раз помиляється й отримує попередження, воно не має стояти вічно.

Попередження, яке ніколи не закінчується, означає, що хтось, хто схибив два роки тому, постійно за крок від зняття. Це ані справедливо, ані корисно.

Задай строк, наприклад 90 днів без нового попередження, і після цього нехай рівень спливає.

Роби рішення видимими

Два канали журналів, які варто мати:

• Публічний: набір, підвищення, відходи. Це визнання, і заодно воно відповідає на запитання «хто взагалі в команді».
• Внутрішній: попередження, блокування, нотатки. Лише для керівництва.

Розділення і є суттю. Спільнота має бачити підвищення, але не кожне внутрішнє обговорення щодо нього.

Список команди, який підтримує себе сам

Закріплене повідомлення з переліком усіх членів команди через чотири тижні вже неправильне. Або ти щотижня оновлюєш його вручну, або дозволяєш йому генеруватися з ролей.

Останнє єдиний варіант, який залишається правильним. Побічний ефект: коли хтось іде з команди, він автоматично зникає зі списку, і нікому не треба про це пам'ятати.

Частина, яку не розв'яже жодна програма

Команда працює або провалюється на трьох речах, для яких немає перемикача:

Ясність щодо того, хто вирішує. Коли два модератори ухвалюють суперечливі рішення, справа майже ніколи не в них, а в тому, що ніхто ніколи не сказав, за ким останнє слово в суперечці.

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

Вихід. Більшість людей ідуть із команди не зі злості, а тому, що змінюється життя. Якщо піти означає стати зрадником, люди не йдуть, вони просто стають неактивними. І тоді ти знову повертаєшся до проблеми з самого початку.