Wikipedia में सबसे कम देखे जाने वाले लेखों की खोज (2022)

 (colinmorris.github.io)
1 पॉइंट द्वारा GN⁺ 2023-10-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Wikipedia में जहाँ लोकप्रिय पेज हर हफ्ते लाखों views पाते हैं, वहीं 60 लाख से ज़्यादा लेखों के बीच ऐसे बेहद अलोकप्रिय लेख भी हैं जिन्हें साल भर में केवल एक-अंकीय बार पढ़ा जाता है
  • 2021 में लगभग 32,000 लेखों के sample में सबसे निचले हिस्से में कई disambiguation pages थे, और इन्हें हटाने पर पतंगा·मक्खी की प्रजातियाँ, ईरान के गाँव, और उपनाम जैसे छोटे stub लेख सालाना 7–9 views पर टिके रहे
  • “Random article” बटन में हर लेख के page_random मान और उससे ठीक पहले वाले मान के बीच के random gap के आधार पर चयन संभावना बदलती है, इसलिए कुछ लेख औसत से बहुत कम दिखते हैं
  • औसत gap के लगभग 1/10 या उससे कम वाले 6 लाख लेखों तक दायरा सीमित करने पर, 2021 के सबसे कम देखे गए लेख Trichromia phaeocrota और Opharus corticea निकले, जिन पर अनुमानतः मानवीय views 3-3 दर्ज हुए
  • सबसे नीचे के 500 लेखों में कीट taxa, कुछ gastropods·fungi, भौगोलिक स्थलरूप, और set index लेख अधिक थे, और species·settlement लेख अक्सर कमज़ोर स्रोतों के बावजूद कम सख्त inclusion मानदंडों के कारण बने रहते हैं

sample में दिखने वाले अलोकप्रिय लेखों की विशेषताएँ

  • Wikipedia में 60 लाख से ज़्यादा लेख हैं, और लोकप्रिय लेख हर हफ्ते लाखों views पाते हैं
  • इसके उलट, ऐसे लेख भी हैं जिन्हें दिन में कुछ बार देखना भी मुश्किल है; उदाहरण:
  • लेखक द्वारा बनाए गए लेखों में सबसे कम लोकप्रिय Sunday reading periodical है, जो Victorian era magazine genre पर एक लेख है और इसे औसतन लगभग 12 views प्रति माह मिलते हैं
  • Wikipedia pageview data raw dump और API के रूप में सार्वजनिक है, लेकिन सबसे कम देखे गए लेख को सीधे sort करने का कोई आसान तरीका नहीं है

32,000 के random sample का विश्लेषण

  • 2021 के pageview data को Wikipedia के लगभग 32,000 लेखों के एक sample से जुटाया गया
  • sample में सालाना views का median 1,000 से थोड़ा कम था, और long tail के कारण average लगभग 13,000 था
  • sample में लगभग 100 ऐसे लेख थे जिनके 2021 में कुल views एक अंक में थे
  • लेकिन सबसे नीचे के 50 लेख सभी disambiguation pages थे, और विश्लेषण में इन्हें “वास्तविक लेख” नहीं माना गया
  • disambiguation pages को हटाने पर, सालाना एक-अंकीय views वाले लेख 7–9 views की range में आने वाले कुछ छोटे stub लेखों तक सीमित रह जाते हैं

“Random article” बटन और random gap

  • बहुत कम views का कारण यह हो सकता है कि उपयोगकर्ता Random article बटन दबाकर वहाँ पहुँचे हों
  • Random article बटन 2015 से disambiguation pages को अनदेखा करने के लिए implement किया गया है, जिससे यह समझाया जा सकता है कि sample में सबसे कम views वाले पेज disambiguation pages में क्यों भरे थे
  • Wikipedia लेख बनते समय 0 और 1 के बीच एक random value page_random पाते हैं
  • जब Random article request आती है, server 0 और 1 के बीच एक random number बनाता है और उस value से बड़ा सबसे नज़दीकी page_random वाला लेख लौटाता है
  • यह तरीका पूरी तरह fair नहीं है
    • किसी लेख के चुने जाने की संभावना उसके page_random मान और उससे ठीक पहले वाले लेख के page_random मान के अंतर, यानी random gap, के बराबर होती है
    • जिन लेखों का gap छोटा होता है, उनके Random article में चुने जाने की संभावना भी कम होती है

