सार्वजनिक रूप से लिखने की कुछ रणनीतियाँ

 (jvns.ca)
1 पॉइंट द्वारा GN⁺ 2023-08-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • सार्वजनिक तकनीकी लेखों को comments से बचने के बजाय तथ्यों, अनुभवों और सवालों के इर्द-गिर्द डिज़ाइन किया जाए, तो अनजान लोगों की प्रतिक्रियाओं को सीखने योग्य जानकारी में बदला जा सकता है
  • कंप्यूटर इस्तेमाल करने के तरीके या समस्या-समाधान के उदाहरणों जैसे जाँचे जा सकने वाले तथ्यों पर बात करने से मिलते-जुलते अनुभव, resource recommendations, छूटे हुए तथ्य, सावधानियाँ, सवाल और गलतियों की ओर इशारे ज़्यादा आते हैं
  • राय पूछने के बजाय ठोस उदाहरण और अनुभव माँगने से “DNS web management UI खराब है” जैसी राय “TLSA record supported नहीं था” जैसी जानकारी में बदल जाती है
  • पोस्ट करने के तुरंत बाद के कुछ घंटों में गलतियाँ जल्दी सुधारना, पहले से review किए गए alternatives को पहले ही लिख देना, और बार-बार दोहराई जाने वाली बहसों में जहाँ तक हो सके न खिंचना बेहतर है
  • Twitter या Mastodon जैसी जगहों पर, जहाँ following और blocking manage की जा सकती है, स्वस्थ तकनीकी बातचीत के लिए किन व्यवहारों को अनुमति नहीं देंगे इसकी सीमाएँ तय करनी चाहिए

Comments को उपयोगी बनाने का लेखन तरीका

  • सार्वजनिक writing में comments से पूरी तरह बचने के बजाय, comments ज़्यादा informative आएँ इसके लिए विषय और सवाल पूछने के तरीके को adjust किया जाता है
  • इंटरनेट comments में rude reactions भी होती हैं, लेकिन अनजान लोगों के comments से लंबे समय में बहुत कुछ सीखा जा सकता है

तथ्यों और अनुभवों को केंद्र में रखना

  • तकनीकी लेखों में मुख्य रूप से कंप्यूटर से जुड़े तथ्य या कंप्यूटर इस्तेमाल करते समय हुए अनुभवों पर बात की जाती है
  • tcpdump वाले लेख की तरह usage और पुराने use cases को साथ में कवर किया जाए, तो comments की दिशा अपेक्षाकृत ठोस रहती है
    • मिलते-जुलते या अलग usage experiences
    • दूसरे docs या resources की recommendation
    • लेख में न आए संबंधित तथ्य
    • संभावित समस्याएँ या सावधानियाँ
    • तकनीकी सवाल
    • लेख की गलतियों की ओर इशारा
  • facts-based comments आम तौर पर सामान्य flow बनाए रखते हैं
  • negative reactions भी होती हैं
    • लेख में छूटे हुए किसी option पर लोग कभी-कभी rude तरीके से react करते हैं
    • उदाहरण के लिए tcpdump का -n option default reverse DNS lookup को बंद करके IP address देखने देता है, इसलिए उपयोगी है
    • कुछ लोग गलतियों पर बहुत संवेदनशीलता से react करते हैं, इसलिए जहाँ पक्का नहीं होता वहाँ “मुझे ठीक से नहीं पता” लिखकर handle किया जाता है

समस्या-समाधान की कहानियाँ जो context बनाती हैं

  • हल की गई समस्या के बारे में कहानी अच्छी discussion को बढ़ावा देती है
  • TCP समझना क्यों ज़रूरी पड़ा, ऐसे अनुभव पर आधारित लेख की तरह, किसी खास समस्या को हल करने की प्रक्रिया share करने से comments सीखी गई बातों को बड़े context में रखने में मदद करते हैं
    • पता चल सकता है कि वही समस्या कितनी common है
    • उससे जुड़ी अक्सर आने वाली दूसरी समस्याएँ क्या हैं, यह पता चल सकता है
    • जिन दूसरे solutions पर विचार नहीं किया था, उनके बारे में पता चल सकता है
  • मुश्किल bug हल कर पाने की वजह भी किसी और का लिखा लेख पढ़ना था, इसलिए ऐसी problem-solving stories दूसरों के लिए भी महत्वपूर्ण हो सकती हैं

