Open source projects में AI-assisted कोड कैसे सबमिट करें

AI-assisted कोड को upstream भेजने से पहले क्या करें

Open source projects अब AI-assisted कोड पर अपनी नीतियां प्रकाशित करते हैं, और ये नीतियां एक-दूसरे से मेल नहीं खाती हैं। इसलिए आदत सरल है: patch लिखने से पहले policy खोजें, और उसे भेजते समय सटीक जानकारी दें। एक नियम दोनों के अंतर्गत आता है। ऐसी कोई भी लाइन सबमिट न करें जिसे आप review के दौरान समझा न सकें।

यदि project generated कोड पर प्रतिबंध लगाता है, या यदि आपने यह छिपाया है कि कोड कहाँ से आया है, तो एक सही patch भी बंद (close) कर दिया जाता है। इसका नुकसान आपके नाम पर होता है और वहीं बना रहता है, क्योंकि जो maintainer बाद में इस चूक का पता लगाता है, उसके पास आपके बाकी इतिहास पर भरोसा करने का कोई कारण नहीं होता। पहले कुछ शब्द, क्योंकि नीतियां उनका उपयोग करती हैं। एक LLM (large language model) आपके coding agent के पीछे का model है। GitHub पर एक PR (pull request), GitLab पर एक MR (merge request) है, और नीचे दी गई हर बात दोनों पर लागू होती है। DCO (developer certificate of origin) commit message के नीचे की sign-off लाइन है, और यह पूरी बहस का केंद्र साबित होती है।

AI कोड पर ओपन सोर्स नीतियां किस स्थिति में हैं

प्रोजेक्ट्स चार श्रेणियों में विभाजित हो गए हैं। नीचे दिए गए प्रत्येक उदाहरण की एक तारीख है, क्योंकि ये नियम बदलते रहते हैं।

प्रतिबंधित (Banned)। Gentoo की काउंसिल ने 14 April 2024 को मतदान किया कि "Natural Language Processing आर्टिफिशियल इंटेलिजेंस टूल्स की सहायता से बनाई गई किसी भी सामग्री को Gentoo में योगदान देना स्पष्ट रूप से वर्जित है"। NetBSD के कमिट दिशानिर्देश LLM से प्राप्त आउटपुट को "दूषित कोड" (tainted code) कहते हैं जिसे "कोर टीम की पूर्व लिखित स्वीकृति के बिना कमिट नहीं किया जाना चाहिए"। QEMU का कोड प्रोवेनेंस दस्तावेज़, August 2026 तक, अभी भी कहता है कि प्रोजेक्ट "किसी भी ऐसे योगदान को अस्वीकार (DECLINE) कर देगा जिसके बारे में माना जाता है कि उसमें AI द्वारा उत्पन्न सामग्री शामिल है या उससे ली गई है"।

केवल विश्लेषण (Analysis only)। अधिकांश प्रतिबंध हेडलाइन की तुलना में अधिक सीमित हैं। QEMU का दस्तावेज़ कहता है कि यह नीति "AI के अन्य उपयोगों पर लागू नहीं होती है, जैसे कि API या एल्गोरिदम पर शोध करना, स्टेटिक एनालिसिस, या डिबगिंग, बशर्ते उनका आउटपुट योगदान में शामिल न हो"। आप कोड पढ़ने के लिए एजेंट का उपयोग कर सकते हैं। आप वह कोड शिप नहीं कर सकते जो उसने लिखा है। यह अंतर अधिकांश प्रतिबंधात्मक प्रोजेक्ट्स के भीतर कार्यशील रेखा है, और यही वह बात है जिसे लोग अक्सर अनदेखा कर देते हैं।