views के निचले स्तर और random gap का संबंध

  • अगर Wikipedia में लगभग 60 लाख लेख हैं, तो average random gap लगभग 1/6,000,000, यानी 1.67e-7 होगा
  • sample में सबसे कम देखे गए Erygia sigillata का page_random मान 0.500764585777 है, और उससे ठीक पहले वाला लेख Katherine Hanley 0.500764582314 है
  • इन दोनों का अंतर लगभग 3e-9 है, जो average random gap से 98% छोटा है, और इसलिए average लेख की तुलना में Random article में चुने जाने की संभावना 50 गुना कम है
  • सालाना एक-अंकीय views वाले बाकी 5 लेखों के random gap भी 3e-9, 9e-9, 8e-9, 4e-9, 8e-9, 2e-8 थे, जो सभी average से लगभग एक order छोटे थे
  • पूरे 32,000 sample में random gap और views का संबंध बहुत स्पष्ट नहीं दिखता
    • लेकिन सालाना 200 से कम views वाले लेखों, या Category:Phaegopterina stubs के लगभग 1,500 लेखों जैसे उन समूहों में, जिनमें शुरू से ही रुचि कम लगती है, यह संबंध अधिक स्पष्ट हो जाता है

2021 के सबसे कम देखे गए लेख

  • सबसे कम देखे गए लेख केवल कम जन-रुचि वाले विषय नहीं होने चाहिए, बल्कि बहुत छोटे random gap वाले लेख भी होने चाहिए
  • विश्लेषण को average gap के लगभग 1/10, यानी 1.7e-8 या उससे कम वाले लेखों तक सीमित करके 6 लाख “सबसे बदकिस्मत” लेखों को देखा गया
  • इन 6 लाख लेखों को भी 2021 में कम-से-कम कुछ बार देखा गया
  • 2021 में सबसे कम views वाले लेखों का संयुक्त पहला स्थान दो लेखों ने लिया, जिन पर अनुमानतः मानवीय views 3-3 थे
  • दोनों लेख पतंगे की प्रजातियों के बारे में हैं

सबसे नीचे के 500 लेखों में दोहराने वाले पैटर्न

  • सबसे नीचे के 500 लेखों की सूची Least viewed articles in 2021 पर देखी जा सकती है
  • विषय-वितरण बहुत सुसंगत है
    • इनमें से काफ़ी लेख कीट प्रजातियों या अन्य कीट taxon पर हैं
    • इनमें 17 gastropods और Harknessiella नाम का 1 fungus भी शामिल है
    • इसके बाद सबसे आम श्रेणी भौगोलिक स्थलरूपों की है, खासकर ईरान और श्रीलंका के गाँव बार-बार दिखते हैं
    • Kälberbuckel जैसे छोटे भौगोलिक लेख भी हैं
  • एक और बार-बार दिखने वाली श्रेणी set index लेखों की है
  • set index article, disambiguation page की तरह दिखते और वैसा ही काम करते हैं, लेकिन Wikipedia classification में वे disambiguation pages नहीं हैं
  • DMZ//38 या EuroNanoForum 2009 जैसे कुछ लेख भी शामिल हैं, जो Wikipedia के पुराने ढीले inclusion criteria की याद दिलाते हैं

