मल्टीप्लेयर रूम

v2.7.0 में नया

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

तीन तरह के रूम:

नॉर्मिंग रूम क्यों

एनोटेशन टीमें पहले से ही स्क्रीन-शेयर पर नॉर्मिंग बैठकें करती हैं, और नतीजे किसी के नोट्स में पड़े रह जाते हैं। रूम इस सत्र को टूल का हिस्सा बना देते हैं और उसे मापने लायक बनाते हैं।

• पहले ब्लाइंड। खुलासे से पहले सदस्य देख सकते हैं कि किसने वोट दिया, पर कभी नहीं कि क्या वोट दिया। यह सर्वर की तरफ़ लागू होता है, इसलिए पहली राय सचमुच स्वतंत्र रहती है।
• खुलासा अपने आप में एक माप है। खुलासे के बाद ब्लाइंड वोट अपरिवर्तनीय हो जाते हैं। खुलासे के बाद हर बदलाव इस विवरण के साथ दर्ज होता है कि सदस्य ने किससे किसमें बदला और उस क्षण बहुमत क्या था, जिससे आपको प्रति-सदस्य अनुरूपता का रिकॉर्ड मिल जाता है।
• α मीटर बताता है कि “क्या यह सार्थक था?” Krippendorff's α खोले जा चुके आइटमों पर दो बार गणना होता है: ब्लाइंड वोटों पर, और मौजूदा वोटों पर। इन दोनों का अंतर ही सत्र की नॉर्मिंग बढ़त है, जो होते-होते स्क्रीन पर दिखती है।

कॉन्फ़िगरेशन

rooms:
  enabled: true
  who_can_create: any      # "any" logged-in user, or "admin" only
  persist_votes: true      # final votes write into members' annotation state
  poll_interval_ms: 1500   # client sync cadence (500–30000)
  max_members: 12          # per room (2–100)
  schema: sarcasm          # optional; defaults to the first radio/likert scheme

रूम एक ही एकल-विकल्प योजना (radio या likert) पर वोट करते हैं। यदि schema सेट नहीं है, तो annotation_schemes में मौजूद पहली ऐसी योजना ली जाती है।

सत्र चलाना

1. सर्वर शुरू करें, लॉग इन करें, और /rooms खोलें।
2. एक रूम बनाएँ (प्रकार और आइटम संख्या)। उसे MKT4QP जैसा छह-अक्षरों वाला कोड मिलता है। कोड में मिलते-जुलते अक्षर नहीं आते, इसलिए आप उन्हें बोलकर बता सकते हैं।
3. बाक़ी लोग लॉबी सूची से जुड़ते हैं, या /rooms/<CODE> खोलकर।
4. वोट दें, होस्ट खुलासा करे, साइड चैट में चर्चा करें, राज़ी होने पर वोट बदलें, और होस्ट आगे बढ़ाए। आख़िरी आइटम के बाद रूम एक सत्र सारांश के साथ बंद हो जाता है, और होस्ट पूरा इवेंट लॉग डाउनलोड कर सकता है।

Huddle

बनाते समय Huddle चुनने पर रूम में हर वह आइटम भर जाता है जिस पर एनोटेटर रूम की योजना को लेकर अभी असहमत हैं, अधिकतम 200 तक। मूल एनोटेशन वोट पैनल के ऊपर संदर्भ के रूप में दिखती हैं। असहमतियाँ एनोटेशन स्थिति से लाइव गणना की जाती हैं, इसलिए अधिनिर्णय उपप्रणाली को सक्रिय करने की ज़रूरत नहीं।

Shadow सत्र

Shadow रूम में होस्ट को छोड़कर बाक़ी सब पर्यवेक्षक के रूप में जुड़ते हैं। पर्यवेक्षक वोट नहीं दे सकते, पर वे होस्ट के वोट, खुलासे और टेक्स्ट चयन लगभग 1.5 सेकंड की देरी से देखते हैं। होस्ट का मौजूदा चयन पर्यवेक्षकों की स्क्रीन पर अंबर रंग में हाइलाइट होता है।

स्थायित्व और क्रैश रिकवरी

हर रूम इवेंट-सोर्स्ड है। हर बदलाव (जुड़ना, वोट, खुलासा, परिवर्तन, संदेश, आगे बढ़ना, बंद करना) इस फ़ाइल में एक JSON पंक्ति जोड़ता है:

<output_annotation_dir>/rooms/room-<CODE>.jsonl

रूम की स्थिति उसी लॉग का शुद्ध रीप्ले है, इसलिए चालू रूम सर्वर के पुनरारंभ के बाद भी बचे रहते हैं। यह लॉग सत्र का ऑडिट ट्रेल भी है: ब्लाइंड वोट, टाइमस्टैम्प, चर्चा, और खुलासे के बाद हर बदलाव अपने बहुमत-संदर्भ के साथ। GET /rooms/api/<CODE>/export (होस्ट या एडमिन) लॉग के साथ गणना किए गए मेट्रिक JSON के रूप में लौटाता है।

persist_votes: true (डिफ़ॉल्ट) के साथ, खोले गए आइटम पर हर सदस्य का अंतिम वोट होस्ट के आगे बढ़ाने पर उसकी नियमित एनोटेशन स्थिति में लिख दिया जाता है। रूम में किया गया काम असली एनोटेशन के रूप में गिना जाता है और हर मौजूदा निर्यात पथ में बहकर आता है।

क्लाइंट एक कर्सर के साथ /events को पोल करके सिंक्रनाइज़ होते हैं। कोई WebSocket नहीं है, इसलिए रूम थ्रेडेड डेव सर्वर और किसी भी WSGI डिप्लॉयमेंट, दोनों पर काम करते हैं।

API सारांश

आगे पढ़ें

• Psychometrics — प्रति-एनोटेटर क्षमता और आइटम कठिनाई; यह जिन कोडबुक समस्याओं को चिह्नित करता है, उन्हें रूम में ही सुलझाया जाता है
• अधिनिर्णय और असहमति — huddle का असिंक्रोनस समकक्ष
• एनोटेशन दिशानिर्देश लिखना
• स्रोत दस्तावेज़