खुलासा आवश्यक (Disclosure required)। Fedora की काउंसिल ने October 2025 में AI-सहायता प्राप्त योगदानों पर एक नीति को मंजूरी दी। यह टूल्स के उपयोग की अनुमति देती है और जिम्मेदारी व्यक्ति पर डालती है: योगदानकर्ता ही लेखक है, पूरे योगदान के लिए पूरी तरह से जवाबदेह है, और जब इसका कोई महत्वपूर्ण हिस्सा बिना किसी बदलाव के टूल से आया हो, तो उसे खुलासा करना होगा। Linux kernel ने December 2025 में अपनी प्रक्रिया प्रलेखन में एक कोडिंग असिस्टेंट पेज जोड़ा, जिसमें टूल को रिकॉर्ड करने के लिए एक ट्रेलर और कौन साइन-ऑफ कर सकता है, इस पर एक सख्त नियम शामिल है।

कुछ भी लिखित नहीं (Nothing written down)। यह अभी भी सामान्य स्थिति है। May 2026 के एक प्रीप्रिंट ने 1,000 लोकप्रिय GitHub रिपॉजिटरी का सर्वेक्षण किया और पाया कि केवल 118 में ही कोई लिखित AI नीति मौजूद है। चुप्पी का मतलब अनुमति नहीं है। पैच लिखने से पहले issue tracker में एक वाक्य में पूछें, और उत्तर एक सार्वजनिक रिकॉर्ड बन जाएगा जिसे आप बाद में संदर्भ के रूप में उपयोग कर सकते हैं।

मेंटेनर्स ने ये नियम क्यों बनाए

पहला कारण रिव्यू का बोझ है, और इसका गणित एक ही दिशा में काम करता है। एक एजेंट एक मिनट में 400 लाइनों का एक तर्कसंगत merge request तैयार कर देता है। उस request को सही ढंग से रिव्यू करने में एक मेंटेनर की पूरी दोपहर लग जाती है, और अधिकांश मेंटेनर्स स्वयंसेवक होते हैं। सबमिट करने की लागत लगभग शून्य हो गई है। रिव्यू करने की लागत में कोई कमी नहीं आई है।

curl इस वक्र (curve) के अंतिम छोर को दर्शाता है। Daniel Stenberg ने 2025 के मध्य में बताया कि प्रोजेक्ट के bug bounty के माध्यम से आने वाली लगभग पांचवीं सुरक्षा रिपोर्ट वह है जिसे वे AI slop कहते हैं: ऐसी रिपोर्टें जो वास्तविक functions और वास्तविक code paths का नाम लेती हैं, एक संभावित हमले का वर्णन करती हैं, लेकिन उनमें कुछ भी ठोस नहीं होता। प्रोजेक्ट ने फंडिंग की बाढ़ को जारी रखने के बजाय 2026 की शुरुआत में bounty को समाप्त कर दिया। वे पैच के बजाय रिपोर्ट थीं, लेकिन यह वही तंत्र है जो एक मेंटेनर को आपका PR खोलने से पहले ही थका देता है।

GNOME Calendar ने इस समस्या को एक लेबल के रूप में लिखा। जून 2026 में प्रोजेक्ट ने उन merge requests के लिए "Probabilistically Automated" लेबल पेश किया जो "कोड उत्पन्न करने के लिए कृत्रिम 'बुद्धिमत्ता' पर प्रमुख या पूर्ण निर्भरता" दिखाते हैं, और लक्षण का सटीक नाम दिया: "आमतौर पर उचित परीक्षण की कमी के साथ, और कोड की शुद्धता के बजाय सैद्धांतिक इच्छित व्यवहार के आधार पर पैच को अंतिम रूप देना"। उस अंतिम वाक्यांश को दो बार पढ़ें। कोड देखने में ऐसा लगता है कि उसे काम करना चाहिए। किसी ने यह जांचा ही नहीं कि क्या वह वास्तव में काम करता है।

