- Zig issues, Pull Requests, bug tracker comments और translations में LLM के उपयोग पर सख्त रोक लगाता है
- अंग्रेज़ी का उपयोग केवल recommendation है, अनिवार्य नहीं; contributor अपनी मातृभाषा में लिख सकते हैं और दूसरे लोग अपनी पसंद के translation tools से उसे समझ सकते हैं
- Bun ने अपने Zig fork में LLVM backend के लिए parallel semantic analysis और multiple codegen units जोड़कर Bun compilation में 4x performance improvement हासिल किया, लेकिन LLM-लिखित contributions पर रोक के कारण फिलहाल इसे upstream करने की योजना नहीं है
- Zig का review model अधूरे PR को खारिज करने के बजाय नए contributors को merge करने योग्य काम तक पहुँचने में मदद करता है, और individual contribution से ज़्यादा contributor growth को महत्व देता है
- ज़्यादातर LLM द्वारा लिखे गए PR review time को reliable नए contributors बढ़ाने में उपयोगी नहीं रहने देते, और maintainer के पास वही समस्या सीधे LLM चलाकर हल करने का विकल्प भी होता है
Policy और Bun fork का टकराव
- Zig ने Code of Conduct में issues, Pull Requests, bug tracker comments और translations में LLM के उपयोग पर रोक साफ़ तौर पर लिखी है
- अंग्रेज़ी का उपयोग recommendation है, और contributor अपनी मातृभाषा में लिख सकते हैं
- दूसरे लोग अपनी पसंद के translation tools से उसे समझ सकते हैं
- Zig में लिखे गए प्रमुख प्रोजेक्ट्स में Bun JavaScript runtime शामिल है, और Bun का 2025 के दिसंबर में Anthropic द्वारा अधिग्रहण हुआ
- Bun अपना अलग Zig fork चलाता है, और LLVM backend में “parallel semantic analysis and multiple codegen units” जोड़कर Bun compilation में 4x performance improvement हासिल की
- संबंधित code oven-sh/zig compare link पर सार्वजनिक है
- Bun की फिलहाल इसे upstream करने की योजना नहीं है क्योंकि Zig LLM-लिखित contributions पर सख्ती से रोक लगाता है
- Zig core contributor के अनुसार यह patch LLM मुद्दे से अलग भी स्वीकार किया जाना मुश्किल है
- parallel semantic analysis लंबे समय से planned feature है, लेकिन इसका असर खुद Zig language पर पड़ता है
Contributor Poker और contributor-केंद्रित review
- Contributor Poker and Zig's AI Ban में contributor poker Zig की सख्त रोक को समझने के लिए एक अहम रूपक है
- सफल open source projects उस चरण में पहुँचते हैं जहाँ उन्हें संभाली जा सकने वाली मात्रा से अधिक PR मिलते हैं
- ROI को अधिकतम करने के लिए Zig अधूरे PR को ठुकराने के बजाय नए contributors को उनके काम को mergeable बनाने में मदद करना चुनता है
- इस approach को सिर्फ “सही काम” नहीं बल्कि “स्मार्ट काम” भी माना जाता है
- Zig individual contributions से ज़्यादा contributors को महत्व देता है
- PR review और acceptance का प्राथमिक लक्ष्य नया code जोड़ना नहीं, बल्कि ऐसे लोगों को मदद देना है जो समय के साथ reliable और productive contributors बन सकते हैं
- हर contributor, Zig core team के लिए investment का विषय बनता है
- LLM support इस structure को तोड़ देता है
- भले ही LLM एक perfect PR लिखने में मदद करे, Zig team का review पर लगाया गया समय नए, आत्मविश्वासी और reliable contributors बढ़ाने में योगदान नहीं देता
- “contributor poker” यह रूपक है कि खेल cards नहीं बल्कि लोगों को देखकर खेला जाता है
- इसका मतलब पहले PR की सामग्री से अधिक contributor पर दांव लगाना है
- अगर PR का अधिकांश हिस्सा LLM ने लिखा हो, तो project maintainer के पास उस PR को review और discuss करने के बजाय सीधे LLM चलाकर वही समस्या हल करने का विकल्प होता है
अभी कोई टिप्पणी नहीं है.