इतने पतंगे क्यों हैं

  • Wikipedia जीवित व्यक्तियों, कंपनियों, bands जैसे विषयों पर सख्त sourcing requirements लागू करता है
  • ऐसे विषयों का दुरुपयोग प्रचार, हित-साधन या विवाद के लिए edits में हो सकता है, इसलिए सिर्फ़ प्राथमिक स्रोत की पुष्टि से लेख शामिल करना मुश्किल होता है और कई independent secondary sources में meaningful coverage चाहिए होती है
  • इसलिए जो विषय ये आवश्यकताएँ पूरी करते हैं, उनमें Random article उपयोगकर्ताओं के अलावा भी रुचि रखने वाले लोग होने की संभावना अधिक होती है, और वे नीचे के 500 में लगभग कभी नहीं दिखते
  • इसके विपरीत, species articles और settlement articles आम तौर पर delete नहीं किए जाते
    • विषय कमज़ोर रूप से sourced हो तब भी वे अक्सर बने रहते हैं
    • नीचे की सूची के बहुत से लेख database, gazetteer, किताब या academic journal में छोटे उल्लेख जैसे एकल स्रोतों पर टिके होते हैं
  • कम मानदंडों के कारण कुछ लेख ऐसे stub लगते हैं मानो मशीन से बनाए गए हों
    • Pottallinda 12-शब्दों का stub है और 2021 में इसे 5 views मिले
    • इसे 18 जनवरी 2011 को User:Ser Amantio di Nicolao ने बनाया था, और 60 सेकंड के भीतर Polmalagama, Polommana, Polpitiya, Polwatta जैसे कई मिलते-जुलते लेख भी बनाए गए
  • ऐसे बेहद छोटे और अलोकप्रिय लेख Random article उपयोगकर्ताओं को निराश कर सकते हैं, लेकिन बाद में दूसरे संपादकों द्वारा विस्तार के लिए बुनियादी groundwork भी बन सकते हैं

डेटा और कोड

  • pageview data और scraping·analysis code GitHub repository wiki-pageview-floor में सार्वजनिक रूप से उपलब्ध हैं

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