दूसरा कारण प्रोवेनेंस (provenance) है, जिसका अर्थ है कि कोड कहाँ से आया और किस लाइसेंस के तहत है। QEMU इस संघर्ष को स्पष्ट रूप से बताता है: साइन-ऑफ करने का अर्थ है कि आप योगदान की गई सामग्री की "कॉपीराइट और लाइसेंस स्थिति को पूरी तरह समझते हैं", और मॉडल आउटपुट की कॉपीराइट स्थिति अनिश्चित है। Gentoo की काउंसिल ने गुणवत्ता और नैतिकता के साथ-साथ यही कारण बताया। आपको कानूनी व्याख्या से सहमत होने की आवश्यकता नहीं है। आपको बस यह ध्यान रखना होगा कि यह निर्णय मेंटेनर का है, आपका नहीं।

किसी प्रोजेक्ट की AI policy कैसे ढूँढें?

इन स्थानों पर, इसी क्रम में देखें।

• रिपॉजिटरी के रूट में CONTRIBUTING.md, फिर .github/CONTRIBUTING.md, और उसके बाद कोई भी DCO फाइल।
• डेवलपर दस्तावेज़। QEMU अपने नियम docs/devel/code-provenance.rst में रखता है। कर्नल अपने नियम Documentation/process/coding-assistants.rst में रखता है।
• प्रोजेक्ट की वेबसाइट या विकी। Gentoo की policy काउंसिल के विकी पेज पर है, और NetBSD की policy कमिट गाइडलाइन्स में है।
• इश्यू ट्रैकर और मेलिंग लिस्ट आर्काइव। रिपॉजिटरी में लिखे जाने से महीनों पहले ही policy आमतौर पर वहाँ मौजूद होती है।

चेकआउट के अंदर से, एक grep कमांड से अधिकांश जानकारी मिल जाती है:

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

फिर प्रोजेक्ट का अपना इतिहास पढ़ें, क्योंकि कमिट की गई परंपरा किसी भी सारांश से बेहतर होती है:

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

ट्रेलर वैल्यू के बगल में दी गई संख्या आपको वह फॉर्म बताती है जिसका उपयोग यह प्रोजेक्ट वास्तव में करता है। यदि परिणाम खाली है, तो इसका मतलब है कि यहाँ किसी ने भी उस फॉर्म में खुलासा नहीं किया है, जो अपने आप में एक जानकारी है। यदि प्रोजेक्ट GitHub पर है और workflow आपके लिए नया है, तो GitHub पर pull requests और forks कैसे काम करते हैं उन मैकेनिक्स को कवर करता है जिन्हें यह सेक्शन आधार मानता है।

Commit trailer में खुलासा करें, comment में नहीं

Trailer commit message के अंतिम पैराग्राफ में एक Key: value लाइन होती है। Git पहले से ही इस प्रारूप का उपयोग Signed-off-by: और Co-authored-by: के लिए करता है, और tools इसे parse करते हैं, इसलिए यह एकमात्र ऐसा खुलासा है जो code के साथ tree में आगे बढ़ता है।

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

Kernel इस प्रारूप को Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] के रूप में document करता है, और यह लाइन की सीमा के बारे में स्पष्ट है: "AI agents को Signed-off-by tags नहीं जोड़ने चाहिए। केवल मनुष्य ही कानूनी रूप से Developer Certificate of Origin (DCO) को प्रमाणित कर सकते हैं।" Agent का नाम Assisted-by पर जाता है। आपका नाम Signed-off-by पर जाता है। किसी tool को दूसरा नाम कभी न लिखने दें, और उसे कभी भी ऐसा Co-authored-by पता बनाने न दें जो किसी का नहीं है।

नाम अलग-अलग होते हैं, इसलिए अपना नाम बनाने के बजाय local नाम की प्रतिलिपि बनाएँ। मई 2026 में QEMU list में पोस्ट किए गए एक patch ने यांत्रिक परिवर्तनों, tests, docs और बीस लाइनों या उससे कम के bug fixes के लिए उस project के प्रतिबंध को ढीला करने का प्रस्ताव दिया था, जिसे AI-used-for: tests, docs जैसे trailer के साथ दर्ज किया गया था। अगस्त 2026 तक यह एक mailing list पर केवल एक प्रस्ताव है और committed document अभी भी generated content को स्वीकार नहीं करता है। एक project ने 2023 और 2026 के बीच दो बार अपना रुख बदला। अगला बदलाव आपके लिए नहीं रुकेगा, इसीलिए सूची से अधिक तरीका मायने रखता है।

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