लेख में तकनीकी सवाल शामिल करना

  • लेख में जिन तकनीकी सवालों का जवाब नहीं पता, उन्हें सीधे पूछना या “मुझे X नहीं पता” लिखना comments का focus संकरा कर देता है
  • readers सवाल का जवाब देकर या न पता हिस्से को समझाकर आसानी से योगदान दे सकते हैं
  • सवाल शामिल करने से comments से सच में value मिलने की संभावना बढ़ती है
    • लोगों को सवालों के जवाब देना पसंद होता है
    • लेखक अपने मन का जवाब पा सकता है

गलतियाँ जल्दी सुधारना

  • ज्ञान की सीमा पर मौजूद topics को अक्सर कवर किया जाता है, इसलिए लेखों में कई mistakes हो जाती हैं
  • कोई गलती बताए तो लेख edit करके तुरंत सुधारने का तरीका अपनाया जाता है
  • publish करने के बाद कुछ घंटों तक कंप्यूटर के पास रहकर आने वाले error reports को जल्दी reflect किया जाता है
  • हर correction को errata के रूप में detail में record करने का तरीका भी है, लेकिन समय कम होने के कारण आम तौर पर लेख को ही edit किया जाता है

राय से ज़्यादा उदाहरण और अनुभव माँगना

  • Twitter या Mastodon पर लेख के बारे में अलग-अलग रायें आएँ, तो उनका कारण पूछने पर ठोस अनुभव मिल सकते हैं
  • DNS लेख पर जब किसी ने कहा कि उन्हें zone file पसंद है और DNS record management के लिए web interface पसंद नहीं, तो कारण पूछने पर जवाब मिला कि कुछ web interfaces TLSA record support नहीं करते
  • “DNS web management interface खराब है” जैसी राय की तुलना में “मैं X DNS record type इस्तेमाल करना चाहता था, लेकिन नहीं कर सका” जैसा अनुभव ज़्यादा उपयोगी जानकारी बनाता है
  • अपने लेखों में भी राय देते समय उस राय तक पहुँचाने वाला कंप्यूटर इस्तेमाल का अनुभव साथ में समझाने की कोशिश की जाती है

छोटे context से गलतफहमियाँ घटाना

  • इंटरनेट पर अनजान लोग अगर नहीं जानते कि लेखक कौन है और क्यों लिख रहा है, तो अजीब तरह से react करने की संभावना बढ़ जाती है
  • लेख की शुरुआत में छोटा writing context डालकर गलत assumptions कम किए जाते हैं
    • Mac इस्तेमाल करना शुरू किया और Linux-only software चलाना पड़ा, इसलिए असुविधा हुई — ऐसा context
    • कई और servers चलाने लगे और monitoring के बारे में सोचना पड़ा — ऐसा context
    • Linux पर पहली बार scanner इस्तेमाल करना था और डर था कि इसमें बहुत समय लगेगा — ऐसा context

उबाऊ बहसों से बचना

  • “क्या vim सीखना चाहिए”, “क्या functional programming imperative programming से बेहतर है” जैसी programming debates उबाऊ लग सकती हैं
  • जिन topics में interest नहीं है या जिन पर कोई interesting बात नहीं कह सकते, वे unwanted comment flow बना सकते हैं, इसलिए उनसे बचा जाता है
  • prediction हमेशा possible नहीं होती, लेकिन पहले बार-बार debate पैदा कर चुके flamebait topics से जहाँ तक हो सके बचा जाता है
    • उदाहरण: cryptocurrency, Tailwind, DNSSEC/DoH
  • हालांकि किसी topic में सचमुच रुचि हो, तो उसे वैसे ही cover किया जा सकता है
  • IPv6 और IPv4 जैसे कई repetitive arguments वाले topics पर भी, server को IPv6 support क्यों करना चाहिए जैसे angle से लिखने पर interesting comments आ सकते हैं

पहले से review किए गए alternatives लिख देना

  • जिन तरीकों पर पहले ही विचार किया लेकिन चुना नहीं, अगर comments में वही फिर से suggest हों तो बातचीत boring हो सकती है
  • इसलिए “X न करने का कारण A, B, C है” या “आम तौर पर X किया जाता है, लेकिन यहाँ…” जैसे छोटे notes डाले जाते हैं
  • Nix लेख में nix-shell, nix flakes, home manager जैसे जिन features को इस्तेमाल न करने का फैसला किया था, उन्हें लिखकर “flakes इस्तेमाल करने चाहिए” जैसे comments कम करने की कोशिश की गई
  • जो काम नहीं किए उन्हें लिखना readers के लिए भी मददगार है
    • Nix से पहली बार परिचित हो रहा reader nix flakes discover कर सकता है
    • यह सीख सकता है कि किसी भी “best practice” के exceptions हो सकते हैं

