Designing the application form
फ़ॉर्म एक screening tool है जो किसी human reviewer के कुछ पढ़ने से पहले चलता है। हर field एक trade-off है: यह या तो आपकी आवेदन तुलना करने की क्षमता में सुधार करता है या friction जोड़ता है जो आपको अच्छे submissions खो देता है। fields की सही संख्या अधिकांश ऑर्गनाइज़र्स की सोच से कम है।
वे fields जो लगातार अपनी जगह कमाते हैं:
• Talk शीर्षक और 100-200 शब्दों का abstract। talk गुणवत्ता का एकल सबसे अच्छा predictor। यदि आपके पास केवल एक field हो, तो यह होगा।
• तीन से पाँच learning outcomes या "ऑडियंस क्या लेकर जाएगी"। applicant को topic के बजाय value articulate करने के लिए मजबूर करता है।
• Format वरीयता (talk, workshop, panel, lightning) और लंबाई।
• एक निश्चित सूची से Track या theme चयन।
• Speaker bio (एक paragraph, साथ ही optional लंबा version)।
• पिछली talks के एक या दो links (video preferred, deck या transcript acceptable)।
• Logistical fields: location, travel की willingness, आवास आवश्यकताएँ, accessibility आवश्यकताएँ।
विशिष्ट कारण न होने पर drop करने योग्य fields: deck का पूरा draft, पूरा talk script, तीन references, अलग angles से वही प्रश्न पूछने वाले repeat fields, free-text "और कुछ?" boxes जिन्हें कोई नहीं पढ़ता। प्रत्येक top से मापने योग्य संख्या में senior applicants को shave करता है।
Optional fields को explicitly mark करें। Senior speakers फ़ॉर्म जल्दी भरते हैं जब वे trust करते हैं कि फ़ॉर्म बीच में उन्हें surprise नहीं करेगा।
SpeakUp पर एक structured speaker request form by default ऊपर fields capture करता है और प्रत्येक reviewer के लिए prompts के साथ आवेदनों को review queue पर route करता है।
Scoring rubrics and panel calibration
Rubric वह document है जिसे आपके reviewers हर आवेदन पढ़ते समय देखते रहना चाहिए। इसके बिना, हर reviewer अपने स्वयं के implicit model के विरुद्ध score करता है और अंतिम बैठक एक debate बन जाती है कि "अच्छा" का क्या मतलब है बजाय इसके कि कौन सी talks lineup बनाती हैं।
एक workable rubric में तीन से पाँच dimensions होते हैं, हर 1-5 scored, हर level कैसा दिखता है इसका वर्णन करने वाले एक वाक्य के साथ। सामान्य dimensions:
• Track के लिए Relevance — क्या यह talk उस track से संबंधित है जिसमें submit की गई?
• Expertise की गहराई — क्या आवेदक के पास यह talk देने का standing है?
• नवीनता — क्या परिप्रेक्ष्य ताज़ा है, या हमने इस साल तीन अन्य conferences में इस talk के संस्करण देखे हैं?
• Takeaways की स्पष्टता — क्या ऑडियंस कुछ concrete के साथ बाहर निकलेगी?
• Speaker craft — क्या पिछली talk का video room और material पर command दिखाता है?
इससे पहले कि panel स्वतंत्र रूप से समीक्षा करे, calibrate करें। तीन नमूना आवेदन चुनें (एक strong, एक borderline, एक weak) और सभी को समूह के रूप में उन्हें score करने दें। एक से अधिक point से भिन्न होने वाले किसी भी score पर चर्चा करें। ऊपर बीस मिनट का calibration बाद में तीन घंटे का debate रोकता है।
Review के दौरान हर आवेदन के पास rubric को visible रखें। Reviewers को score करने और screen छोड़े बिना एक-line note जोड़ने में सक्षम होना चाहिए।
Reviewing applications efficiently
पचास आवेदनों, तीन reviewers, और ऊपर rubric पर, आप panel में लगभग छह से आठ घंटे का review time देख रहे हैं — साथ ही एक final selection बैठक। संरचना जो इसे manageable रखती है:
• न्यूनतम प्रति आवेदन दो reviewers, borderline cases के लिए तीन। एक reviewer assignment है; दूसरा pass उन cases को पकड़ता है जहाँ एक अकेला reviewer एक खराब दोपहर बिता रहा था।
• track-batched order में review करें, submission order में नहीं। एक के बाद एक पंद्रह distributed-systems abstracts की तुलना करना scoring को कहीं अधिक consistent बनाता है बजाय एक distributed-systems abstract, फिर एक frontend, फिर एक leadership पढ़ने के।
• Review session की लंबाई को नब्बे मिनट पर cap करें। उसके बाद score quality तेज़ी से गिरती है। एक हफ़्ते में तीन नब्बे-मिनट sessions एक पूरे दिन के marathon को outperform करते हैं।
• एक ऐसा tool इस्तेमाल करें जो reviewers को एक-दूसरे के scores केवल अपने submit करने के बाद देखने दे — anchoring bias real और well-documented है।
• Review phase में flag करें, debate नहीं। Reviewers एक छोटा note जोड़ते हैं जब किसी आवेदन को panel discussion की ज़रूरत होती है। Debate को calibration meeting के लिए बचाएँ जहाँ हर किसी के सामने rubric है।
एक panel जो दो हफ़्ते में round खत्म करता है और एक जो इसे छह हफ़्ते तक खींचता है के बीच का अंतर लगभग पूरी तरह इस पर है कि review tooling लोगों को logistics के बजाय judging पर focus करने देता है या नहीं।
समर्पित speaker management software reviewer assignment, blind scoring, calibration बैठकों, और decision-letter workflow को एक ही जगह handle करता है — एक shared spreadsheet से कहीं कम brittle।
Communicating decisions
आप decisions को कैसे communicate करते हैं यह अगले पाँच साल के लिए आपके speaker relationships को set up करता है। Senior speakers rejection letters याद रखते हैं। वे विशेष रूप से submission के बाद silence याद रखते हैं।
स्वीकृत speakers के लिए, एक single email भेजें जिसमें शामिल हो: slot की पुष्टि, अगले कदम, content deadlines, contract या speaker agreement, और एक single point of contact। इसे पाँच emails में मत बाँटें। देर से content delivery का सबसे आम कारण scattered messages में दबे deadlines हैं।
Reject किए speakers के लिए, अंतिम निर्णय के 48 घंटों के भीतर एक छोटा, सम्मानजनक note भेजें। तीन वाक्य ठीक हैं। निर्णय बताएँ, submission के लिए धन्यवाद, और — अगर सच हो — note करें कि आप भविष्य के संस्करण के लिए एक submission का स्वागत करेंगे। custom rejection rationale तब तक मत लिखें जब तक आपके पास सच में हर rejected applicant के लिए ऐसा करने का समय न हो। Inconsistent feedback (कुछ को rationale मिलता है, अधिकांश को नहीं) uniform brevity की तुलना में अधिक goodwill loss पैदा करता है।
Proclaimed notification date के बाद किसी को limbo में मत छोड़ें। यदि decisions slip हो रही हैं, तो revised date के साथ एक holding email भेजें। Published date के बाद silence आपके alumni network को खोने का सबसे तेज़ तरीका है।
Building a reusable application pipeline
जिस कारण से अधिकांश ऑर्गनाइज़र हर साल अपनी CFS process को scratch से reconstruct करते हैं वह यह है कि पिछले round के अंत में कुछ भी save नहीं हुआ। Rubric किसी के Google Doc में रहती है। फ़ॉर्म एक Typeform में रहता है जिसे किसी ने duplicate और edit किया। Reviewer list पिछले साल के WhatsApp group में है।
हर round के अंत में, archive करें: कॉल का text, फ़ॉर्म संरचना, rubric, reviewer scoring history, decision letters, accepted-and-rejected applicant lists हल्के tags (track, format, region, seniority) के साथ, और क्या अच्छा गया और क्या बदलना है पर एक-page की retrospective।
अगले season, round पिछले के duplicate के साथ खुलता है, themes और dates में edits, और एक महीने के setup के बजाय एक हफ़्ते का setup। Applicant database compound होता है: इस साल reject हुए speakers को अगले साल के लिए proactively invite किया जा सकता है अगर उनका abstract अभी भी fit करता है। तीन rounds में, आप cold में speakers sourcing करना बंद करते हैं और एक pool से curate करना शुरू करते हैं जिसने पहले से intent दिखाया है।