यादृच्छिक ड्रॉ का कोई मूल्य नहीं है अगर कोई यह विश्वास न करे कि वह यादृच्छिक था। परिणाम पूरी तरह निष्पक्ष हो सकता है, लेकिन जिस प्रक्रिया पर लोग भरोसा नहीं करते वह फिर भी आपकी विश्वसनीयता खर्च करती है — और आपत्ति उठाने वाले सबसे ज्यादा वही होते हैं जो हारे हैं।
आवश्यकताएँ छोटी हैं। ज्यादातर असफलताएँ किसी खराब टूल से नहीं, बल्कि इनमें से कोई एक आवश्यकता छूट जाने से होती हैं।
निष्पक्षता पर मेहनत क्यों बनती है
ड्रॉ पर विवाद होने पर तीन चीजें होती हैं। प्रक्रिया पर भरोसा घटता है, जिसका असर हर भावी प्रतियोगिता पर पड़ता है। विजेता को परिणाम चाहे जो भी हो, अनुचित लग सकता है। और लोग अगली बार प्रवेश करने से हिचकते हैं, क्योंकि उन्हें भागीदारी सार्थक नहीं लगती।
इसमें से कुछ भी विजेता के बारे में नहीं है। यह इस बारे में है कि कोई आपके साथ दूसरी प्रतियोगिता चलाएगा या नहीं।
चार आवश्यकताएँ
1. एक निश्चित, प्रकाशित पूल। हर पात्र प्रतिभागी, नाम के साथ, उसी स्थिति में जिसमें प्रविष्टियाँ बंद होते समय थीं। संख्या नहीं — सूची। लोग संख्या को दावा मानते हैं और सूची को सबूत।
2. एक घोषित विधि। “सभी योग्य प्रविष्टियों में से एक समान रूप से एक विजेता।” अगर आपके नियम अतिरिक्त प्रविष्टियों की अनुमति देते हैं, तो यह बताएँ और बताएँ कि उनका भार कैसे तय होता है। भारित राफल ठीक इसी कारण भार को स्पष्ट करता है।
3. एक ऐसा स्रोत जिसका पहले से अनुमान न लगाया जा सके। घुमाई जाती बोतल और एक व्यक्ति द्वारा चलाया गया स्प्रेडशीट फॉर्मूला दोनों पक्षपाती लगते हैं, भले ही हों नहीं। यह वह आवश्यकता है जिसमें ज्यादातर टूल चूकते हैं: Math.random() नियतात्मक है, इसलिए सिद्धांत रूप में इसके आउटपुट से अगला परिणाम भविष्यवाणी की जा सकती है। एक क्रिप्टोग्राफिक स्रोत ऐसा नहीं कर सकता। निष्पक्षता पृष्ठ इस अंतर को समझाता है।
4. पूल दिखते हुए एक रिकॉर्ड। एक स्क्रीनशॉट या रिकॉर्डिंग जिसमें प्रतिभागी सूची और परिणाम एक ही फ्रेम में दिखें।
यही पूरा सेट है। इससे लंबा कुछ भी औपचारिकता है।
इसे चलाना
सूची ध्यान से बनाएँ। सबसे आम असफलता एक साधारण चूक है — कोई कमेंट थ्रेड जो छूट गया, कोई स्रोत जो आप भूल गए कि आपके पास था। अगर प्रविष्टियाँ एक से ज्यादा जगह से आई हैं, तो ड्रॉ से पहले सब जोड़ लें, न कि जो मौजूद है उसी से ड्रॉ कर लें।
पहले डुप्लिकेट हल करें। “Mark Smith”, “mark smith” और “Mark Smyth” एक व्यक्ति हैं या तीन, और ड्रॉ से पहले आपको यह तय कर लेना चाहिए। अगर आपके नियम कई प्रविष्टियों की अनुमति देते हैं, तो यह डुप्लिकेट का नहीं, भार का सवाल है — उन्हें रखें और भार का उपयोग करें, या अगर नियम प्रति व्यक्ति एक प्रविष्टि कहते हैं तो डुप्लिकेट-रोकथाम चालू करें।
शुरू करने से पहले सूची दिखाएँ। सबको रीयल टाइम में नहीं — उसे जिसे बाद में फर्क पड़ेगा। बात यह है कि ड्रॉ से पहले किया गया सुधार अदृश्य रहता है और बाद में किया गया सुर्खी बन जाता है।
कई पुरस्कारों के लिए “Remove Winner” का उपयोग करें। यह आपको कई बार ड्रॉ करने देता है बिना वही नाम दोबारा आए, और हर ड्रॉ को स्पष्ट रूप से निष्पक्ष बनाता है, न कि सिर्फ पहले को।
ड्रॉ शुरू होने से पहले से रिकॉर्ड करें। बाद में रिकॉर्डिंग शुरू करने से बिना संदर्भ के परिणाम कैद होता है, जो बिना रिकॉर्डिंग से भी बुरा है क्योंकि वह सबूत जैसा दिखता है।
किन बातों से बचें
बोतल घुमाना। किसी भी अर्थपूर्ण तरीके से पक्षपाती नहीं, और हर जगह पक्षपाती पढ़ा जाता है। इसका कोई ऐसा रूप नहीं जो हठी आपत्तिकर्ता को मनाए।
टोपी से नाम। बाद में सत्यापित करना वाकई मुश्किल, और यह साबित करना असंभव कि किसी ने देखा नहीं।
एक व्यक्ति द्वारा चलाया गया स्प्रेडशीट फॉर्मूला। सांख्यिकीय रूप से उपयुक्त, और पूरी तरह असत्यापनीय — जो इसे चलाता है वही इनपुट नियंत्रित करता है और कोई और इसे जाँच नहीं सकता।
नापसंद परिणाम को दोबारा चलाना। यही वह चीज है जो सचमुच भरोसे को नुकसान पहुँचाती है, क्योंकि यह एक यादृच्छिक प्रक्रिया को पसंदीदा जवाब की खोज में बदल देती है, और देखने वाले हर व्यक्ति को यह होते दिख जाता है। अगर सचमुच कोई गलती हुई थी, तो सार्वजनिक रूप से सुधारें और दोबारा चलाएँ, कारण बताते हुए।
ड्रॉ के बीच में सूची हाथ से बदलना। ड्रॉ शुरू होने के बाद किया गया हर बदलाव आलोचक के इशारे का निशाना बनता है। शुरू करने से पहले सूची साफ करें।
दृश्यता कहाँ मदद करती है
इसे स्क्रीन-शेयर करें। लाइव ड्रॉ के लिए यह अकेली सबसे कीमती आदत है। जिस ड्रॉ को किसी ने देखा नहीं, वह धोखे से अलग नहीं पहचाना जा सकता।