--trailer के लिए Git 2.32 या उससे नया version चाहिए। दूसरा command value को सीधे आपको print करना चाहिए। एक खाली लाइन का मतलब है कि git ने trailer को parse नहीं किया, ऐसा लगभग हमेशा इसलिए होता है क्योंकि message के नीचे trailer block के भीतर कोई खाली लाइन या सामान्य वाक्य मौजूद होता है। आपके द्वारा पहले से लिखे गए series के लिए, git rebase --signoff origin/main हर commit में sign-off जोड़ता है, और git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt एक message file को edit करता है।

दो failure modes के लिए योजना बनाना उचित है। Squash merge commit message को फिर से लिखता है, इसलिए जिस project में squash होता है, वहाँ PR description में खुलासा दोहराएँ जहाँ maintainer उसे पढ़ता है। और review comment कोई record नहीं है, क्योंकि comments को edit किया जा सकता है और वे कभी भी git history में दर्ज नहीं होते हैं।

सटीकता दोनों तरफ काम करती है। आपके द्वारा हाथ से लिखे गए commit पर Assisted-by शोर है, और यह आपके वास्तविक खुलासों के मूल्य को कम करता है। Agent द्वारा लिखे गए commit पर इसे न लगाना ही वह कारण है जो संबंध समाप्त कर देता है।

Signed-off-by वास्तव में किस बात की पुष्टि करता है?

DCO एक संक्षिप्त टेक्स्ट है, संस्करण 1.1, जो developercertificate.org पर प्रकाशित है और जिसका उपयोग kernel, QEMU और कई अन्य परियोजनाओं द्वारा किया जाता है। Signed-off-by: Your Name <you@example.com> जोड़ने का अर्थ है कि आप इसे प्रमाणित कर रहे हैं। आप क्या प्रमाणित कर रहे हैं, इसे पढ़ें, क्योंकि अधिकांश लोग इसे बिना पढ़े ही sign कर देते हैं।

खंड (a) कहता है कि योगदान "मेरे द्वारा पूर्ण या आंशिक रूप से बनाया गया था और मुझे इसे फाइल में निर्दिष्ट open source license के तहत सबमिट करने का अधिकार है"। खंड (b) उन कार्यों को कवर करता है जो पहले के open source code पर आधारित हैं जिन्हें आप संशोधनों के साथ आगे बढ़ाने का अधिकार रखते हैं। खंड (c) उस कोड को कवर करता है जो आपको किसी ऐसे व्यक्ति द्वारा दिया गया है जिसने उसी बात को प्रमाणित किया है। खंड (d) कहता है कि आप समझते हैं कि योगदान और आपके sign-off में मौजूद व्यक्तिगत जानकारी सार्वजनिक है और इसे अनिश्चित काल तक रखा जाता है।

ध्यान दें कि क्या गायब है। DCO कभी नहीं कहता कि आपने हर character खुद टाइप किया है। यह कहता है कि आपको इस license के तहत कोड सबमिट करने का अधिकार है। यही कारण है कि generated code यहाँ अजीब स्थिति में होता है: प्रश्न authorship का नहीं है, बल्कि यह है कि क्या आप इसके origin (मूल) के लिए जवाबदेह हो सकते हैं। अधिकांश परियोजनाएं जिन्हें sign-off की आवश्यकता होती है, वे वास्तविक नाम भी मांगती हैं, इसलिए pseudonym (उपनाम) इस जांच में विफल रहता है। git commit -s के साथ वह लाइन जोड़ें, जो आपके git config से user.name और user.email को पढ़ती है। जब कोई DCO bot आपके PR को विफल कर देता है और उस commit का नाम बताता है जिसमें लाइन की कमी है, तो git rebase --signoff origin/main और आपकी branch पर force push इसे ठीक कर देता है।