1 टिप्पणियां

 
GN⁺ 2023-10-21
Hacker News की राय

  • Wikipedia में ऐसा होने की वजह monetization या विवादास्पद दृष्टिकोण नहीं है, बल्कि हटाने के फैसलों में सबसे ज़्यादा इस्तेमाल होने वाला notability criterion उद्धृत sources की प्रकृति और गुणवत्ता से आता है
    पहले यह guideline थी कि international level के sports में खेलने वाले लोग आम तौर पर notable माने जाते हैं, इसलिए national team के लिए सिर्फ़ एक match खेलने वाला footballer भी कमज़ोर sources के बावजूद deletion से बच सकता था
    लेकिन वह guideline हट गई और general notability guideline (GNG) पर लौटने के बाद, व्यक्तियों के लिए national level के भरोसेमंद mainstream media में पर्याप्त biographical coverage की ज़रूरत हो गई, और match reports, local interviews, fan media आम तौर पर बाहर कर दिए गए
    नतीजतन महिला international footballers से जुड़े सैकड़ों stub articles और दर्जनों full articles, World Cup विजेता होने पर भी, mainstream media coverage अपेक्षाकृत कम होने के कारण GNG पूरा नहीं कर पाए; और जब एक editor ने इस गर्मी Women's World Cup शुरू होने के बाद ऐसे articles को बड़े पैमाने पर deletion के लिए nominate किया, तो लगभग सभी delete हो गए
    इसलिए moths या places पर articles बने रहने की वजह monetization या controversy नहीं है; वजह यह है कि जिन objects और places के लिए Wikipedia editors पर defamation का मुकदमा नहीं हो सकता, उन पर पूरी तरह अलग notability standards लागू होते हैं

    • आज सुबह भी मैं Interstate 94 article पढ़ते-पढ़ते उसे manage करने वाले WikiProject, US Roads, तक पहुंचा, और देखा कि एक महीने पहले उन्होंने एक open letter लिखा था कि arbitrary notability guidelines के कारण articles delete होने की पीड़ा से वे Wikipedia छोड़कर अपनी wiki बनाएंगे
      https://en.wikipedia.org/wiki/Wikipedia:WikiProject_U.S._Roads/Newsletter/Issues/Volume10/Issue01
    • मैंने काफी niche personality The Mexican Runner पर article लिखा था, और दूसरे editors को यह मनाने के लिए थोड़ा संघर्ष करना पड़ा कि यह व्यक्ति notable है
      Polygon और Kotaku में coverage था, इसलिए मुझे लगा काफी है, लेकिन शुरुआत में यह मुश्किल काम था
      क्या कोई व्यक्ति जो buttons बहुत तेज़ी से दबाता है, सच में notable person है?
    • क्या कोई सच में मानता है कि “national level के भरोसेमंद mainstream sources” वाला standard व्यवहार में consistently लागू होता है?
      technology, academia, local politics आदि में अलग-अलग roles और positions रखने वाले लोगों पर Wikipedia articles की गिनती शायद बहुत बड़ी होगी जो इस standard को पूरा नहीं करेंगे
    • Wikipedia कोई एक single entity नहीं है, और यहां शायद English Wikipedia की बात हो रही है, लेकिन जहां तक मुझे पता है, अन्य language editions के Wikipedia की अपनी, कभी-कभी काफी अलग notability requirements होती हैं
    • Wikipedia की notability guidelines बहुत पहले से ही बहुत सख़्त रही हैं
      मुझे याद है कि यह देखकर हैरानी हुई थी कि काफी popular webcomic तक का wiki article नहीं हो सकता

  • मेरे हिसाब से Wikipedia की कम-ज्ञात बेहतरीन features में से एक हर article के सबसे नीचे मौजूद collapsed navigation box है
    complex topics को bird's-eye view से समझने और यह देखने के लिए कि कोई item किसी complex hierarchy में कहां फिट होता है, यह बहुत अच्छा है
    कुछ तो छोटे art pieces जैसे लगते हैं जिन्हें मैं किसी दिन दीवार पर लगाना चाहूंगा
    https://imgur.com/gallery/ILp6TtA
    मैं समझता हूं कि उन्हें default रूप से collapsed क्यों होना चाहिए, लेकिन userjs से उन्हें page के top पर ले जाकर expanded रखता हूं और navigation के लिए इस्तेमाल करता हूं
    बहुत ज़्यादा जगह न घेरें, इसलिए CSS zoom को 0.3 पर set किया हुआ है

    • दिलचस्प है कि आपको यह “art” के तौर पर आकर्षक लगता है, लेकिन मुझे यह बिल्कुल वैसा नहीं दिखता

  • रैंडम लेख चुनने का तरीका चौंकाने वाला है
    randomization में स्थायी bias पैदा हो जाता है, और समय के साथ किसी अलग-अलग लेख के चुने जाने की संभावना कैसे बदलती है, इसमें काफ़ी path dependence होना तय है
    1 से N तक कोई random integer निकालना rocket science नहीं है
    यह भी सोचने का मन करता है कि कहीं किसी खास पसंदीदा लेख से पहले वाली जगह खाली छोड़कर उसे ज़्यादा बार दिखाने जैसी कोई जानबूझकर दी गई weighting तो नहीं है

    • चौंकाने वाला तो है, लेकिन और ज़्यादा चौंकाने वाली बात यह है कि इसे ठीक से करना सचमुच rocket science के काफ़ी करीब है
      MySQL असल में अच्छी performance के साथ सच में random row चुनने के लिए बना ही नहीं है
      ORDER BY RAND() LIMIT 1 जैसा भोला-भाला तरीका performance में बेहद खराब है, और LIMIT 0 OFFSET RAND() * row_count भी लगभग उतना ही खराब है
      अगर WHERE id >= RAND() * max_id ORDER BY id LIMIT 1 जैसा तेज़ तरीका इस्तेमाल करें, तो हटाए गए लेखों से बने ID holes की वजह से वही समस्या आती है कि कुछ लेख ज़्यादा बार चुने जाते हैं
      सही समाधान सिर्फ़ दो हैं: random ID निकालें और invalid होने पर फिर कोशिश करें, या सभी valid लेखों को sequential integer series में रखने वाला अलग column/table maintain करें
      पहले वाले में ID कितनी sparse है, इस पर निर्भर करते हुए कभी-कभी 20 बार retry करना पड़ सकता है, इसलिए performance predict करना मुश्किल है; और दूसरे में हर बार लेख delete करने पर integer column का औसतन आधा हिस्सा फिर से calculate और rewrite करना पड़ता है
      आखिरकार, एक toy feature जैसे काम के लिए Wikipedia का तरीका “काफी अच्छा” है, और रोज़/साप्ताहिक batch job में या हर document edit पर random numbers फिर से calculate करने से इसकी कमियां कम हो सकती हैं
      मौजूदा तरीके में सिर्फ़ सबसे नज़दीकी एक लेख चुनने के बजाय आगे-पीछे करीब 50-50 लेख चुनकर उन 100 में से फिर random चुनने से भी बड़ा सुधार हो सकता है
      यह पूरी तरह hack है, लेकिन व्यवहार में फिर भी बहुत तेज़ रहेगा
    • अगर पहले से पता ही न हो कि कौन-सा लेख delete हुआ है, तो क्या करेंगे?
      1 से N तक random integer चुनने पर खराब नतीजा आने की संभावना होती है
      spam को ध्यान में रखें तो खराब pages की संख्या अच्छे pages से ज़्यादा होने की संभावना भी कम नहीं है, और तब कई बार फिर से चुनना पड़ेगा
      मैं re-draw को ठीक strategy मानता हूं, लेकिन यह नहीं लगता कि हर कोई उस probability पर बस भरोसा कर लेगा
      सच में अगर 99 खराब pages और 1 अच्छे page वाली wiki बना दी जाए, तो random article button ज़्यादातर समय काम नहीं करेगा
      valid लेखों की संख्या M के आधार पर 1 से M तक भी चुना जा सकता है, लेकिन उस number को actual document ID पर कैसे map करेंगे, वही समस्या बनी रहती है
      इस तरीके में bias हो सकता है, लेकिन इसकी constant-time performance है
      निजी तौर पर मुझे सभी valid लेखों को memory में रखकर उनमें से एक चुनना बेहतर लगता है
      अक्टूबर तक सिर्फ़ 70 लाख हैं, और deleted documents मिलाकर भी शायद करीब 7 करोड़ होंगे, जो HN के कुल items की संख्या जैसा ही scale है
      यहां तक कि disk पर हर valid document के लिए एक file बनाकर find . -type f | shuf -n 1 से random search करें और result को हर कुछ seconds में cache करें, तो भी शायद बहुत खराब नहीं होगा, हालांकि उसमें भी अपनी तरह का bias होगा
    • इतना सब करने को देखकर लगता है कि शायद database में random row selection सचमुच धीमा operation है
      यह पूरी तरह toy feature है, इसलिए weights बराबर न हों तो भी बहुत फर्क नहीं पड़ता, और कहा जाता है कि MariaDB में ORDER BY RAND() LIMIT 1 full table scan करता है
    • अगर deleted होने या न होने से अलग, IDs वाले documents का database हो, हर application server ID range जानता हो, और आप non-deleted document को random चुनना चाहते हों, तो शायद मैं ऐसा करूंगा
      1. deleted documents के लिए remote cache रखूंगा और 2) application server जब भी deleted document चुने, उसे remote cache में add कर देगा
        remote cache data center local हो और persistent storage से backed हो, तथा TTL लंबा रखा जा सके
        cache TTL के दौरान revive हुए documents नहीं चुने जा पाएंगे, लेकिन यह ठीक है
        data center locality कुछ हद तक fault tolerance और low latency सुनिश्चित करती है, और persistent storage restart के समय cold cache problem कम करता है
        ID range का max watermark async तरीके से update किया जा सकता है, और नए documents का थोड़ी देर तक न दिखना भी ठीक है
    • मैंने सोचा था कि अलग-अलग weights शायद जानबूझकर रखे गए हों, क्योंकि इससे arithmetic coding याद आया
      पता चला कि यह बस संयोग था
      मौजूदा implementation में लेखों की संख्या बढ़ने के साथ weights मोटे तौर पर समान होते जाते हैं, और individual users को आखिरकार बस एक random article मिल जाए तो शायद fairness में खास दिलचस्पी नहीं होती, इसलिए यह बात समझ में आती है

  • एक साधारण पेरूवियन moth, ईरान के किसी छोटे-से गांव, या Victorian-era England की Sunday reading material जैसी जानकारी एक ही जगह मिल सकती है—यह वाकई कमाल है
    internet से पहले ऐसी चीज़ों को छापने के कागज़ की लागत भी शायद justified नहीं होती, लेकिन अब cloud storage cost लगभग 0 के करीब है, इसलिए हमें बेहद valuable long-tail information मिल रही है
    ऐसी सामग्री contribute और maintain करने वालों का आभार
    साथ ही, अगर किसी page पर “मैंने यह page visit किया है और Peru Foovius Barivius Moth में रुचि रखने वाले किसी और व्यक्ति से connect होना चाहता हूं” जैसा note छोड़ा जा सके, तो बहुत शानदार होगा

    • मुझे मौजूदा Wikipedia भी बहुत पसंद है, लेकिन मैं पुराने inclusionism policy पर लौटने की इच्छा रखता हूं
      https://gwern.net/inclusionism
    • आखिरी जोड़ से जुड़ी बात: मैंने हमेशा सोचा है कि social media apps द्वारा इस्तेमाल किए जाने वाले ultra-engagement-driving तरीके Wikipedia पर लागू करना एक मज़ेदार personal project होगा
      उदाहरण के लिए, एक TikTok-style vertical feed हो सकता है जो user के सबसे देर तक देखने लायक articles ढूंढे, और WikiScroll पहले से ही कुछ हद तक उसी दिशा में जा रहा है
      हर article के साथ chat room जोड़कर लोगों को बातचीत करने देना, या DM feature रखना लेकिन उसमें सिर्फ़ Wikipedia links भेजने देना भी संभव है
      social catalyst के रूप में Wikipedia का idea बहुत दिलचस्प है
      https://wikiscroll.blankenship.io/
    • आखिरी “Edit” के संदर्भ में यह बहुत बेशर्म self-promotion है, लेकिन मेरे बनाए web extension में बिल्कुल वही feature है: https://webcursors.click/
      अगर आप page पर note छोड़ते हैं, तो वही extension install किए हुए दूसरे लोग उसे देख सकते हैं, और किस्मत अच्छी हो तो वे आपसे संपर्क भी कर सकते हैं
    • Wikipedia का सच में आभारी हूं
      मेरे हिसाब से यह internet का सबसे अच्छा हिस्सा है

  • यह गणितीय रूप से साबित किया जा सकता है कि Wikipedia में एक भी बोरिंग लेख नहीं है
    इसे proof by contradiction से साबित किया जा सकता है
    सभी लेखों को दिलचस्पी के क्रम में रैंक करके sort करने के बाद सबसे कम value देखें, तो ज़रूर सबसे बोरिंग लेख मौजूद होगा
    लेकिन यह तथ्य ही कि वह लेख पूरे Wikipedia का सबसे बोरिंग लेख है, उस लेख को दिलचस्प बना देता है
    इसी तरह, इस ब्लॉग पोस्ट में जिन लेखों की view count सबसे कम बताई गई है, वे भी शायद अब तक वह दर्जा खो चुके होंगे

    • स्वाभाविक है कि इस पर भी Wikipedia article है: https://en.wikipedia.org/wiki/Interesting_number_paradox
    • मुझे शक है कि वह proof वैध है
      लगता है यह मानकर चलता है कि सबसे बोरिंग लेख ठीक एक ही है
      लेकिन हो सकता है कि सैकड़ों लेखों की दिलचस्पी का न्यूनतम स्तर एक जैसा हो, और तब उन सैकड़ों को बोरिंग लेख माना जाना चाहिए
    • सख्ती से कहें तो, लेख असल में 2021 में सबसे कम देखे गए documents को देख रहा है
    • सबसे बोरिंग लेख होने से जो दिलचस्पी पैदा होती है, वह इतनी बड़ी होनी चाहिए कि सबसे बोरिंग लेख और उसके बाद वाले सबसे बोरिंग लेख के बीच का gap भर सके
      इसमें उसके बाद वाले सबसे बोरिंग लेख होने की दिलचस्पी को भी ध्यान में रखना होगा
      शायद यह सच होगा, इसलिए QED
    • उसे सचमुच खोज निकालना ज़रूरी है
      जब तक कोई सबसे बोरिंग लेख खोजकर उसके बारे में सोचता नहीं, तब तक वह लेख दिलचस्प नहीं होता
      गणितीय गुण स्थायी होते हैं, और यह परवाह किए बिना मौजूद रहते हैं कि कोई उन्हें देखे या नहीं

  • UK के Network Rail के Least Used Stations पर Geoff Marshall की series याद आती है
    https://www.youtube.com/playlist?list=PLt4q5oaptyI9U2zddss8dm8srzuJj6nRz
    https://www.youtube.com/@geofftech2

    • वाकई बहुत मज़ेदार channel और videos हैं, link के लिए धन्यवाद

  • Wikipedia admins उन लेखों को हटाने में काफी सक्रिय रहते हैं जिन्हें वे महत्वपूर्ण नहीं बताते, इसलिए सबसे कम views वाला लेख शायद काफी बार बदलता होगा

    • मेरे लिखे Carrier_IQ लेख को स्पष्ट राजनीतिक कारणों से notable नहीं बताकर हटा दिया गया था, फिर कंपनी पर public-opinion battle शांत होने के कुछ साल बाद फिर से बनाया गया
      इसमें intelligence agencies की कुछ शरारत भी हो सकती थी
      असुविधाजनक ऐतिहासिक तथ्य मिटाने का बहुत अच्छा तरीका है
      अब यह किसी खास राजनीतिक साज़िश के बिना, rootkit के बारे में बस एक छोटी मज़ेदार कहानी बनकर रह गया है
    • सही है, लेकिन मेरे अनुभव में यह लेख में कवर किए गए कुछ topics की तुलना में लोगों पर ज़्यादा लागू होता है
      उदाहरण के लिए, अमेरिका के शहरों, कस्बों, गांवों और छोटे settlements में ऐसा कोई ढूंढना मुश्किल होगा जिसका Wikipedia article न हो
      Jack Wade, Alaska को देखें, Google Maps पर करीब 8 घर दिखते हैं, फिर भी Wikipedia पर है
      मुझे नहीं लगता कि किसी दुर्लभ moth species का article हटेगा
      हालांकि धरती पर हर व्यक्ति का Wikipedia article न हो, इसके लिए कोई policy तो चाहिए
      Google Maps: https://www.google.com/maps/place/Jack+Wade,+AK+99732/@64.1519419,-141.4630071,448a,35y,3.16t/data=!3m1!1e3!4m6!3m5!1s0x5149e998873be075:0x2f1a9ca47f03bf1b!8m2!3d64.1526072!4d-141.4604683!16s%2Fm%2F0480bm5?entry=ttu
      Wikipedia: https://en.wikipedia.org/wiki/Jack_Wade,_Alaska
    • लेखक ने भी असल में इसी बात को कवर किया है, और ऐसे लेखों के हटाए जाने की संभावना कम लगती है
      हालांकि इस तरह की अनोखी स्थिति सामने आने से होने वाली vandalism इसका अपवाद हो सकती है
      रुचि रखने वालों को हल्के से बता दूं: यह लेखक द्वारा इस्तेमाल किए गए dataset का byproduct भी हो सकता है, लेकिन सबसे कम views वाले लेखों की एक common बात यह है कि उनका विषय Wikipedia content guidelines के हिसाब से आम तौर पर deletion के दायरे में नहीं आता

  • लेखक ने कहा कि moth articles किसी विवादास्पद viewpoint को push करने का मौका देने की संभावना कम रखते हैं, लेकिन edit history देखें तो इस साल की शुरुआत में Scrobipalpula crustaria के wingspan पर मतभेद था
    11–13mm या 10–13mm?
    लोग ऐसी बातों को लेकर strong feelings रखते हैं

  • सबसे कम views वाले Wikipedia article का नाम खोजकर public कर दें तो उस article के views बढ़ जाते हैं, जिससे उसे खोजने की वजह ही खत्म हो जाती है

    • observer effect जैसा है
      https://en.m.wikipedia.org/wiki/Observer_effect_(physics)
    • तो शुरू की वजह क्या थी, यह मुझे ठीक से समझ नहीं आया
      क्या कोई समस्या है?
      न्याय की बात करें तो यह 2021 dataset का analysis है, इसलिए जाहिर है उस पर असर नहीं पड़ता
    • internet पर hapax legomenon खोजने की कोशिश भी इसी जैसी समस्या झेलती है, बल्कि और भी गंभीर
      कोई एक मिल भी जाए, तो उसके अस्तित्व की सूचना देते ही वह नष्ट हो जाता है
      quizzaciously देख लें

  • भले ही लेख 60 लाख से ज्यादा हों, 6.0e6 तो दशकों पहले से ही brute force करने लायक संख्या रही है
    linear search में शायद लेख पढ़ने से कम समय लगता, और लेख लिखने से तो लगभग निश्चित रूप से कम समय लगता
    बेशक ऐसा करते तो यह इतना मज़ेदार या clever नहीं होता, लेकिन अच्छी engineering लगभग हमेशा ऐसी ही होती है