Skip to main content
गाइड
गाइडTeamModeration

Discord मॉडरेशन टीम बनाना: ऐसा ढाँचा जो 2,000 सदस्यों पर भी टिका रहे

ज़्यादातर टीमें बुरे लोगों की वजह से नहीं बिखरतीं, बल्कि भर्ती, अनुमतियों और निष्क्रियता के नियम न होने से बिखरती हैं। अनुभव से निकली एक गाइड।

प्रकाशित लेखक AlphaCloud5 मिनट में पढ़ें

हर बढ़ता सर्वर उस मोड़ पर पहुँचता है जहाँ एक व्यक्ति अकेले मॉडरेट नहीं कर सकता। आमतौर पर तब यह होता है: तीन दोस्तों को मॉडरेटर अनुमतियाँ मिल जाती हैं क्योंकि वे बहुत ऑनलाइन रहते हैं। छह महीने बाद उनमें से दो निष्क्रिय हैं, किसी की हिम्मत नहीं होती कि रोल वापस ले, और तीसरा थककर चूर हो चुका है।

यह लोगों की कमी की समस्या नहीं है। यह एक नियम-पुस्तिका के न होने की समस्या है।

रोल से नहीं, अनुमतियों से शुरू करें

आम क्रम उल्टा है। ज़्यादातर लोग पहले ऐसे रोल बनाते हैं जो पद जैसे लगते हैं, और फिर बाद में सोचते हैं कि उन्हें क्या करने की अनुमति होनी चाहिए।

इसे पलट दें। लिखिए कि असल में कौन से काम मौजूद हैं:

  • किसी को स्पैम डिलीट करना है और बहसें शांत करनी हैं
  • किसी को सपोर्ट रिक्वेस्ट का जवाब देना है
  • किसी को तय करना है कि टीम में कौन शामिल होगा
  • किसी को इवेंट आयोजित करने हैं

उसके बाद ही कामों को रोल में बाँधें। आमतौर पर इससे आपकी उम्मीद से कम रोल बनते हैं, और हर एक का एक साफ़ मकसद होता है।

न्यूनतम अनुमतियाँ

एक नियम जो बहुत सी परेशानी बचाता है: किसी को Administrator न दें, जब तक उसे सच में सर्वर का प्रशासन न करना हो।

रोज़ के मॉडरेशन के लिए ये काफ़ी हैं:

काम ज़रूरी अनुमति
स्पैम डिलीट करना Manage Messages
किसी को शांत करना Timeout Members
किसी को हटाना Kick Members
हमेशा के लिए हटाना Ban Members

बस इतना ही। Manage Channels, Manage Roles और Manage Server नेतृत्व के लिए हैं, मॉडरेशन के लिए नहीं। वजह अविश्वास नहीं, बल्कि नुकसान को सीमित रखना है: अगर कोई अकाउंट हैक हो जाए, तो ठीक यही सूची तय करती है कि हालात कितने बुरे होंगे।

भर्ती के लिए एक प्रक्रिया चाहिए

जब तक टीम सदस्यों को अंदाज़े से चुना जाता है, हर अस्वीकृति निजी बन जाती है। एक तय प्रक्रिया दोनों तरफ़ की रक्षा करती है।

एक प्रक्रिया जो कारगर साबित हुई है:

  1. आवेदन एक फ़ॉर्म से, डायरेक्ट मैसेज से नहीं। इस तरह नेतृत्व में हर किसी को एक जैसी जानकारी दिखती है।
  2. न्यूनतम ज़रूरतें पहले से प्रकाशित करें। उदाहरण के लिए: सर्वर पर 30 दिन, एक न्यूनतम उम्र, हर हफ़्ते उपलब्धता।
  3. एक ट्रायल अवधि। सीमित अनुमतियों के साथ चार हफ़्ते, फिर एक सोचा-समझा फ़ैसला।
  4. अस्वीकृति का एक कारण होता है। एक वाक्य काफ़ी है, लेकिन वह होना चाहिए।

तीसरा बिंदु सबसे अहम है और सबसे ज़्यादा छोड़ दिया जाता है। ट्रायल अवधि आपको बाहर निकलने का एक स्वाभाविक रास्ता देती है, जिसमें किसी की बेइज़्ज़ती नहीं होती।

निष्क्रियता को बाद में नहीं, पहले से तय करें

यह सबसे अप्रिय हिस्सा है, और इसीलिए लगभग हर कोई इसे टालता रहता है।

जो टीम सदस्य तीन महीने से कुछ नहीं कर रहा, वह एक जगह घेरे रहता है और काम करने वालों का मनोबल गिराता है। समस्या बस यह है: बिना नियम के, इस बारे में हर बातचीत एक निजी हमले जैसी लगती है।

नियम ज़रूरत पड़ने से पहले लिख दें। उदाहरण के लिए:

हर टीम सदस्य हर महीने कम से कम 10 सपोर्ट केस संभालता है। जो इससे कम है उसे एक संदेश मिलता है। जो अगले महीने फिर से कम रहता है, वह रोल वापस कर देता है।

दो चीज़ें इसे सहने लायक बनाती हैं:

छुट्टी की सूचना देने का एक सही तरीका। छुट्टियाँ, परीक्षाएँ, बीमारी। जो कोई अनुपस्थिति दर्ज करता है, वह उस दौरान निष्क्रिय नहीं गिना जाता। इस रास्ते के बिना नियम अन्यायपूर्ण है और लोग उससे बचने के तरीके ढूंढ लेते हैं।

हटाने के बजाय चेतावनी। पहली कमी पर एक संदेश जाता है, सज़ा नहीं। उसके बाद लगभग हर कोई फिर से सक्रिय हो जाता है।

अगर आप इसे ऑटोमेट करना चाहते हैं: AlphaCloud सपोर्ट एंट्री या संभाले गए टिकटों के ज़रिए साथ-साथ गिनता है, और गतिविधि जांच के ज़रिए चेतावनी खुद भेजता है। जिन सदस्यों ने अनुपस्थिति दर्ज की है, उन्हें छोड़ दिया जाता है।

चेतावनियों की एक समाप्ति तारीख होनी चाहिए

यही तर्क अंदरूनी तौर पर भी लागू होता है। जब कोई टीम सदस्य एक बार गलती करता है और उसे चेतावनी मिलती है, तो वह हमेशा के लिए नहीं रहनी चाहिए।

कभी खत्म न होने वाली चेतावनी का मतलब है कि जिससे दो साल पहले चूक हुई थी, वह हमेशा हटाए जाने से एक कदम दूर है। यह न तो निष्पक्ष है और न ही उपयोगी।

एक अवधि तय करें, जैसे बिना किसी नई चेतावनी के 90 दिन, और उसके बाद स्तर को खत्म हो जाने दें।

फ़ैसलों को दिखने लायक बनाएँ

दो लॉग चैनल जो रखने लायक हैं:

  • सार्वजनिक: भर्ती, प्रमोशन, विदाई। यह सम्मान है, और साथ-साथ इस सवाल का जवाब भी देता है कि "असल में स्टाफ़ कौन है"।
  • अंदरूनी: चेतावनियाँ, रोक, नोट्स। सिर्फ़ नेतृत्व के लिए।

बँटवारा ही असली बात है। कम्युनिटी को प्रमोशन दिखना चाहिए, लेकिन उस पर हुई हर अंदरूनी चर्चा नहीं।

एक टीम सूची जो खुद को अपडेट रखती है

सभी टीम सदस्यों की सूची वाला एक पिन किया हुआ संदेश चार हफ़्ते बाद गलत हो जाता है। या तो आप उसे हर हफ़्ते हाथ से अपडेट करें, या उसे रोल से अपने आप बनने दें।

सिर्फ़ दूसरा तरीका ही सही रहता है। साइड इफ़ेक्ट: जब कोई टीम छोड़ता है तो वह सूची से अपने आप गायब हो जाता है, और किसी को याद रखने की ज़रूरत नहीं पड़ती।

वह हिस्सा जिसे कोई सॉफ़्टवेयर हल नहीं करता

एक टीम तीन चीज़ों पर चलती या गिरती है, जिनके लिए कोई स्विच नहीं है:

स्पष्टता कि फ़ैसला कौन करता है। जब दो मॉडरेटर एक-दूसरे के उलट फ़ैसले लेते हैं, तो बात लगभग कभी उनकी नहीं होती, बल्कि यह होती है कि किसी ने कभी बताया ही नहीं कि विवाद में आखिरी फ़ैसला किसका है।

साथ देना। जो मॉडरेटर एक अलोकप्रिय लेकिन सही फ़ैसला लेता है और फिर नेतृत्व उसे सबके सामने गलत ठहराता है, वह अगली बार कोई फ़ैसला ही नहीं लेगा।

बाहर निकलने का रास्ता। ज़्यादातर लोग गुस्से में टीम नहीं छोड़ते, वे इसलिए छोड़ते हैं क्योंकि ज़िंदगी बदल जाती है। अगर छोड़ने का मतलब गद्दार कहलाना है, तो लोग छोड़ते नहीं, बस निष्क्रिय हो जाते हैं। और फिर आप शुरुआत वाली समस्या पर वापस पहुँच जाते हैं।

और लेख

गाइड

Discord वेरिफ़िकेशन सेट करना: कौन सा तरीका कौन सी समस्या रोकता है

बटन, गणित का सवाल, Discord लॉगिन या बाहरी लिंक: हर तरह का वेरिफ़िकेशन कुछ अलग रोकता है। सही तरीका कैसे चुनें, और वे दो गलतियाँ जो लगभग हर सेटअप बिगाड़ देती हैं।

गाइड

एंटी-न्यूक: जब किसी एडमिन अकाउंट पर कब्ज़ा हो जाए तो क्या होता है

रेड बाहर से आता है, न्यूक अंदर से। सुरक्षा की यह परत कैसे काम करती है, यह तय नियमों के बजाय खतरों को स्कोर क्यों करती है, और यह क्या नहीं कर सकती।

गाइड

AutoMod सेट अप करना: छह फ़िल्टर और उनके पीछे की एस्केलेशन

ऑटोमैटिक मॉडरेशन शायद ही कभी पहचान में फ़ेल होता है, वह प्रतिक्रिया में फ़ेल होता है। छह फ़िल्टर कैसे काम करते हैं और कौन सी सज़ा किस उल्लंघन पर ठीक बैठती है।