Podania na moderatora na Discordzie: jak śledzić podania do ekipy serwera

Większość serwerów zbiera podania do ekipy przez Formularz Google albo bota do ticketów. Zbieranie to łatwa część. Bałagan zaczyna się później: które podania ktoś już przeczytał, kto z kim robi rozmowę i czy ktokolwiek odpisał osobie, która złożyła podanie w marcu?

Ten poradnik konfiguruje tracker podań, z którego ekipa korzysta na Discordzie. Nie zastępuje formularza, który wypełniają członkowie (więcej o tym niżej). To proces oceny, który przychodzi potem.

Jak wygląda tracker

Jeden wiersz na podanie, z kolumnami:

• kandydat (członek Discorda, wymagana)
• rola, na którą składa podanie (tekst, wymagana)
• status (Submitted, Under Review, Interview, Accepted, Rejected; wymagana)
• data złożenia
• osoba oceniająca (członek Discorda)
• notatki

To szablon Podania w CordBase, który sami tworzymy. Ten poradnik buduje go jednak ręcznie, z jedną dodatkową kolumną, z powodu wyjaśnionego w kroku 1.

Krok 1: utwórz tabelę

1. Zaloguj się przez Discorda na cordbase.gg, wybierz serwer i dodaj bota, gdy pojawi się prośba.
2. Utwórz tabelę o nazwie „Apps” z kolumną tekstową imię kandydata na początku, a po niej sześcioma kolumnami z listy wyżej. Komenda będzie się nazywać /apps.

Po co dodatkowa kolumna: gdy ekipa wybiera wiersz do aktualizacji, CordBase przeszukuje i wyświetla wiersze według pierwszej kolumny tekstowej tabeli. W szablonie to „rola, na którą składa podanie”, więc dziesięć podań na moderatora pokazałoby się jako dziesięć identycznych pozycji „Moderator”. Kolumna z imieniem na początku sprawia, że każdy wiersz łatwo znaleźć.

Krok 2: ogranicz dostęp do ekipy

Podania są w miarę prywatne, więc ustaw uprawnienia, zanim ktokolwiek zacznie z nich korzystać:

• Rola ekipy dostaje Zapis (dodawanie i aktualizowanie wierszy).
• Rola admina albo głównego moderatora dostaje Admin (do tego usuwanie).
• Żadnej innej roli nie dawaj poziomu. Gdy w tabeli ustawisz choć jedną rolę, członkowie bez żadnej z tych ról w ogóle nie mogą z niej korzystać, i właśnie o to tu chodzi.

Upewnij się też, że kanał, na którym ekipa uruchamia te komendy, jest tylko dla ekipy. Wyniki query, view, add i update pojawiają się na kanale, na którym uruchomiono komendę, więc każdy, kto widzi ten kanał, widzi też je. Prywatne są tylko błędy i potwierdzenia usunięcia.

Krok 3: zapisuj podania na bieżąco

Gdy przychodzi podanie, ktoś z ekipy je zapisuje:

/apps add applicant_name:Rin applicant:@Rin role_applied:Moderator status:Submitted submitted_date:2026-10-08

Krok 4: obsługuj kolejkę

• /apps query status:Submitted pokazuje wszystko, czego nikt jeszcze nie wziął.
• /apps query reviewer:@Sam pokazuje kolejkę Sama.
• /apps update row:Rin status:Interview reviewer:@Sam notes:Interview Fri 8pm przesuwa podanie dalej. Zacznij wpisywać imię kandydata w row i wybierz je z listy.

Kolejka jest w tabeli, więc nic nie zależy od tego, czy ktoś pamięta, które odpowiedzi z formularza już przeczytał.

Gdzie w tym wszystkim formularz

CordBase sam nie zbiera odpowiedzi z podań; członkowie nie wypełniają przez niego formularza. Dalej używaj tego, co zbiera odpowiedzi (Formularza Google, bota do ticketów albo bota do podań, który zadaje pytania w DM), a trackera używaj do statusu. Kolumna z notatkami to dobre miejsce na link do pełnej odpowiedzi.

Po zakończeniu naboru

• Wyeksportuj tabelę do CSV albo JSON, co przydaje się przy podsumowaniu kadencji.
• Odrzucone i przyjęte wiersze mogą zostać jako historia albo admin może je usunąć. Usunięte wiersze są trwale kasowane po 30 dniach.
• Plan Free mieści 100 wierszy na tabelę, co na większości serwerów wystarczy na wiele naborów. Pro podnosi to do 10 000.