Social spaces में boundaries तय करना

  • Mastodon पर जब dig man page में “domain information groper” expression की ओर इशारा किया गया, तो कुछ replies ने माँग की कि साबित किया जाए कि मूल लेखक की intent aggressive थी, या समझाने की कोशिश की कि यह समस्या नहीं है
  • वह expression sexual assault को संदर्भित करने वाले व्यापक रूप से समझे जाने वाले term से जुड़ा है, इसलिए यह स्थिति है कि उसे dig man page में रखने की ज़रूरत नहीं है
  • कुछ लोगों को block किया गया और एक छोटा post लिखा गया कि ऐसी reactions और नहीं लेनी हैं
  • social media पर कभी-कभी यह तय करना महत्वपूर्ण है कि किस तरह के व्यवहार को allow नहीं करेंगे — ऐसी rules बनाना
    • लक्ष्य कुछ rude लोगों को दूर करना है
    • बाकी लोगों के लिए कंप्यूटरों के बारे में ज़्यादा स्वस्थ तरीके से बात करने की जगह बनाना है
  • यह तरीका केवल Twitter या Mastodon जैसी जगहों पर संभव है, जहाँ following को कुछ हद तक manage किया जा सकता है
  • HN, Reddit, Lobsters जैसी जगहों पर ऐसा ही करने की कोशिश नहीं की जाती
  • dig maintainers ने problem expression कई साल पहले हटा दिया था, लेकिन Mac OS में licensing कारणों से बहुत पुराना version बचा हुआ है

बहस किए बिना उपयोगी चीज़ें बचाकर रखना

  • कोई बहस छेड़े या dismissive comment करे, तो जवाब नहीं दिया जाता
  • इंटरनेट पर बहस करना पसंद नहीं है और उसमें अच्छा भी नहीं हूँ, इसलिए समय के हिसाब से यह अच्छा उपयोग नहीं है
  • अगर unexpected negative comments बहुत आ जाएँ, तो देखा जाता है कि उनमें से कुछ उपयोगी निकाला जा सकता है या नहीं
  • 80-line Go DNS resolver वाले लेख में कुछ comments को इस बात पर आपत्ति थी कि DNS packet parsing cover नहीं की गई
    • शुरुआत में DNS parsing सरल और obvious लगी थी
    • लेकिन एहसास हुआ कि जिसने पहली बार नहीं किया है, उसके लिए यह बिल्कुल obvious नहीं हो सकता
  • उन comments ने implement DNS in a weekend को कुछ हद तक inspire किया, जिसमें parsing को ज़्यादा cover किया गया, और आखिरकार DNS resolver की बेहतर explanation बनी
  • negative public criticism से emotional असर बिल्कुल नहीं होता ऐसा नहीं है, लेकिन criticism को analyze करके उसके useful हिस्से लेने की कोशिश करने वाला तरीका मददगार होता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-08-08