Commit को sign करना और sign-off करना एक समान नहीं है

git commit -s एक टेक्स्ट लाइन जोड़ता है। git commit -S आपके GPG या SSH key का उपयोग करके commit object पर एक cryptographic signature बनाता है। ये दोनों अलग-अलग सवालों के जवाब देते हैं। Signature यह प्रमाणित करता है कि यह commit उस key के धारक की ओर से आया है और तब से इसमें कोई बदलाव नहीं किया गया है। यह इस बारे में कुछ नहीं कहता कि इसके अंदर का कोड कहाँ से आया है, इसलिए undisclosed generated code से भरा हुआ एक signed commit, signed होने के बावजूद policy का उल्लंघन हो सकता है। Sign-off उत्पत्ति के बारे में दावा है। Signature पहचान के बारे में दावा है। जो projects दोनों चाहते हैं, वे दोनों की मांग करेंगे।

कोड को review में सबमिट न करें जिसे आप समझा न सकें

यह एक परीक्षण है, और यह वास्तव में ईमानदारी के बारे में नहीं है। हर पंक्ति के लिए: यह किस उद्देश्य से है, और इसके बिना क्या खराब हो जाएगा? यदि इन दोनों में से कोई भी उत्तर गायब है, तो पैच तैयार नहीं है, क्योंकि review comment आने वाली है और आपका उत्तर फिर से generation का एक और दौर होगा। Reviewers इसे समझ सकते हैं। यही वह क्षण है जब एक contributor एक बोझ बन जाता है। किनारों (edges), खाली input, failure path, और दूसरे caller के बारे में भी यही प्रश्न पूछें।

इसे चलाकर देखें। इसे build करें, project की test suite चलाएं, और जिस bug को आप ठीक करने का दावा कर रहे हैं, उसके लिए एक reproducer लिखें। Kernel documentation स्पष्ट शब्दों में ईमानदार fallback प्रदान करती है: "यदि fix को build या test नहीं किया जा सका, या यदि कोई reproducer तैयार नहीं किया जा सका, तो इसे स्पष्ट रूप से बताएं: maintainers वर्तमान में unverfied reports और untested fixes का विश्लेषण करने में बहुत अधिक समय बर्बाद करते हैं।" यह लिखना कि "मैं इसे वास्तविक hardware पर test नहीं कर सका" आपको कुछ भी नुकसान नहीं पहुँचाता है। यह संकेत देना कि आपने ऐसा किया है, आपको project से बाहर कर देता है।

Review comments का उत्तर स्वयं दें, अपने शब्दों में और अपने समय पर। एक उत्तर जो comment के तीस सेकंड बाद आता है और उसे पांच पैराग्राफ में दोहराता है, वह maintainer को ठीक-ठीक बता देता है कि क्या हुआ है। Diff को भी छोटा रखें। चालीस पंक्तियाँ जिन्हें आप पूरी तरह से समझते हैं, वे चार सौ पंक्तियों के refactor से अधिक मूल्यवान हैं जिसकी आपने केवल निगरानी की है। यदि आपका agent आपको आपकी मांग से अधिक दे रहा है, तो सबसे छोटा बदलाव जो काम करता है, उस तक सीमित रहने का कौशल पैच को इतना छोटा रखने का एक तरीका है जिसका आप पंक्ति-दर-पंक्ति बचाव कर सकें।

एजेंट के निर्देशों को रिपॉजिटरी में रखें

