Skip to main content
Poradniki
PoradnikiTeamModeration

Jak zbudować zespół moderacji na Discordzie: struktura, która wytrzyma 2000 członków

Większość zespołów nie rozpada się przez złych ludzi, tylko przez brak zasad dotyczących rekrutacji, uprawnień i nieaktywności. Poradnik z praktyki.

Opublikowano autor: AlphaCloud4 min czytania

Każdy rosnący serwer dochodzi do momentu, w którym jedna osoba nie jest już w stanie moderować sama. Co zwykle dzieje się wtedy: trzech znajomych dostaje uprawnienia moderatora, bo często są online. Pół roku później dwóch z nich jest nieaktywnych, nikt nie ma odwagi odebrać im roli, a trzeci jest wypalony.

To nie jest problem ludzi. To brak regulaminu.

Zacznij od uprawnień, nie od ról

Zwykła kolejność jest odwrócona. Większość najpierw tworzy role, które brzmią jak stopnie, a dopiero potem zastanawia się, co mają móc robić.

Odwróć to. Zapisz, jakie zadania naprawdę istnieją:

  • Ktoś musi usuwać spam i uspokajać kłótnie
  • Ktoś musi odpowiadać na prośby o pomoc
  • Ktoś musi decydować, kto dołącza do zespołu
  • Ktoś musi organizować wydarzenia

Dopiero potem łącz zadania w role. Zwykle wychodzi mniej ról, niż się spodziewałeś, a każda ma jasny cel.

Minimalne uprawnienia

Jedna zasada, która oszczędza sporo kłopotów: nikt nie dostaje Administratora, chyba że naprawdę musi administrować serwerem.

Do codziennej moderacji wystarczą te:

Zadanie Potrzebne uprawnienie
Usuwanie spamu Zarządzanie wiadomościami
Uspokojenie kogoś Wyciszanie członków
Usunięcie kogoś Wyrzucanie członków
Usunięcie na stałe Banowanie członków

To wszystko. Zarządzanie kanałami, Zarządzanie rolami i Zarządzanie serwerem należą do kierownictwa, nie do moderacji. Powodem nie jest nieufność, tylko ograniczanie szkód: jeśli konto zostanie przejęte, właśnie ta lista decyduje, jak źle się skończy.

Rekrutacja potrzebuje procesu

Dopóki członków zespołu rekrutuje się na wyczucie, każda odmowa staje się osobista. Ustalony proces chroni obie strony.

Proces, który się sprawdził:

  1. Podania przez formularz, nie przez wiadomość prywatną. Wtedy całe kierownictwo widzi te same informacje.
  2. Opublikuj wcześniej minimalne wymagania. Na przykład: 30 dni na serwerze, minimalny wiek, dostępność w tygodniu.
  3. Okres próbny. Cztery tygodnie z ograniczonymi uprawnieniami, potem świadoma decyzja.
  4. Odmowa to odmowa z powodem. Wystarczy jedno zdanie, ale powinno być.

Punkt 3 jest najważniejszy i najczęściej pomijany. Okres próbny daje naturalne wyjście, przy którym nikt nie traci twarzy.

Ureguluj nieaktywność wcześniej, nie potem

To najprzykrzejsza część i dlatego prawie wszyscy ją odkładają.

Członek zespołu, który od trzech miesięcy nic nie robi, blokuje miejsce i demotywuje tych, którzy pracują. Problem jest tylko jeden: bez zasady każda rozmowa o tym odbierana jest jak osobisty atak.

Zapisz zasadę, zanim będzie potrzebna. Na przykład:

Każdy członek zespołu obsługuje co najmniej 10 zgłoszeń supportu miesięcznie. Kto jest poniżej, dostaje wiadomość. Kto w kolejnym miesiącu znów jest poniżej, oddaje rolę.

Dwie rzeczy sprawiają, że da się to znieść:

Porządny sposób zgłaszania nieobecności. Urlop, egzaminy, choroba. Kto zgłosił nieobecność, w tym czasie nie liczy się jako nieaktywny. Bez tej drogi zasada jest niesprawiedliwa i będzie obchodzona.

Ostrzeżenie zamiast odebrania. Pierwsze niedociągnięcie to wiadomość, a nie kara. Prawie wszyscy potem znowu się włączają.

Jeśli chcesz to zautomatyzować: AlphaCloud liczy przez wpisy supportu albo obsłużone tickety i sam wysyła ostrzeżenie przez kontrolę aktywności. Członkowie, którzy zgłosili nieobecność, są pomijani.

Ostrzeżenia potrzebują daty ważności

Ta sama logika obowiązuje wewnętrznie. Gdy członek zespołu raz popełni błąd i dostanie ostrzeżenie, nie powinno ono wisieć na zawsze.

Ostrzeżenie, które nigdy nie wygasa, oznacza, że ktoś, kto potknął się dwa lata temu, jest na stałe o krok od usunięcia. To ani sprawiedliwe, ani przydatne.

Ustal okres, na przykład 90 dni bez nowego ostrzeżenia, i pozwól, żeby poziom potem wygasł.

Pokazuj decyzje

Dwa kanały logów, które warto mieć:

  • Publiczny: przyjęcia, awanse, odejścia. To uznanie, a przy okazji odpowiedź na pytanie "kto właściwie jest w zespole".
  • Wewnętrzny: ostrzeżenia, blokady, notatki. Tylko dla kierownictwa.

Cały sens jest w tym rozdzieleniu. Społeczność powinna widzieć awans, ale nie każdą wewnętrzną dyskusję o nim.

Lista zespołu, która utrzymuje się sama

Przypięta wiadomość ze wszystkimi członkami zespołu po czterech tygodniach jest nieaktualna. Albo aktualizujesz ją ręcznie co tydzień, albo pozwalasz jej generować się samej z ról.

To drugie to jedyna wersja, która pozostaje poprawna. Efekt uboczny: gdy ktoś odchodzi z zespołu, automatycznie znika z listy i nikt nie musi o tym pamiętać.

Część, której żadne oprogramowanie nie rozwiąże

Zespół działa albo nie z powodu trzech rzeczy, dla których nie ma przełącznika:

Jasność, kto decyduje. Gdy dwóch moderatorów podejmuje sprzeczne decyzje, prawie nigdy nie chodzi o nich, tylko o to, że nikt nigdy nie powiedział, kto ma ostatnie słowo w sporze.

Wsparcie. Moderator, który podejmie niepopularną, ale słuszną decyzję, a potem zostanie publicznie skorygowany przez kierownictwo, następnym razem nie podejmie żadnej decyzji.

Wyjście. Większość ludzi nie odchodzi z zespołu w gniewie, tylko dlatego, że zmienia się ich życie. Jeśli odejście oznacza bycie nazwanym zdrajcą, ludzie nie odchodzą, tylko stają się nieaktywni. A wtedy jesteś z powrotem przy problemie z początku.

Więcej artykułów