Hacker News की राय

  • इंटरनेट पर लिखने वाले किसी भी व्यक्ति के लिए यह वाकई अमल में लाई जा सकने वाली और तर्कसंगत सलाह है, और मेरे अनुभव से भी मेल खाती है
    फिर भी यह दुखद है कि हमने जो इंटरनेट संस्कृति बनाई है, उसकी वजह से Julia जैसी प्रतिभाशाली व्यक्ति को खुद को सेंसर करना पड़ता है और अपने लेखन का दायरा सीमित करना पड़ता है
    जैसे इस पंक्ति में है, “मेरे दिमाग में उन चीज़ों की एक अजीब सूची है जिनका ज़िक्र नहीं करना चाहिए, अगर मैं उसी विषय पर 50वीं बहस शुरू नहीं करना चाहता,” ऑनलाइन दुनिया में ऐसा व्यवहार स्वीकार और कभी-कभी पुरस्कृत भी होता है जिसे किसी अन्य सामाजिक माहौल में बर्दाश्त नहीं किया जाता
    HN, Slashdot, Twitter, Tumblr—हर जगह रूप अलग हैं, लेकिन मूल समस्या हर जगह एक जैसी लगती है

    • मुझे नहीं लगता कि यह कहना ठीक है कि वह संस्कृति हमने “बनाई” है; बल्कि इंसान लाखों वर्षों में छोटे आमने-सामने वाले समूहों के लिए विकसित हुए हैं, और अंतहीन ऑनलाइन अजनबियों से निपटने के लिए “डिज़ाइन” नहीं किए गए
      इंटरनेट पर व्यक्तिगत परिचय, भौतिक निकटता, चेहरे के भाव और बोलने का लहजा गायब हो जाते हैं, और वास्तविक प्रतिशोध का डर भी ज़्यादातर खत्म हो जाता है
    • Julia के लेख के संदर्भ में, मुझे नहीं पता कि सेंसरशिप शब्द सही है या नहीं
      उद्धृत अगले वाक्य की तरह, मुझे यह ऐसे विषय जैसा लगा जिस पर पहले ही बहुत चर्चा हो चुकी है और लोगों की राय बहुत मजबूत है, लेकिन जिसमें किसी का अपना विचार बदलना, कोई नया नजरिया रखना या कुछ सीखना मुश्किल है
      हालांकि, मुझे लगता है कि बहुत से लोग सचमुच खुद को सेंसर करते हैं जब बात ऐसी चीज़ों की हो जो भावनात्मक बहस, रूढ़ धारणाएं या downvotes ला सकती हैं—जैसे किसी community की मुख्यधारा की राय से बाहर या उसकी सीमा पर मौजूद विचार
    • मौका मिले तो लोग बाइक-शेड बहस का आनंद लेते हैं, इसलिए जिस बाइक-शेड पर आप बहस नहीं करना चाहते, उसे शुरू से उठाना ही बेहतर नहीं है
    • मुझे यह स्वाभाविक लगता है कि किसी विषय को लेकर मुझसे कहीं अधिक मजबूत भावनाएं और चर्चा करने की इच्छा रखने वाले लोग होंगे
      उदाहरण के लिए, मैंने Tailwind के साथ कुछ toy projects किए हैं और मुझे यह काफी ठीक लगा, लेकिन जो लोग काम पर किसी विशाल Tailwind project को full-time संभालते हैं, वे उन बातों से भी बहुत अधिक प्रभावित हो सकते हैं जिन्हें मैं मामूली समझकर छोड़ देता हूं, और वे उसमें कहीं अधिक समय और जुनून लगा सकते हैं
      अगर ऐसा बार-बार होता रहे, तो मैं Tailwind को उन बातचीतों में नहीं घसीटूंगा जहां Tailwind की बात नहीं चाहिए, और मुझे यह बहुत बुरा भी नहीं लगेगा
    • यह उन score-based reward systems का भी दुर्भाग्यपूर्ण परिणाम है जिन्हें platforms engagement बढ़ाने के लिए इस्तेमाल करते हैं
      कुछ विषयों को बड़े समूह हमेशा ऊपर या नीचे करते हैं, इसलिए जब भी वे विषय आएं, अगर वही comments दोहराकर स्थिर रूप से reward निकाला जा सकता है, तो ऐसा करना तर्कसंगत व्यवहार बन जाता है
      यहां reward अंततः अपने dopamine balance को adjust करना ही क्यों न हो, बात वही रहती है
      ऑफलाइन समाज में भी comments को monetize करना ज्यादा कठिन है, लेकिन popularity या elections जैसी चीज़ों में यह पूरी तरह अनुपस्थित नहीं है

  • “मुझे ठीक से नहीं पता” कहकर बेकार की बहसों से बचने और उपयोगी जवाब निकालने की रणनीति शानदार है, लेकिन अफसोस कि software industry के बहुत से लोगों के लिए यह आसान नहीं है
    software वाले लोग उस पुराने दौर के आदी हैं जब किसी चीज़ को पूरी तरह master किया जा सकता था, लेकिन अब ज्ञान और दुनिया की जटिलता लगातार बढ़ गई है, इसलिए Genesis से मौजूद कोई superintelligent व्यक्ति भी शायद इसके साथ कदम मिलाना लगभग असंभव पाएगा
    अगर आप असहमति को “मैं जितना सोचता हूं, उससे कम जानता हूं” के संकेत की तरह नहीं देख पाते, तो यह खतरनाक हो जाता है; मैंने कई बार देखा है कि बहुत smart लोगों के नेतृत्व वाले projects इसलिए fail हुए क्योंकि उन्होंने उस कम smart व्यक्ति की महत्वपूर्ण जानकारी नहीं सुनी जो किसी खास technology को बेहतर जानता था

    • ज्ञान, अनुभव और skill के बारे में “smartness” को सीधे ऊपर बढ़ते Pokémon level की तरह देखने वाला सब-कुछ या कुछ भी नहीं वाला रवैया अजीब है
      असल में यह skills और experience के radar chart जैसा अधिक है, और गूढ़ ज्ञान से भरे पेशे में तो यह खासकर हास्यास्पद लगता है
      अनुभवी और smart होना बड़ी संपत्ति है, लेकिन अगर library X को अच्छी तरह न जानने वाले senior के सामने कोई ऐसा junior है जिसने सिर्फ library X में गहराई से काम किया है, तो उस junior की सलाह सुननी चाहिए
    • जो व्यक्ति बहुत कुछ नहीं जानता लेकिन यह जानता है कि वह नहीं जानता, उससे कहीं ज्यादा खतरनाक वह है जो अपने जानने से ज्यादा जानने का भ्रम पालता है
    • ऐसे लोगों की मूल बुद्धि ठीक हो सकती है, लेकिन वे सचमुच smart नहीं होते
      सचमुच smart व्यक्ति जानता है कि वह क्या जानता है और क्या नहीं, अपनी समझ को लगातार verify करता है, और जब यह सामने आता है कि वह गलत था तो खुश होता है, क्योंकि इसका मतलब है कि उसने कुछ नया सीखा
    • इसके लिए बहुत ऊंचे स्तर की self-awareness और vulnerability चाहिए
      सभी सोचते हैं कि trust या recognition पाने के लिए सब कुछ जानने का दिखावा करना पड़ेगा, लेकिन असल में अगर आप ईमानदारी से वास्तविक बने रहें, तो मदद अपने आप आती है

  • HN पर मेरे नियम ये हैं: मानकर चलो कि reply करने वाले ने article नहीं पढ़ा और मेरे comment को भी बस सरसरी तौर पर देखते हुए अपने जवाब को मन में लिख रहा था; abstract बातें गलत समझी जाएंगी, इसलिए concrete लेकिन थोड़ी अस्पष्ट भाषा में लिखो; मानो कि comment की quality और response के बीच कोई consistent संबंध नहीं है; reply लिखकर भेजे बिना delete कर देना भी ठीक है और अक्सर यही सबसे अच्छा होता है; शक हो तो thread बंद करो और आगे बढ़ो

    • मुझे लगता है कि मैं भी हर चार comments में से एक को लिखकर मिटा देता हूं
      साथ ही, किसी एक user के साथ लंबी बहसें आम तौर पर उबाऊ और बेनतीजा होती हैं, इसलिए उनसे बचना चाहिए; कोई लड़ाई शुरू करे तो उसमें मत कूदो; नकारात्मक लगने वाले comments के बारे में यह पर्याप्त संभावना मानो कि शायद मैंने ही गलत समझा है; और तारीफ रोकनी नहीं चाहिए, क्योंकि वह किसी का दिन बेहतर बना सकती है
    • मुझे याद है कि पहले एक बार मैंने बहुत गुस्से में एक लंबा email लिखा था
      मैंने एक colleague से review करने को कहा, तो उसने कहा “इसे सुधारने का सिर्फ एक तरीका है” और तुरंत delete button दबा दिया
    • मेरे स्वाद के लिए यह बहुत cynical है
      अगर ऐसी सूची की जरूरत है, तो मुझे लगता है कि ज्यादा productive दिशा आमतौर पर अपने ego को घटाकर online discourse के प्रति resilience बढ़ाना है
      तब आप ज्यादा चीज़ों को जैसी हैं वैसी स्वीकार कर सकते हैं और ज्यादा विविध perspectives से सामना होता है
      HN कोई खास जगह नहीं है, मैं भी खास नहीं हूं, और किसी अजनबी पर यह obligation नहीं है कि वह मेरे लिए सोच-समझकर जवाब तैयार करने में समय लगाए; अगर आप इसकी उम्मीद या मांग करेंगे, तो आमतौर पर निराशा ही मिलेगी
    • मैं भी कभी-कभी reply लिखकर मिटा देता हूं, लेकिन जो मैं अधिक बार करता हूं वह यह है कि comment लिखने के बाद उस चर्चा को दोबारा check नहीं करता
      अगर reply आए और उसमें शामिल होने की इच्छा हो तभी फिर देखता हूं
      थोड़ा भी विवादास्पद comment हो तो अक्सर ऐसे जवाब आते हैं जिनमें सामने वाला यह समझने की कोशिश नहीं करता कि मैं क्या कह रहा हूं, और अगर link वाला कोई data point भी डाल दूं तो कोई न कोई उस data से खुश न होकर नाराज हो जाता है
    • मैं इन नियमों से सहमत हूं, और एक और जोड़ना चाहूंगा: comment का reply आएगा, इसकी उम्मीद न रखना बेहतर है
      comment threads ज्यादा से ज्यादा बस ढीले तौर पर उसी विषय से जुड़े रहते हैं

  • Julia की लिखाई में, ज़बरदस्ती cute बनने की कोशिश करने वाले कुछ blogs के उलट, अच्छे इंसान वाली energy है, और लगता है कि वह जितना बाहर देती हैं उतना वापस भी पा लेती हैं
    वह साफ़ तौर पर एक अनुभवी writer हैं जिन्हें tone सेट करना आता है
    इंटरनेट पर लोग default रूप से जिस बोलने के अंदाज़ को मानकर चलते हैं, वह ज़्यादा रूखा होता है, और यही अनावश्यक समस्याओं की बड़ी वजह है
    उल्टा, थोड़ी-सी तंज़िया बात या पुराने Torvalds-स्टाइल की खुरदरी ऊर्जा भी बुरी नहीं है, लेकिन ऐसा लहजा ज़्यादा शोरगुल वाली भीड़ को खींचता है
    हर किसी को discourse का वही तरीका अपनाने की ज़रूरत नहीं है

    • Julia की लिखाई मुझे हमेशा बेहतरीन लगी है, और मेरे दिमाग़ में वह उस model की तरह है जिसकी ओर मैं बढ़ना चाहता हूँ
      फिर भी मेरा अपना लहजा हमेशा जितना मैं चाहता हूँ उससे कहीं ज़्यादा lecture जैसा लगता है

  • सलाह ठोस है
    मिलते-जुलते अनुभव से गुज़र चुके व्यक्ति के तौर पर जोड़ूँ तो, हर online बातचीत optional है, इसलिए किसी अप्रिय exchange को आखिर तक पूरा करना ज़रूरी नहीं है, और बेवकूफ़ लोगों को ignore करके छोड़ देना ठीक है
    आप हर किसी को मना नहीं सकते, कुछ लोग जानबूझकर सिर्फ़ विरोध करते हैं, और कई बहसें bad-faith में होती हैं, इसलिए उकसावे को discussion में बदलने की कोशिश न करना बेहतर है
    आप readers के कर्ज़दार भी नहीं हैं। वे पैसे नहीं देते

  • कुल मिलाकर अच्छी सलाह है, और राय से पहले अनुभव को रखने की बात नई लगी
    “पहले से रोकथाम” मुझे पसंद नहीं आई क्योंकि इससे लेख boring हो सकता है, और Julia अनुभवी writer हैं इसलिए इसे smooth तरीके से कर लेती हैं, पर मैं नहीं कर पाता
    “बहस न करना” अच्छा है, लेकिन मैं अक्सर fail हो जाता हूँ
    मेरे लिए काम करने वाली तरकीब यह है कि खुद को याद दिलाऊँ कि अभी मैं किसी को मुफ्त में train कर रहा हूँ
    negative comments का analysis भी मैं ठीक से नहीं कर पाता, इसलिए शायद किसी तरह की cognitive behavioral therapy technique चाहिए; आम तौर पर मैं जल्दी से “क्या मैं गलत हूँ?” check करता हूँ, और अगर गलत हूँ तो सुधार सकता हूँ, इसलिए यह अच्छा outcome है, लेकिन अगर मैं सही था और फिर भी गलत समझा गया तो गुस्सा आता है
    पता नहीं क्यों, लेकिन गलत होने की तुलना में सही होते हुए भी गलत समझा जाना कहीं ज़्यादा frustrate करता है
    गलत होने पर “अरे, धत्” जैसा discovery वाला dopamine response आता है, लेकिन जब मैं सही हूँ और सामने वाला समझने से इनकार करता है, तो मैं उसी topic को बार-बार कुरेदता रहता हूँ
    Twitter पर block करने की मेरी मुख्य वजह यही है, और ideal तौर पर जो लोग मुझे अक्सर गलत समझते हैं वे भी मुझे block कर दें ताकि मैं involve न होऊँ

  • dig manual page के “gross terminology” पर reaction सचमुच की गलतफहमी और communication failure भी हो सकता है, और शायद British English और American English का फर्क भी
    “to grope around for something” का मतलब किसी चीज़ को टटोलकर ढूँढना है, यह बिल्कुल भी sexual expression नहीं है, और आम तौर पर जिसे टटोला जा रहा होता है वह भी light switch जैसी निर्जीव चीज़ होती है
    मुझे यह भी नहीं लगता कि यह usage sexual assault के रूपक से आया है
    शब्दों के कई अर्थ हो सकते हैं और उन्हें गंदे तरीके से भी इस्तेमाल किया जा सकता है, लेकिन फिर भी उनका जायज़ और स्वाभाविक इस्तेमाल हो सकता है
    “I coloured in a picture” घिनौना नहीं है, और “garden hoe” भी ठीक ही लगता है

    • “Groping for a light switch” American English में भी valid expression है, लेकिन groper अकेले आए तो sexual implication बन जाता है
      उदाहरण: https://www.dictionary.com/browse/groper
      खासकर महिलाएँ, जो sexual groping का आम target होती हैं, उस अर्थ को ज़्यादा notice कर सकती हैं, इसलिए भले वह मेरी पहली association न हो, किसी महिला का उसे वैसे लेना मुझे reasonable लगता है
      जैसा Julia ने कहा, असली intention उतनी अहम नहीं है, और अगर मेरी लिखाई गलती से कुछ readers के लिए problem बनती है तो मैं बदल दूँगा
      क्योंकि मेरा goal बात पहुँचाना है
      इतिहास में marginalize किए गए groups को असहज करने वाली language का इतना कड़ा बचाव होते देख, सवाल उठता है कि छोटे-से बदलाव का इतना विरोध क्यों
      ऊपर से dig maintainer ने 2017 में ही वह बदलाव कर दिया था, इसलिए लगता है उन्हें भी इससे बहुत फर्क नहीं पड़ा
    • आज के समय में sexual interpretation काफी strong है, और groping और groper के nuances थोड़े अलग हैं, इसलिए मुझे लगता है कि अब इसे हटाना उचित है
      हालांकि 80s में भी ऐसा था या नहीं, यह मुझे ठीक से नहीं पता
      Mastodon link खोलकर “proof माँगने वाले पुरुषों” को देखा, लेकिन बाद में पता चला कि problem वाले replies delete हो चुके थे, इसलिए मैंने जो तीन replies देखे वे वास्तव में relevant नहीं थे
      मैंने जो replies देखे वे कुल मिलाकर supportive थे; दो लोगों ने कहा कि उन्होंने अब तक sexual assault वाला अर्थ नहीं सोचा था और पता नहीं वह intention था या नहीं, फिर भी वे इसे हटाने से strongly agree करते हैं, और एक ने कहा कि ऐसा interpretation मौजूद है यह जानकर हैरानी हुई और extra context पूछा
      उसके बाद OP ने बहुत सारे बेहद confrontational जवाब दिए जिनमें हर मामले में bad intent assume किया गया था; Julia बेहतरीन technical writer हैं और मैं पढ़ता रहूँगा, लेकिन इस बार उनका यह रूप अच्छा नहीं लगा
      manual page में बदलाव की request पूरी तरह reasonable है, लेकिन personal attacks की ज़रूरत नहीं थी
    • Mastodon thread पढ़ते समय यह हिस्सा ध्यान में आया
      उस expression पर सवाल उठाने वाले कुछ पुरुषों ने साफ़ कहा था कि वे “groping” हटाने से पूरी तरह सहमत हैं, लेकिन उस समय तक लेखक शायद वह explanation देख नहीं पा रहे थे
      मैं लोगों के boundaries तय करने और abusive behavior को block करने के चुनाव का पूरी तरह समर्थन करता हूँ, लेकिन “तुम मेरी बात से सहमत नहीं हो, इसलिए तुरंत block करूँगा और सफाई का मौका भी नहीं दूँगा” वाला रवैया online discourse के टूटने के बीचोंबीच लगता है
      हालांकि आसपास की महिलाओं को online abuse झेलते देखा है, इसलिए संवेदनशील trigger भी समझ आता है
      सही balance क्या है, यह नहीं जानता और वह बहुत personal/contextual होगा, लेकिन मैंने अब बातचीत में तभी उतरना शुरू किया है जब स्पष्ट abuse को छोड़कर expected response categories को handle करने की इच्छा हो
      disagree करने पर block करने का तरीका polarization बढ़ाता है और लंबी अवधि में उल्टा असर करता दिखता है, और कभी-कभी भले मैं “सही” होऊँ, यह मेरे blind spots को मजबूत करना आसान लगता है
    • लिखने के तरीके को लेकर चिंता करना या बदलना valuable नहीं मानता
      ऐसे लोगों से थक गया हूँ जो अपनी उम्मीद से अलग तरीके से लिखा वाक्य देखकर सफेद पड़ जाते हैं और इस चिंता में घुलते हैं कि कहीं इसका double meaning तो नहीं
      मसलन “Smoking a fag” पूरी तरह British expression है, लेकिन कोई uncultured American मोतियों की माला clutch करते हुए downvote या report button खोजने के लिए टटोल सकता है
      अगर डर लगता है तो कुछ भी नहीं पढ़ना चाहिए
      पढ़ना डरावना और खतरनाक है
    • “मैं जो कहना चाहता था”, “वास्तव में इस्तेमाल किए गए शब्द और उन शब्दों का cultural context”, और “उन शब्दों से पड़ा असर” अलग-अलग चीज़ें हैं
      अगर आप उन लोगों की परवाह करते हैं जो आपको सुन रहे हैं, तो जब वे कहें “आपके इस्तेमाल किए शब्दों का negative impact पड़ा”, तब “माफ़ कीजिए, मैं आपको ऐसा महसूस नहीं कराना चाहता, इसलिए शब्द बदल दूँगा” कहना और आगे बढ़ जाना बहुत स्वाभाविक और मुश्किल नहीं है
      या फिर आप पूरे दिन इस intention पर बहस कर सकते हैं कि मेरा मतलब वह नहीं था, actual impact को पूरी तरह ignore करते हुए, और सामने वाले को यह feeling दे सकते हैं कि आपको उनकी भावनाओं की परवाह नहीं है
      खासकर personal relationships में, apology देते समय intention की बजाय impact पर focus करने की मैं strongly सलाह देता हूँ

  • यह लेख बहुत ज़्यादा आत्मचेतना और political correctness से भरा हुआ लगता है
    लेखक policy proposals और सामाजिक-सांस्कृतिक insights पर self-censoring करता है, जबकि निजी तौर पर मुझे ऐसी चीज़ें—खासकर बदलाव पैदा करने वाले अजीब नज़रिए—लिखना और पढ़ना दिलचस्प लगता है
    dig से जुड़ी blocking भी काफ़ी खटकती है, और लेखक को ऐसे व्यक्ति जैसा दिखाती है जो बहुत जल्दी trigger दबा देता है
    मैंने इस thread में थोड़े भी आलोचनात्मक comments को 0 से नीचे जाते भी देखा
    मेरा comment भी ऐसा ही है, और HN पर आलोचनात्मक comments का नज़रअंदाज़ होकर upvote न मिलना आम है, लेकिन ज़रा-सी भी आलोचना वाली हर चीज़ को 0 से नीचे धकेलना HN के standards से भी दुर्लभ है
    self-censorship पर लिखे लेख ऐसे readers को आकर्षित करते लगते हैं जो एक अजीब नई आत्मचेतन दुनिया चाहते हैं, जहाँ सभी को एक-दूसरे से सहमति में सिर हिलाना पड़े

    • लेखक रणनीतिक रूप से उन discussions से बच रहा है जिन्हें वह productive नहीं मानता और जिनमें शामिल नहीं होना चाहता, और इसलिए लेख का शीर्षक भी ऐसा है
      अच्छे writers हमेशा सोचते हैं कि शब्दों का चुनाव reader पर कैसा असर डालेगा
      क्या आप कह रहे हैं कि यह बुरी बात है?
    • लेखक कहना चाहता है कि वह ऐसी writing करना चाहता है जिससे ऐसे discussion threads बनें जो उसे दिलचस्प लगें
      आपकी interests बस अलग हैं
      dig वाले उदाहरण में जल्दी trigger दबाना ही असल point है
      लेखक हमें याद दिला रहा है कि हम क्या देखेंगे, इसे control कर सकते हैं और हमें उस control का इस्तेमाल करना चाहिए
      ज़्यादातर लोगों के लिए कुछ topics ऐसे होते हैं जिन पर constructive तरीके से discussion में हिस्सा लेना मुश्किल होता है, और यह ठीक है
      ऐसे topics पर energy बचाकर उन topics पर लिखते रहना बेहतर है जहाँ उसे अच्छी तरह इस्तेमाल किया जा सके
      upvote को सहमति और downvote को असहमति की तरह इस्तेमाल करने की प्रवृत्ति होती है
      votes का मतलब क्या होना चाहिए, इस पर अलग विचार हो सकते हैं, लेकिन voting system की प्रकृति के कारण चीज़ें आसानी से उसी दिशा में चली जाती हैं
      यह कुछ वैसा ही है जैसे मैं चाहता हूँ कि लोग default रूप से 5/5 नहीं बल्कि 3/5 दें, लेकिन असल में शायद IMDb ही ऐसा कर पाया है

  • शर्म की बात है कि आज ही मुझे पता चला कि dig एक acronym था और किसका short form है

    • मुझे भी नहीं पता था, और इसमें शर्माने की कोई बात नहीं है
      लगभग हर command-line tool जिसका नाम साफ़ नहीं है, grep, cd, pwd, dd, yacc की तरह एक acronym होता है
    • Mastodon thread में पता चला कि ping भी ऐसा ही है

  • मेरा एक personal blog है जहाँ मैं सिर्फ़ सख्ती से professional topics पर लिखता हूँ, और जिन opinions को लोग नापसंद कर सकते हैं उन्हें मैं pen name से दूसरे blog पर लिखता हूँ
    अगर आपके पास एक shadow identity हो, तो ज़रूरत पड़ने पर “गलत” होने की जगह मिलती है