चेतावनियाँ, रिपोर्ट और मॉडरेशन लॉग

परिचय

हर मॉडरेशन फ़ैसला तुरंत बैन में नहीं बदलना चाहिए। कोई सदस्य अगर एक बार नियम तोड़ता है, तो शायद उसे सिर्फ़ हल्की याद दिलाने की ज़रूरत हो; लेकिन जो सदस्य बार-बार नियम तोड़ता रहे, उसके लिए साफ़ और पहले से अनुमानित परिणाम होना चाहिए। ये सुविधाएँ admins को व्यवहार संभालने का एक क्रमिक तरीका देती हैं — एक चेतावनी-सीढ़ी, जो बार-बार गलती होने पर ही बैन तक पहुँचती है; सामान्य सदस्यों के लिए खराब संदेशों को admins के ध्यान में लाने का तरीका; और एक निजी लॉग, जिसमें मॉडरेशन सिस्टम ने क्या किया, उसका रिकॉर्ड रहता है।

हर सुविधा डिफ़ॉल्ट रूप से बंद रहती है और तब तक कोई कार्रवाई नहीं करती जब तक कोई admin उसे समूह डैशबोर्ड में सक्षम न करे। bot चालू करने से चुपचाप किसी को चेतावनी देना या बैन करना शुरू नहीं होता।

चेतावनी-सीढ़ी

चेतावनी-सीढ़ी admins को किसी सदस्य को strikes देने देती है। जब strike की संख्या तय सीमा तक पहुँच जाती है, तो सदस्य अपने-आप बैन हो जाता है और उसकी गिनती रीसेट हो जाती है। इसे दो settings नियंत्रित करती हैं:

• set_warnings_enabled — चालू/बंद स्विच। डिफ़ॉल्ट रूप से बंद।
• set_warn_limit — इतने strikes होने पर बैन होता है। डिफ़ॉल्ट 3।

तीन केवल-admin commands strikes को संभालते हैं:

• /warn — एक strike दें। सदस्य के संदेश का reply करें, या उसका numeric id या @handle दें। आप चाहें तो एक वैकल्पिक कारण भी जोड़ सकते हैं, जैसे /warn @user spamming links।
• /unwarn — किसी सदस्य से एक strike हटाएँ, अगर चेतावनी गलती से दे दी गई हो।
• /warns — देखें कि किसी सदस्य के पास सीमा में से अभी कितने strikes हैं।

जब कोई /warn किसी सदस्य को सीमा तक पहुँचा देता है — उदाहरण के लिए, डिफ़ॉल्ट सीमा 3 होने पर उसका तीसरा strike — तो bot उसे बैन कर देता है और उसकी strike गिनती साफ़ कर देता है। सीमा से नीचे होने पर, bot नया strike रिकॉर्ड करता है और मौजूदा गिनती के साथ reply करता है, ताकि admin और सदस्य दोनों देख सकें कि स्थिति क्या है। command message खुद processing के बाद हटा दिया जाता है, जिससे दिखाई देने वाली chat साफ़ रहती है।

ये तीनों commands केवल admins के लिए हैं। अगर कोई सामान्य सदस्य इन्हें चलाता है, तो उसे मना कर दिया जाता है, और कोई भी खुद को warn नहीं कर सकता।

सदस्य रिपोर्ट

Reports सामान्य सदस्यों को admins के ध्यान के लिए किसी message को flag करने देती हैं। यह जानबूझकर सदस्य-केंद्रित सुविधा है, admin-केंद्रित नहीं: chat पढ़ रहे लोग अक्सर किसी समस्या को सबसे पहले नोटिस करते हैं। इसे एक ही setting नियंत्रित करती है:

• set_reports_enabled — चालू/बंद स्विच। डिफ़ॉल्ट रूप से बंद।

किसी message को report करने के लिए, सदस्य उस पर reply करता है और /report भेजता है, चाहें तो साथ में छोटा-सा कारण भी जोड़ सकता है। bot समूह में एक notice पोस्ट करता है ताकि admins देख सकें कि कौन-सा message flag किया गया और किसने किया, और अगर moderation log सेट है तो report को उसमें रिकॉर्ड करता है।

दो नियम reports को परेशानी बनने से रोकते हैं:

• Rate limiting. हर सदस्य हर 30 seconds में सिर्फ़ एक बार report कर सकता है। उस समय-सीमा के भीतर दोहराई गई reports चुपचाप ignore कर दी जाती हैं, ताकि कोई भी admins को report notices से spam न कर सके।
• साफ़ chat. /report command message handling के बाद हमेशा delete कर दिया जाता है, चाहे report आगे जाए या नहीं, ताकि flag की गई बातचीत report commands से भरे नहीं।

Report अपने-आप किसी को सज़ा नहीं देती। यह admins के लिए एक संकेत है, जिसके बाद वे तय करते हैं कि warn करना है, mute करना है, ban करना है, या कोई कार्रवाई नहीं करनी है।

मॉडरेशन लॉग

मॉडरेशन लॉग moderation system की कार्रवाइयों को एक अलग channel में mirror करता है, ताकि admins के पास समूह को real time में देखे बिना लगातार record रहे। इसे एक setting नियंत्रित करती है:

• set_modlog_channel_id — उस channel का numeric id जिसे log मिलता है। इसे group admin dashboard में Auto-Moderation section के तहत सेट करें। इसे खाली छोड़ना (डिफ़ॉल्ट) log को disable करता है।

जब channel id सेट होता है, bot moderation events के होते ही उनके लिए एक-line entry पोस्ट करता है। इनमें जारी की गई warnings, bans (warning-limit bans और दूसरे automated bans, जैसे किसी banned known abuser को ban करना), member reports, और raid lockdowns शामिल हैं। हर entry में action का नाम, संबंधित member, और उसे करने वाला admin या system बताया जाता है।

Log के काम करने के लिए, bot को target channel का admin होना ज़रूरी है — इसी से वह वहाँ post कर सकता है। अगर bot channel का admin नहीं है, तो log entries deliver नहीं की जा सकतीं। Log best-effort है: किसी एक entry को post करने में failure moderation action को कभी block नहीं करता; वह कार्रवाई group में फिर भी होती है।

ये सुविधाएँ साथ मिलकर कैसे काम करती हैं

ये तीनों सुविधाएँ एक-दूसरे की पूरक हैं। Reports सदस्यों को समस्याएँ सामने लाने देती हैं। चेतावनी-सीढ़ी admins को संतुलित ढंग से प्रतिक्रिया देने देती है, और escalation तभी होता है जब कोई सदस्य रुकता नहीं। मॉडरेशन लॉग दोनों को record करता है, जिससे admin team के पास क्या हुआ और किसने कार्रवाई की, इसका साझा इतिहास रहता है। आम setup यह है कि तीनों को enable किया जाए: सदस्य report करते हैं, admins warn करते हैं, और सब कुछ review के लिए log channel में पहुँचता है।

सर्वोत्तम अभ्यास

• warning limit को अपनी community की tolerance के अनुसार सेट करें। 3 की limit सदस्यों को ban से पहले दो मौके देती है; उदार group के लिए इसे बढ़ाएँ, सख्त group के लिए घटाएँ।
• offending message पर reply करके /warn जारी करना बेहतर है — इससे सही सदस्य target होता है और गलत id type होने की संभावना सबसे कम रहती है।
• ban decision से पहले /warns का उपयोग करें, ताकि यह पता चले कि सदस्य repeat offender है या पहली बार गलती कर रहा है।
• एक private moderation-log channel बनाएँ, वहाँ bot को admin के रूप में add करें, और dashboard में उसका id सेट करें ताकि आपकी team के पास audit trail रहे।
• बड़े groups में reports enable करें जहाँ admins हर message नहीं पढ़ सकते; सदस्य एक अतिरिक्त निगरानी-टीम की तरह काम करते हैं।

सारांश

Warnings, reports और moderation log मॉडरेशन को अलग-अलग bans की श्रृंखला से बदलकर एक system बना देते हैं। सदस्य /report से समस्याएँ flag करते हैं, admins /warn, /unwarn, और /warns से क्रमिक strikes देते हैं, कोई सदस्य configured limit तक पहुँचने के बाद ही अपने-आप ban होता है, और जब log channel configured हो तो हर action वहाँ mirror होता है। यह सब तब तक बंद रहता है जब तक कोई admin इसे enable न करे, और warning commands केवल admins तक सीमित रहते हैं।