किसी और को इसे चलाने दें। अगर परिणाम से प्रभावित कोई व्यक्ति टूल चलाता है, तो बाद में उस पर किसी को बढ़ावा देने का शक नहीं किया जा सकता। यह छोटा बदलाव है जिसका परिणाम पेश होने के तरीके पर बड़ा असर होता है।
रिकॉर्डिंग माँगे जाने पर नहीं, प्रकाशित करें। इसे प्रकाशित करना शिकायत को पहले ही काट देता है। माँगे जाने पर देने से यह सवाल उठता है कि और क्या है जो आप प्रकाशित नहीं कर रहे।
तरीका जितना आप सोचते हैं उससे कम मायने रखता है
ज्यादातर लोग मानते हैं कि टूल का चुनाव परिणाम तय करता है। ऐसा नहीं है — अनुमानित स्रोत से ड्रॉ और क्रिप्टोग्राफिक स्रोत से ड्रॉ दोनों एक नाम देते हैं, और कोई उनमें फर्क नहीं बता सकता।
जिसमें लोग फर्क बता सकते हैं वह यह है कि पूल दिख रहा था या नहीं, विधि नियमों से मेल खाती थी या नहीं, और चलाने वाले को कुछ बदलने का कोई मौका मिला या नहीं। विवाद हर बार यहीं से आते हैं।
इसलिए मेहनत रिकॉर्ड पर खर्च करनी चाहिए, और टूल का चुनाव एक बार सिद्धांत पर करना चाहिए, न कि बार-बार चिंता में।
क्लासरूम संस्करण
वही चार आवश्यकताएँ एक छात्र चुनने पर लागू होती हैं, कम दाँव के साथ।
पूल निश्चित — आपकी सहेजी हुई क्लास सूची, अनुपस्थित छात्रों को हटाकर। विधि घोषित — हर कोई समान रूप से संभावित। स्रोत ठोस — एक क्रिप्टोग्राफिक जनरेटर, फॉर्मूला नहीं। रिकॉर्ड उपलब्ध — अगर कोई अभिभावक पूछे तो एक स्क्रीनशॉट।
यह “आपको कैसे पता कि यह सचमुच यादृच्छिक है?” का जवाब देने का एक उचित तरीका है, बिना अधिकार का सहारा लिए।
परिणाम की घोषणा
विजेता, योग्य प्रविष्टियों की संख्या, और रिकॉर्डिंग प्रकाशित करें। फिर विजेता से निजी तौर पर संपर्क करें और वह समय-सीमा बताएँ जो आपने पहले नियमों में कही थी।
पहले से तय करें कि अगर वे जवाब न दें तो क्या होगा। दोबारा ड्रॉ और अयोग्य ठहराना दोनों ही बचाव योग्य हैं; बाद में अपनी सुविधा के अनुसार जो नियम चाहे उसे लागू करना नहीं है।
और जीत की जरूरत से ज्यादा व्याख्या न करें। विजेता का नाम लेकर रिकॉर्डिंग लिंक करने वाली छोटी पोस्ट आत्मविश्वास जैसी पढ़ती है। लंबा औचित्य बचाव जैसा पढ़ता है, और उसी सवाल को न्योता देता है जिसे वह निपटाना चाहता था।
शुरू करना
लकी ड्रॉ खोलें, सूची पेस्ट करें, और बटन दबाने से पहले रिकॉर्ड करना शुरू करें।
ड्रॉ में दो सेकंड लगते हैं। जो कुछ इसे बचाव योग्य बनाता है, वह सब पहले और बाद में होता है।