आप अपने एजेंट को जो निर्देश देते हैं, वे आपकी टूलचेन का हिस्सा होते हैं, इसलिए उनके साथ कोड जैसा व्यवहार करें। रिपॉजिटरी रूट में मौजूद एक फाइल, आमतौर पर AGENTS.md, में बिल्ड कमांड, टेस्ट कमांड, कमिट मैसेज फॉर्मेट, साइन-ऑफ की आवश्यकता और प्रोजेक्ट द्वारा पहले से प्रलेखित स्टाइल नियम होते हैं। वह फाइल वर्शन्ड और रिव्यु करने योग्य होती है, और वह आज जैसी है, कल भी वैसी ही रहती है। हर सेशन में याददाश्त से दोबारा टाइप किए गए निर्देश हर बार एक अलग पैच तैयार करते हैं, और आपको यह पता नहीं चलेगा कि किस सेशन ने वह पैच तैयार किया जिसे रिजेक्ट कर दिया गया। एक ऐसी AGENTS.md लिखना जिसे एजेंट और इंसान दोनों पढ़ सकें इस फाइल के बारे में विस्तार से बताती है।

दूसरे लोगों की रिपॉजिटरी के बारे में एक सावधानी बरतें। अपना पहला योगदान ऐसी किसी प्रोजेक्ट में PR के रूप में न दें जिसे आप मेंटेन नहीं करते हैं। इसे बाहर से प्रोजेक्ट की टूलिंग पॉलिसी तय करने के प्रयास के रूप में देखा जाता है, और यह आपके अकाउंट को उस चीज से जोड़ने का एक त्वरित तरीका है जिससे मेंटेनर्स पहले ही परेशान हो चुके हैं। फाइल को अपने फोर्क में तब तक रखें जब तक कोई इसे न मांगे।

आप एजेंट को कहाँ चलाते हैं, यह भी इसी कारण से मायने रखता है। एक एजेंट जो आपके द्वारा नियंत्रित सैंडबॉक्स के भीतर प्रोजेक्ट को बिल्ड कर सकता है और उसके टेस्ट चला सकता है, वह आपको एक ऐसा पैच देता है जिसे आपने वास्तव में सत्यापित किया है, जो कि सहायता का खुलासा करने और अनुमान का खुलासा करने के बीच का अंतर है। अपने खुद के VPS पर कोडिंग एजेंट चलाना उस सेटअप को कवर करता है, और Claude Code, Cursor, Codex और Copilot के बीच व्यावहारिक अंतर बताता है कि ये टूल्स दैनिक उपयोग में कैसे भिन्न हैं।

पॉलिसी बदलने के बाद की प्रक्रिया

1. कुछ भी लिखने से पहले निर्धारित पॉलिसी ढूँढें: repository, developer docs, website, या tracker।
2. यदि कोई पॉलिसी नहीं है, तो issue में एक वाक्य में पूछें और उत्तर को सुरक्षित रखें।
3. प्रोजेक्ट द्वारा उपयोग किए जाने वाले फॉर्म में खुलासा करें, commit trailer में लिखें, और यदि प्रोजेक्ट squashing करता है तो PR body में इसे दोहराएँ।
4. अपने वास्तविक नाम के साथ sign off करें, यह जानते हुए कि यह पंक्ति कोड सबमिट करने के आपके अधिकार का दावा है।
5. अपने पैच की समीक्षा ऐसे करें जैसे किसी अजनबी ने इसे लिखा हो, क्योंकि वास्तव में किसी और ने ही ऐसा किया है।

इस पृष्ठ पर नामित प्रत्येक प्रोजेक्ट आपके पढ़ने तक स्थानांतरित हो चुका होगा। ये पाँच चरण कभी नहीं बदलते।

FAQ

क्या मुझे यह बताना होगा कि मैंने AI कोडिंग एजेंट का उपयोग किया है?

प्रोजेक्ट की जाँच करें, क्योंकि इसका उत्तर स्थानीय स्तर पर निर्धारित होता है। Fedora के लिए यह अनिवार्य है कि यदि योगदान का एक महत्वपूर्ण हिस्सा बिना किसी बदलाव के किसी टूल से आया है, तो उसका खुलासा किया जाए। Linux kernel एक Assisted-by ट्रेलर की मांग करता है। अगस्त 2026 तक, Gentoo और QEMU इस तरह के योगदान को स्वीकार नहीं करते हैं। जहाँ कहीं भी कोई लिखित नियम नहीं है, वहां भी commit ट्रेलर में खुलासा कर दें। यदि कोई maintainer बाद में स्वयं पता लगाता है, तो उसकी प्रतिक्रिया टूल के बजाय जानकारी छिपाने पर होगी, और वह प्रतिक्रिया आपके द्वारा भेजे गए अन्य सभी कार्यों पर भी असर डालेगी।

