यह वाकई दोतरफा मामला है। एक तरफ, यह बहुत अच्छा है। शायद ही कोई ऐसा हो जिसने backlog grooming meeting न झेली हो, जहाँ ऊपर से खुरचते हुए आगे बढ़ते हैं, जबकि पता होता है कि अंत तक पहुँचना नामुमकिन है; और वह एहसास सच में दयनीय होता है
दूसरी तरफ, issues गायब नहीं हुए हैं, बस उनका tag बदल गया है। अगर सब कुछ tags और organization का ही मामला है, तो पूरी तरह खाली issue list जैसी छद्म-आदर्श स्थिति को control करने की कोशिश करने के बजाय इसे flow पर छोड़ देना ठीक नहीं होगा? ऐसी notes को दिखने वाली जगह पर छोड़ने के फायदे भी निश्चित रूप से होंगे। यह कुछ वैसा है जैसे बड़ी सफाई में किसी चीज़ को फेंकने का फैसला किया हो, लेकिन अवचेतन कहे कि शायद बाद में ज़रूरत पड़ जाए, इसलिए संभालकर रखो
फिर भी कुल मिलाकर मैं समर्थन में हूँ। कम से कम इससे मुक्ति का एहसास और नए issues के लिए recharge होने का असर तो होगा
थोड़ा और context जोड़ें तो, creator पूरी तरह rewrite कर रहा है
rewrite version को पहले release करके फिर existing issues को deprecated बताकर close करना ज़्यादा साफ-सुथरा होता। rewrite branch के issues को version tags से अलग किया जा सकता था। नई version अभी खत्म नहीं हुई है और अगर इसी बीच close किया जाए, तो contributors यह जाने बिना कि support अब नहीं है, existing version पर नए issues खोल सकते हैं
फिर भी ऐसा नहीं है कि issues को ignore करके codebase में problems छोड़ दी जा रही हैं; पूरा project नए सिरे से व्यवस्थित किया जा रहा है https://twitter.com/jdalton/status/1571863497969119238
user के नज़रिए से, अगर ऐसी “सफाई” का मतलब issues close करना है तो यह problem है। अगर कोई issue अभी भी product में मौजूद है, तो उसे documentation के लिहाज़ से भी और उसी problem से जूझ रहे users को आसानी से खोजकर अपनी बात जोड़ने देने के लिए भी open रहना चाहिए
मेरे हिसाब से project के लिए issue के अस्तित्व को स्वीकार करके उसे open रखना ज़्यादा ईमानदार है। developer के नज़रिए से अगर issue count खटकता है, तो पुराने कम-महत्वपूर्ण issues को छिपाने के लिए filter इस्तेमाल करना बेहतर होगा
मैं भी दो मन में हूँ। एक तरफ, जब भी JavaScript काम पर लौटता हूँ, lodash ढूँढता हूँ। दूसरी तरफ, मुझे लगता है कि इस library के आधे से थोड़ा कम हिस्से को तो कृपया standard library में होना ही चाहिए
क्या ऐसे काम में बड़े language models अच्छे नहीं होने चाहिए? मेरा मतलब ticket summarization से है
इसलिए Basecamp backlog maintain नहीं करता। जो अहम है, वह फिर से सामने आ ही जाता है
jwz ने ऐसा कहा था
मेरे हिसाब से open source software project में मैंने जिन bugs की report की है, वे सबसे आम तौर पर इसी तरह close होते हैं। आप bug report करते हैं, वह 1 साल, कभी-कभी 2 साल तक पढ़ा भी नहीं जाता, फिर एक दिन वह module शुरुआत से दोबारा लिखा जाता है। और नया maintainer यह जांचने का मन नहीं बनाता कि नई version ने पुरानी version में मौजूद ज्ञात problem को सच में solve किया है या नहीं
अगर maintainers कम हों या यह 1-person project हो, तो क्या यह ज़्यादा logical नहीं होगा कि अकेला maintainer कई दिन से कई हफ्ते verification में लगाने के बजाय bug reporters अपने-अपने 10–15 मिनट देकर देखें कि problem अब भी मौजूद है या नहीं?
खासकर अगर bug reproduce करना मुश्किल या complex हो, तो यह भी अनिश्चित है कि maintainer अपने environment में उसे reproduce कर पाएगा या नहीं, और reporter के उस bug को observe करने का आदी होने की संभावना ज़्यादा है
अगर बड़ी team हो या commercial service का companion project हो, तो यह balance थोड़ा बदल सकता है
कई free/open source projects में जो दिखता है, वह यह है कि sleeves rolled up करके सच में काम करने वाले लोग बहुत कम होते हैं, लेकिन साथ ही यह बताने, मांग रखने और ढेर सारे suggestions देने में काफी समय लगाते हैं कि project उनके लिए कितना essential है
अधिकतर लोग wishlist बताने के लिए नया issue बनाते हैं या बहुत vague bug report छोड़ते हैं। उनमें से कुछ अच्छी bug reports भी देते हैं, लेकिन contribution की इच्छा आमतौर पर वहीं तक होती है
व्यक्तिगत तौर पर, मैं अक्सर दिखने वाली comments में से ज़्यादातर को diplomatic तरीके से handle करने की इच्छा नहीं रखता, इसलिए project maintenance मेरे स्वभाव का काम नहीं है
फिर भी जिन issues को मैं report करता हूँ, उन पर अपना हिस्सा निभाने के लिए मैं हमेशा cause trace करने और संभव हो तो fix वाला PR submit करने की कोशिश करता हूँ
उसका एक variant भी है। किसी major version के लिए issue report हुआ, लेकिन नया major version आ गया; rewrite भी नहीं, सिर्फ incremental changes हैं, फिर भी यह कहकर previous release issues सब close कर दिए जाते हैं कि problem अब शायद नहीं रही होगी
ऐसा PR बना देना चाहिए जिसमें tests हों जिन्हें pass होना चाहिए, लेकिन फिलहाल skip के रूप में mark किया गया हो। फिर rebuild करते समय progress check करने और improvement देखने का आसान रास्ता बन जाता है
अगर problem सच में मायने रखती है, तो उसमें test जोड़ना चाहिए
security findings को भी कभी-कभी इसी तरह handle किया जाता है
closed source software projects में भी मेरा experience ऐसा ही है
lodash के author John-David Dalton ने [पिछले साल ऐसा][1] लिखा था
lodash rewrite में technical debt bankruptcy declare करता हूँ। TypeScript और Rollup के साथ शुरुआत से शुरू कर रहा हूँ। FP wrappers नहीं। वह trend खत्म हो गया। जिसने वह headache codebase में लाया, उसके colleagues के प्रति संवेदना। यह team या इंसान, किसी के लिए भी friendly नहीं है
पता नहीं 100% वैसे ही हो रहा है या नहीं, लेकिन काफी करीब लगता है
[1]: https://twitter.com/jdalton/status/1571863497969119238
“वह trend खत्म हो गया। जिसने वह headache codebase में लाया, उसके colleagues के प्रति संवेदना। यह team या इंसान, किसी के लिए भी friendly नहीं है” — क्या original author वही खुद नहीं हैं?
सुनने में ऐसा लगता है जैसे कोई और वह complexity जोड़ गया हो जिसकी वह आलोचना कर रहे हैं। अगर उन्होंने खुद introduce किया था, तो reflection या learning की तरह कहने के बजाय, ऐसा लग रहा है जैसे trend के हिसाब से project develop किया और अब वह trend खत्म हो गया है, इसलिए अगली चीज़ पर जाने का समय है
FP wrapper क्या था, और कौन-सा trend था?
JavaScript side के issues मुझे अच्छी तरह नहीं पता, तो इस context में functional programming में problem क्या है?
सही किया
लिस्ट के आगे के कुछ PR ही देखें तो ऐसी चीज़ें मिलती हैं
कमेंट में एक शब्द जोड़ना, डेवलपमेंट सर्विस के प्रचार के लिए config file जोड़ना, var को let में बदलना, core function के अच्छी तरह स्थापित behavior को बदलना, semicolon हटाना वगैरह
ज़्यादातर PR शायद लाइब्रेरी को बेहतर बनाने की अच्छी नीयत से खोले गए होंगे, लेकिन किसी मोड़ पर maintainer के लिए वे बस spam बन जाते हैं, या इससे भी बुरा, जितना वे ध्यान नहीं दे पाते उतना ही guilt बढ़ाने वाला बोझ बन जाते हैं
जैसे मशहूर लोग लगातार ध्यान से बचने और अपनी मानसिक शांति बचाने के लिए bodyguards रखते हैं और first class या private jet से उड़ते हैं, वैसे ही सोचता हूं कि मशहूर open source projects के लिए क्या कदम संभव हैं
निजी तौर पर, एक open source maintainer के रूप में मुझे typo, wording fix, और automated refactoring PR सबसे पसंद हैं। Review में लगभग कोई मेहनत नहीं लगती, इसलिए लगभग हमेशा बहुत जल्दी merge कर देता हूं
सबसे ज़्यादा समय वे PR लेते हैं जो बड़े features implement करते हैं। उनमें बहुत review और discussion चाहिए होता है, इसलिए उन्हें detail में देखना टलता रहता है
कुछ समय तक मशहूर projects में छोटे-मोटे PR खोलने का trend था। मुझे लगता है यह resume भरने की कोशिश थी
एक खास GitHub user था जो कई JavaScript projects में बार-बार सिर्फ var को let में बदलने वाले PR डालता था
यह GitHub profile भरने जैसा लगता था
वाह
अपने package को Bun पर ले जाने में मेरी दिलचस्पी शुरू हो गई थी, लेकिन compatibility और यह कि Bun सच में लंबे समय तक टिकेगा या नहीं, इसे लेकर चिंता के कारण हिचक रहा था। “Modern Yarn” से थोड़ा हाथ भी जल चुका है। लेकिन lodash को migrate होते देखकर अब इसे और गंभीरता से evaluate करना चाहता हूं
यह सच में बड़ी खबर है। खासकर यह देखते हुए कि हाल की v1.0 release के बावजूद Windows पर performance issues हैं
मैं open source developers को यह बताने से बचने की कोशिश करता हूं कि उन्हें अपना project कैसे चलाना चाहिए। मैं भी open source developer हूं, और जब लोग मेरे साथ ऐसा करते हैं तो चिढ़ होती है
लेकिन अगर मैं ऐसा user होता जिसने issue लिखने और समस्या सुलझाने में काफी समय लगाया हो, या जिसने fix या नया feature बनाकर PR भेजा हो, तो अभी मेरी motivation काफी टूट गई होती
लेकिन ज़्यादातर users issue लिखने में बहुत कम समय लगाते हैं। ज़्यादातर bug reports खराब होती हैं
Issues बंद हुए हैं, गायब नहीं हुए। अगर वे अब भी relevant हैं, तो शायद बाद में फिर से request किया जा सकता है
Issue bankruptcy वास्तविक है। अपने अनुभव से कहूं तो, किसी मोड़ पर open source maintain करना वास्तविक दुनिया में जीने के साथ compatible नहीं रह जाता
काम free होता है और अक्सर उसकी सराहना नहीं होती। बेशक हमेशा ऐसा नहीं होता। Problems complex होती हैं, और work, family, rest जैसी वास्तविक जिम्मेदारियों से compete करती हैं। लोग आसानी से चिढ़ जाते हैं, नियमित रूप से बहस करना चाहते हैं या आपसे उनके लिए documentation पढ़ने को कहते हैं। Open source अगर famous हो तो उसके साथ बहुत बड़ी जिम्मेदारी भी आती है
मुझे लगता है open source ecosystem में बड़ा collapse आ सकता है, जब projects चलाने वाले लोग “बस, बहुत हुआ” कहकर ज़्यादा महत्वपूर्ण चीज़ों की ओर चले जाएंगे
यह समझ आता है। आजकल तो मुझे लगने लगा है कि non-trivial personal project असल project से ज़्यादा addiction या self-harm जैसा है
हालांकि open source ecosystem पागलपन की हद तक inefficient है। lodash, underscore, और ढेरों दूसरी libraries हैं, जबकि उन सबका मौजूद होना जरूरी नहीं है। ऐसी बहुत-सी libraries हैं जो सिर्फ एक काम करती हैं, और आम तौर पर वे इन libraries के subset जैसी होती हैं
इनमें से ज़्यादातर minifier और tree shaking के साथ इस्तेमाल होती हैं, और unused features हट जाते हैं। भारी libraries भी आसानी से optimize हो जाती हैं और ज़्यादातर अलग-अलग हिस्सों से बनी होती हैं, इसलिए हल्की library की खास जरूरत नहीं होती और development effort आम तौर पर linearly बढ़ता है
अगर programmers elegance और simplicity को सबसे ऊपर पसंद न करते, और थोड़ा भी बेहतर बनाने के लिए बार-बार फिर से लिखना न चाहते, तो मुझे लगता है कि सभी लोग अभी जितना समय लगाते हैं उसका सिर्फ एक-चौथाई भी लगाएं तो open source के लिए लोग काफी होंगे
Lodash एक बेहतरीन लाइब्रेरी है। मैं जिन लगभग हर प्रोजेक्ट पर काम करता हूँ, उनमें इसका थोड़ा-बहुत इस्तेमाल हो ही जाता है
लेकिन JavaScript लगातार बेहतर होती जा रही है, इसलिए Lodash का इस्तेमाल धीरे-धीरे कम होता जा रहा है। हर बार इस्तेमाल करते समय मैं देखता हूँ कि जो काम मैं करना चाहता हूँ, उसके लिए कोई built-in feature है या नहीं। PR पर “इसके लिए Lodash की जरूरत नहीं है” वाला लिंक लगाकर comment करना भी काफ़ी अक्सर होता है
फिर भी उम्मीद है कि यह प्रोजेक्ट से हाथ खींचने का संकेत नहीं है
यह निश्चित रूप से सुविधाजनक है, लेकिन आखिरकार अगर जरूरत पड़े तो utilities के लिए मैं शायद अपना बनाया हुआ version ज़्यादा पसंद करूँगा
मैंने 8 साल पहले से lodash या underscore.js इस्तेमाल नहीं किया है। समझ नहीं आता कि ऐसा क्या है जो map, filter, find वगैरह से आसानी से नहीं किया जा सकता
issue tracker में दो तरह के उपयोग overlap करते हैं। एक है maintainers के किए जाने वाले काम को track करने का तरीका, और दूसरा है व्यापक community और users द्वारा software की खामियों को track करने का तरीका
“issue bankruptcy” घोषित करना पहले उपयोग के लिए समझ में आता है, लेकिन दूसरे उपयोग में यह current version में मौजूद issues के बारे में कीमती जानकारी मिटा देने जैसा है
1 टिप्पणियां
Hacker News की राय
यह वाकई दोतरफा मामला है। एक तरफ, यह बहुत अच्छा है। शायद ही कोई ऐसा हो जिसने backlog grooming meeting न झेली हो, जहाँ ऊपर से खुरचते हुए आगे बढ़ते हैं, जबकि पता होता है कि अंत तक पहुँचना नामुमकिन है; और वह एहसास सच में दयनीय होता है
दूसरी तरफ, issues गायब नहीं हुए हैं, बस उनका tag बदल गया है। अगर सब कुछ tags और organization का ही मामला है, तो पूरी तरह खाली issue list जैसी छद्म-आदर्श स्थिति को control करने की कोशिश करने के बजाय इसे flow पर छोड़ देना ठीक नहीं होगा? ऐसी notes को दिखने वाली जगह पर छोड़ने के फायदे भी निश्चित रूप से होंगे। यह कुछ वैसा है जैसे बड़ी सफाई में किसी चीज़ को फेंकने का फैसला किया हो, लेकिन अवचेतन कहे कि शायद बाद में ज़रूरत पड़ जाए, इसलिए संभालकर रखो
फिर भी कुल मिलाकर मैं समर्थन में हूँ। कम से कम इससे मुक्ति का एहसास और नए issues के लिए recharge होने का असर तो होगा
rewrite version को पहले release करके फिर existing issues को deprecated बताकर close करना ज़्यादा साफ-सुथरा होता। rewrite branch के issues को version tags से अलग किया जा सकता था। नई version अभी खत्म नहीं हुई है और अगर इसी बीच close किया जाए, तो contributors यह जाने बिना कि support अब नहीं है, existing version पर नए issues खोल सकते हैं
फिर भी ऐसा नहीं है कि issues को ignore करके codebase में problems छोड़ दी जा रही हैं; पूरा project नए सिरे से व्यवस्थित किया जा रहा है
https://twitter.com/jdalton/status/1571863497969119238
मेरे हिसाब से project के लिए issue के अस्तित्व को स्वीकार करके उसे open रखना ज़्यादा ईमानदार है। developer के नज़रिए से अगर issue count खटकता है, तो पुराने कम-महत्वपूर्ण issues को छिपाने के लिए filter इस्तेमाल करना बेहतर होगा
jwz ने ऐसा कहा था
खासकर अगर bug reproduce करना मुश्किल या complex हो, तो यह भी अनिश्चित है कि maintainer अपने environment में उसे reproduce कर पाएगा या नहीं, और reporter के उस bug को observe करने का आदी होने की संभावना ज़्यादा है
अगर बड़ी team हो या commercial service का companion project हो, तो यह balance थोड़ा बदल सकता है
कई free/open source projects में जो दिखता है, वह यह है कि sleeves rolled up करके सच में काम करने वाले लोग बहुत कम होते हैं, लेकिन साथ ही यह बताने, मांग रखने और ढेर सारे suggestions देने में काफी समय लगाते हैं कि project उनके लिए कितना essential है
अधिकतर लोग wishlist बताने के लिए नया issue बनाते हैं या बहुत vague bug report छोड़ते हैं। उनमें से कुछ अच्छी bug reports भी देते हैं, लेकिन contribution की इच्छा आमतौर पर वहीं तक होती है
व्यक्तिगत तौर पर, मैं अक्सर दिखने वाली comments में से ज़्यादातर को diplomatic तरीके से handle करने की इच्छा नहीं रखता, इसलिए project maintenance मेरे स्वभाव का काम नहीं है
फिर भी जिन issues को मैं report करता हूँ, उन पर अपना हिस्सा निभाने के लिए मैं हमेशा cause trace करने और संभव हो तो fix वाला PR submit करने की कोशिश करता हूँ
अगर problem सच में मायने रखती है, तो उसमें test जोड़ना चाहिए
lodash के author John-David Dalton ने [पिछले साल ऐसा][1] लिखा था
सुनने में ऐसा लगता है जैसे कोई और वह complexity जोड़ गया हो जिसकी वह आलोचना कर रहे हैं। अगर उन्होंने खुद introduce किया था, तो reflection या learning की तरह कहने के बजाय, ऐसा लग रहा है जैसे trend के हिसाब से project develop किया और अब वह trend खत्म हो गया है, इसलिए अगली चीज़ पर जाने का समय है
सही किया
लिस्ट के आगे के कुछ PR ही देखें तो ऐसी चीज़ें मिलती हैं
कमेंट में एक शब्द जोड़ना, डेवलपमेंट सर्विस के प्रचार के लिए config file जोड़ना,
varकोletमें बदलना, core function के अच्छी तरह स्थापित behavior को बदलना, semicolon हटाना वगैरहज़्यादातर PR शायद लाइब्रेरी को बेहतर बनाने की अच्छी नीयत से खोले गए होंगे, लेकिन किसी मोड़ पर maintainer के लिए वे बस spam बन जाते हैं, या इससे भी बुरा, जितना वे ध्यान नहीं दे पाते उतना ही guilt बढ़ाने वाला बोझ बन जाते हैं
जैसे मशहूर लोग लगातार ध्यान से बचने और अपनी मानसिक शांति बचाने के लिए bodyguards रखते हैं और first class या private jet से उड़ते हैं, वैसे ही सोचता हूं कि मशहूर open source projects के लिए क्या कदम संभव हैं
सबसे ज़्यादा समय वे PR लेते हैं जो बड़े features implement करते हैं। उनमें बहुत review और discussion चाहिए होता है, इसलिए उन्हें detail में देखना टलता रहता है
varकोletमें बदलने वाले PR डालता थायह GitHub profile भरने जैसा लगता था
इससे बड़ी खबर यह है कि Lodash Node.js से Bun पर जा रहा है: https://github.com/lodash/lodash/commit/97d4a2fe193a66f5f96d...
अपने package को Bun पर ले जाने में मेरी दिलचस्पी शुरू हो गई थी, लेकिन compatibility और यह कि Bun सच में लंबे समय तक टिकेगा या नहीं, इसे लेकर चिंता के कारण हिचक रहा था। “Modern Yarn” से थोड़ा हाथ भी जल चुका है। लेकिन lodash को migrate होते देखकर अब इसे और गंभीरता से evaluate करना चाहता हूं
मैं open source developers को यह बताने से बचने की कोशिश करता हूं कि उन्हें अपना project कैसे चलाना चाहिए। मैं भी open source developer हूं, और जब लोग मेरे साथ ऐसा करते हैं तो चिढ़ होती है
लेकिन अगर मैं ऐसा user होता जिसने issue लिखने और समस्या सुलझाने में काफी समय लगाया हो, या जिसने fix या नया feature बनाकर PR भेजा हो, तो अभी मेरी motivation काफी टूट गई होती
issue bankruptcytag लगाकर 363 issues बंद किए गए: https://github.com/lodash/lodash/issues?q=is%3Aissue+is%3Acl...PRs भी 325 इसी तरह हैं: https://github.com/lodash/lodash/pulls?q=is%3Apr+is%3Aclosed...
Issue bankruptcy वास्तविक है। अपने अनुभव से कहूं तो, किसी मोड़ पर open source maintain करना वास्तविक दुनिया में जीने के साथ compatible नहीं रह जाता
काम free होता है और अक्सर उसकी सराहना नहीं होती। बेशक हमेशा ऐसा नहीं होता। Problems complex होती हैं, और work, family, rest जैसी वास्तविक जिम्मेदारियों से compete करती हैं। लोग आसानी से चिढ़ जाते हैं, नियमित रूप से बहस करना चाहते हैं या आपसे उनके लिए documentation पढ़ने को कहते हैं। Open source अगर famous हो तो उसके साथ बहुत बड़ी जिम्मेदारी भी आती है
मुझे लगता है open source ecosystem में बड़ा collapse आ सकता है, जब projects चलाने वाले लोग “बस, बहुत हुआ” कहकर ज़्यादा महत्वपूर्ण चीज़ों की ओर चले जाएंगे
हालांकि open source ecosystem पागलपन की हद तक inefficient है। lodash, underscore, और ढेरों दूसरी libraries हैं, जबकि उन सबका मौजूद होना जरूरी नहीं है। ऐसी बहुत-सी libraries हैं जो सिर्फ एक काम करती हैं, और आम तौर पर वे इन libraries के subset जैसी होती हैं
इनमें से ज़्यादातर minifier और tree shaking के साथ इस्तेमाल होती हैं, और unused features हट जाते हैं। भारी libraries भी आसानी से optimize हो जाती हैं और ज़्यादातर अलग-अलग हिस्सों से बनी होती हैं, इसलिए हल्की library की खास जरूरत नहीं होती और development effort आम तौर पर linearly बढ़ता है
अगर programmers elegance और simplicity को सबसे ऊपर पसंद न करते, और थोड़ा भी बेहतर बनाने के लिए बार-बार फिर से लिखना न चाहते, तो मुझे लगता है कि सभी लोग अभी जितना समय लगाते हैं उसका सिर्फ एक-चौथाई भी लगाएं तो open source के लिए लोग काफी होंगे
Lodash एक बेहतरीन लाइब्रेरी है। मैं जिन लगभग हर प्रोजेक्ट पर काम करता हूँ, उनमें इसका थोड़ा-बहुत इस्तेमाल हो ही जाता है
लेकिन JavaScript लगातार बेहतर होती जा रही है, इसलिए Lodash का इस्तेमाल धीरे-धीरे कम होता जा रहा है। हर बार इस्तेमाल करते समय मैं देखता हूँ कि जो काम मैं करना चाहता हूँ, उसके लिए कोई built-in feature है या नहीं। PR पर “इसके लिए Lodash की जरूरत नहीं है” वाला लिंक लगाकर comment करना भी काफ़ी अक्सर होता है
फिर भी उम्मीद है कि यह प्रोजेक्ट से हाथ खींचने का संकेत नहीं है
...भर से भी बहुत बड़ा असर हुआ। https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... iterator helpers भी जल्द ही rollout होने वाले हैं, इसलिए वे काफ़ी मददगार होंगे। async iterator helpers शायद कुछ समय तक देर से आएँगे। https://github.com/tc39/proposal-iterator-helpersपहले ऐसा लगता था कि जिस codebase पर काम कर रहा था उसमें functions को creatively call करने के लिए हर हफ्ते कई बार
.apply()इस्तेमाल करना पड़ता था। https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... अब यह सब गायब हो गया है, और टीम के 50% लोग.callऔर.applyजानते हैं या नहीं, यह भी शायद fifty-fifty ही होगाChrome 117 में
Object.groupBy()आ रहा है, और यह lodash का इस्तेमाल कराने वाली आख़िरी कई वजहों को हटाने में बहुत मदद करेगा। https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...map,filter,findवगैरह से आसानी से नहीं किया जा सकताissue tracker में दो तरह के उपयोग overlap करते हैं। एक है maintainers के किए जाने वाले काम को track करने का तरीका, और दूसरा है व्यापक community और users द्वारा software की खामियों को track करने का तरीका
“issue bankruptcy” घोषित करना पहले उपयोग के लिए समझ में आता है, लेकिन दूसरे उपयोग में यह current version में मौजूद issues के बारे में कीमती जानकारी मिटा देने जैसा है