कौन से ओपन सोर्स प्रोजेक्ट AI-जनरेटेड कोड पर प्रतिबंध लगाते हैं?

अगस्त 2026 की स्थिति के अनुसार: अप्रैल 2024 से Gentoo, NetBSD जो LLM आउटपुट को दूषित कोड मानकर कोर अप्रूवल की मांग करता है, QEMU जो जनरेटेड कंटेंट से प्राप्त योगदान को अस्वीकार करता है, और Loupe तथा Calendar सहित कई GNOME एप्लिकेशन। इस सूची के बजाय प्रत्येक प्रोजेक्ट के अपने टेक्स्ट को पढ़ें, क्योंकि यह जानकारी पुरानी हो सकती है। ध्यान दें कि उनमें से अधिकांश में एक छूट साझा है: किसी API पर शोध करने, static analysis चलाने या डिबगिंग में सहायता के लिए मॉडल का उपयोग करना आमतौर पर ठीक है, बशर्ते उसका आउटपुट पैच में शामिल न हो।

Signed-off-by और signed commit के बीच क्या अंतर है?

Signed-off-by एक सादा टेक्स्ट लाइन है जिसे git commit -s द्वारा जोड़ा जाता है। यह developer certificate of origin को प्रमाणित करता है, जिसका अर्थ है कि आपके पास इस कोड को प्रोजेक्ट के लाइसेंस के तहत सबमिट करने का अधिकार है। git commit -S के साथ किया गया एक signed commit, आपके GPG या SSH key के साथ commit ऑब्जेक्ट पर एक क्रिप्टोग्राफिक हस्ताक्षर है। यह साबित करता है कि commit आपकी key से आया है और इसमें कोई बदलाव नहीं किया गया है। मूल (origin) और पहचान (identity) अलग-अलग दावे हैं, इसलिए एक signed commit भी AI नीति का उल्लंघन कर सकता है।

क्या मैं डिस्क्लोजर को commit मैसेज के बजाय pull request विवरण में डाल सकता हूँ?

इसे commit मैसेज में ही डालें, क्योंकि यही वह रिकॉर्ड है जो git हिस्ट्री में दर्ज होता है और कोड के साथ आगे बढ़ता है, जिसे भी आप बाद में रिपॉजिटरी क्लोन करने के लिए देते हैं। pull request विवरण को बाद में संपादित किया जा सकता है और वह केवल होस्टिंग प्लेटफॉर्म पर ही रहता है। जब प्रोजेक्ट squash merge का उपयोग करता है, तो PR बॉडी में भी इसे जोड़ें, क्योंकि squash आपके commit मैसेज को फिर से लिखता है और ट्रेलर को हटा सकता है।

मेरा pull request इसलिए बंद कर दिया गया क्योंकि वह AI-जनरेटेड था। अब क्या करें?

थ्रेड में नीति पर बहस न करें, क्योंकि इसे बंद करने वाले व्यक्ति ने अकेले नियम नहीं बनाया है और थ्रेड वह जगह नहीं है जहाँ इसे बदला जा सके। नीति का टेक्स्ट पढ़ें, फिर तय करें कि क्या आप उसका पालन कर सकते हैं। जहाँ प्रोजेक्ट जनरेटेड पैच पर प्रतिबंध लगाते हैं, वहाँ एक स्पष्ट बग रिपोर्ट जिसमें reproducer हो और पैच न हो, फिर भी स्वागत योग्य है, और यह अक्सर अधिक उपयोगी योगदान होता है। यदि आप कोड के साथ वापस आते हैं, तो एक छोटे बदलाव के साथ आएं जिसे आप लाइन-दर-लाइन डिफेंड कर सकें।