AI-सहाय्यित कोड पाठवण्यापूर्वी मुक्त-स्रोत धोरण तपासा

AI च्या मदतीने तयार केलेला कोड upstream कडे पाठवण्यापूर्वी काय करावे

ओपन सोर्स प्रकल्प आता AI-सहाय्यित कोडसाठी धोरणे प्रकाशित करतात. ही धोरणे एकमेकांशी सुसंगत असतीलच असे नाही. त्यामुळे साधी पद्धत अवलंबा: patch लिहिण्यापूर्वी धोरण शोधा आणि patch पाठवताना अचूकपणे माहिती द्या. या दोन्ही गोष्टींमागे एक मूलभूत नियम आहे. review मध्ये स्पष्ट करता येणार नाही अशी एकही ओळ submit करू नका.

प्रकल्पाने generated code वर बंदी घातली असेल किंवा कोडचा स्रोत लपवला असेल, तर योग्य patch देखील बंद केला जाऊ शकतो. याचा परिणाम तुमच्या नावावर होतो आणि तो तिथेच राहतो. कारण 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 कोडसंदर्भातील मुक्त-स्रोत धोरणे कुठे पोहोचली आहेत

प्रकल्प चार गटांमध्ये स्थिरावले आहेत. खालील प्रत्येक उदाहरणाला तारीख दिली आहे, कारण हे मजकूर बदलत राहतात.

बंदी. Gentoo च्या council ने 14 April 2024 रोजी ठरवले की, “Natural Language Processing artificial intelligence tools च्या सहाय्याने तयार केलेला कोणताही मजकूर Gentoo मध्ये योगदान देणे स्पष्टपणे निषिद्ध आहे”. NetBSD च्या commit guidelines मध्ये LLM कडून मिळालेल्या output ला “tainted code” म्हटले आहे आणि “core कडून आधी लेखी मंजुरी घेतल्याशिवाय ते commit करू नये” असे नमूद केले आहे. August 2026 पर्यंत QEMU च्या code provenance document मध्येही प्रकल्प “AI generated content समाविष्ट असल्याचे किंवा त्यातून घेतले असल्याचे मानले जाणारे कोणतेही योगदान नाकारेल” असेच म्हटले आहे.

फक्त विश्लेषण. बहुतेक बंदी ही मथळ्यात दिसते त्यापेक्षा मर्यादित असते. QEMU च्या document नुसार, “AI च्या इतर वापरांना हे धोरण लागू होत नाही. उदाहरणार्थ, APIs किंवा algorithms चे संशोधन, static analysis किंवा debugging; मात्र त्यांचा output योगदानात समाविष्ट केलेला नसावा.” कोड वाचण्यासाठी तुम्ही agent वापरू शकता. त्याने लिहिलेला मजकूर तुम्ही release करू शकत नाही. हीच सीमारेषा बहुतेक प्रतिबंधात्मक प्रकल्पांमध्ये प्रत्यक्षात वापरली जाते आणि लोकांकडून तीच चुकते.

प्रकटीकरण आवश्यक. Fedora च्या council ने October 2025 मध्ये AI-assisted contributions संदर्भातील धोरण मंजूर केले. या साधनांना परवानगी आहे आणि जबाबदारी व्यक्तीवर ठेवली आहे: contributor हाच author असतो, संपूर्ण योगदानासाठी पूर्णपणे जबाबदार असतो आणि एखाद्या साधनातून आलेला महत्त्वपूर्ण भाग बदल न करता वापरला असल्यास ते जाहीर करणे आवश्यक असते. Linux kernel च्या process documentation मध्ये December 2025 मध्ये coding assistants साठी एक page जोडण्यात आले. त्यात tool नोंदवण्यासाठी trailer आणि sign off कोण करू शकतो यासंबंधी स्पष्ट नियम आहे.

काहीही लिखित नाही. आजही हीच सर्वसाधारण स्थिती आहे. May 2026 मधील एका preprint मध्ये 1,000 लोकप्रिय GitHub repositories चे सर्वेक्षण करण्यात आले. त्यापैकी केवळ 118 repositories मध्ये AI संदर्भातील कोणतेही लिखित धोरण आढळले. मौन म्हणजे परवानगी नाही. Patch लिहिण्यापूर्वी issue tracker मध्ये एका वाक्यात विचारणा करा. त्यामुळे मिळालेले उत्तर सार्वजनिक नोंद बनते आणि पुढे त्याचा संदर्भ देता येतो.

देखभालकर्त्यांनी हे नियम का लिहिले

पहिले कारण पुनरावलोकनाचा भार आहे आणि गणित एका दिशेनेच जाते. एखादा agent एका मिनिटात विश्वासार्ह वाटणारा 400 ओळींचा merge request तयार करतो. त्या विनंतीचे योग्य पुनरावलोकन करण्यासाठी देखभालकर्त्याला पूर्ण दुपार लागते आणि बहुतेक देखभालकर्ते स्वयंसेवक असतात. सबमिट करण्याची किंमत जवळपास शून्यावर आली. पुनरावलोकनाची किंमत मात्र अजिबात कमी झाली नाही.

curl त्या प्रवृत्तीचा टोकाचा परिणाम दाखवते. 2025 च्या मध्यात Daniel Stenberg यांनी सांगितले की प्रकल्पाच्या bug bounty द्वारे येणाऱ्या security reports पैकी साधारण एक-पंचमांश अहवाल हे त्यांच्या शब्दांत AI slop होते: त्यात खऱ्या functions आणि खऱ्या code paths ची नावे असतात, संभाव्य attack चे वर्णन असते आणि प्रत्यक्षात काहीही नसते. हा ओघ सुरू ठेवण्यासाठी निधी देण्याऐवजी प्रकल्पाने 2026 च्या सुरुवातीला bounty बंद केली. ते अहवाल होते, patches नव्हते; परंतु maintainer तुमचा PR उघडतानाच थकलेला का असतो, हे निर्माण करणारी यंत्रणा तीच आहे.

GNOME Calendar ने ही समस्या एका label द्वारे नोंदवली. June 2026 मध्ये प्रकल्पाने अशा merge requests साठी "Probabilistically Automated" हा label सुरू केला, ज्यामध्ये "major or total reliance on artificial 'intelligence' to generate code" दिसते. या लक्षणाचे अचूक वर्णनही केले: "usually accompanied by a lack of proper testing, and finalizing patches based on theoretical intended behavior rather than correctness of code". शेवटचा वाक्यांश दोनदा वाचा. Code कार्य करायला हवे असे दिसते. प्रत्यक्षात ते कार्य करते की नाही, हे कोणी तपासलेले नसते.

दुसरे कारण provenance आहे. म्हणजे code कुठून आले आणि कोणत्या license अंतर्गत आले. QEMU हा conflict स्पष्टपणे मांडते: sign-off केल्याने तुम्ही योगदान देत असलेल्या content ची "fully understand the copyright and license status" अशी हमी देता; परंतु model output ची copyright स्थिती अद्याप निश्चित नाही. Gentoo च्या council ने quality आणि ethics सोबत हेच कारण दिले. कायदेशीर अर्थ लावण्याशी तुमचे मत जुळणे आवश्यक नाही. परंतु निर्णय घेण्याचा अधिकार maintainer कडे आहे, तुमच्याकडे नाही, हे तुम्ही लक्षात घेतले पाहिजे.

प्रकल्पाचे AI धोरण कसे शोधावे?

खालील ठिकाणी, याच क्रमाने शोधा.

• प्रथम repository root मधील CONTRIBUTING.md, त्यानंतर .github/CONTRIBUTING.md आणि मग त्याच्या शेजारील कोणतीही DCO फाइल.
• Developer documentation. QEMU मध्ये हे नियम docs/devel/code-provenance.rst मध्ये आहेत. Kernel मध्ये ते Documentation/process/coding-assistants.rst मध्ये आहेत.
• Project website किंवा wiki. Gentoo चे धोरण council च्या wiki page वर आहे आणि NetBSD चे commit guidelines मध्ये आहे.
• Issue tracker आणि mailing list archive. Repository मध्ये लिहिण्यापूर्वी धोरण अनेक महिने या ठिकाणी उपलब्ध असते.

Checkout मधून खालील grep command बहुतांश ठिकाणी पुरेसा ठरतो:

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

त्यानंतर project चा स्वतःचा इतिहास वाचा, कारण त्यात commit केलेली पद्धत तिच्या कोणत्याही सारांशापेक्षा अधिक ग्राह्य असते:

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

Trailer value च्या शेजारील count या project मध्ये प्रत्यक्षात कोणता प्रकार वापरला जातो ते दर्शवतो. रिकामा result म्हणजे या project मध्ये त्या प्रकारे कोणीही disclosure केलेले नाही; ही देखील उपयुक्त माहिती आहे. Project GitHub वर असल्यास आणि workflow तुमच्यासाठी नवीन असल्यास, GitHub वर pull requests आणि forks कसे कार्य करतात या विभागात गृहीत धरलेली कार्यपद्धती समजावली आहे.

टिप्पणीमध्ये नव्हे, commit trailer मध्ये उघड करा

Trailer ही commit message च्या शेवटच्या paragraph मधील Key: value line असते. Git आधीपासून Signed-off-by: आणि Co-authored-by: साठी हा format वापरतो आणि tools तो parse करतात. त्यामुळे code tree मध्ये पोहोचणारी हीच disclosure असते.

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 या format चे दस्तऐवजीकरण Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] म्हणून करतो आणि line ची मर्यादा स्पष्टपणे सांगतो: "AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO)." Agent चे नाव Assisted-by वर जाते. तुमचे नाव Signed-off-by वर जाते. दुसरे नाव कोणत्याही tool ने लिहू देऊ नका. तसेच कोणाचेही नसलेला Co-authored-by address tool ने तयार करू देऊ नका.

नावे वेगवेगळी असतात. त्यामुळे स्वतःचे नाव तयार करण्याऐवजी स्थानिक पद्धतीतील नाव copy करा. May 2026 मध्ये QEMU list वर पोस्ट केलेल्या patch मध्ये mechanical changes, tests, docs आणि वीस lines किंवा त्यापेक्षा कमी bug fixes साठी त्या project मधील बंदी शिथिल करण्याचा प्रस्ताव मांडला होता. त्याची नोंद AI-used-for: tests, docs सारख्या trailer ने केली होती. August 2026 पर्यंत हा mailing list वरील प्रस्ताव आहे आणि committed document अद्याप generated content नाकारतो. एका project ने 2023 ते 2026 दरम्यान आपली भूमिका दोनदा बदलली. पुढील बदल तुमची वाट पाहणार नाही. म्हणून list पेक्षा पद्धत अधिक महत्त्वाची आहे.

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 किंवा त्यानंतरची आवृत्ती आवश्यक आहे. दुसऱ्या command ने value थेट पुन्हा दाखवली पाहिजे. रिकामी line दिसल्यास git ने trailer parse केलेला नाही. हे जवळजवळ नेहमी message च्या तळातील trailer block मध्ये blank line किंवा साधे sentence असल्यामुळे होते. आधीच लिहिलेल्या commit मालिकेसाठी git rebase --signoff origin/main प्रत्येक commit मध्ये sign-off जोडते आणि git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt message file संपादित करते.

दोन अपयशाच्या प्रकारांसाठी आधीच तयारी ठेवा. Squash merge commit message पुन्हा लिहिते. त्यामुळे squash करणाऱ्या project मध्ये maintainer जिथे वाचतो त्या PR description मध्ये disclosure पुन्हा द्या. Review comment हा record नाही, कारण comments संपादित करता येतात आणि ते git history मध्ये कधीही येत नाहीत.

अचूकता दोन्ही बाजूंनी महत्त्वाची आहे. स्वतः हाताने टाइप केलेल्या commit वर Assisted-by लावणे अनावश्यक noise आहे. त्यामुळे तुमच्या खऱ्या disclosures चे महत्त्व कमी होते. Agent ने लिहिलेल्या commit वर ते न लावणे म्हणजे संबंध समाप्त होण्याचे कारण ठरते.

Signed-off-by नेमके कशाची साक्ष देते?

DCO हा version 1.1 मधील एक छोटा मजकूर आहे. तो developercertificate.org येथे प्रकाशित केला आहे. Kernel, QEMU आणि इतर अनेक प्रकल्प त्याचा वापर करतात. Signed-off-by: Your Name <you@example.com> जोडणे म्हणजे तुम्ही त्या मजकुरातील बाबींची खात्री देता. तुम्ही नेमकी कशाची खात्री देत आहात ते वाचा, कारण बहुतेक लोक तो मजकूर कधीही न वाचता sign करतात.

Clause (a) नुसार योगदानाचा संपूर्ण किंवा काही भाग "माझ्याकडून तयार केला आहे आणि file मध्ये नमूद केलेल्या open source license अंतर्गत ते सादर करण्याचा मला अधिकार आहे". Clause (b) मध्ये आधीच्या open source code वर आधारित कामाचा समावेश होतो, जर त्यात बदल करून ते पुढे देण्याचा तुम्हाला अधिकार असेल. Clause (c) मध्ये अशा व्यक्तीने तुम्हाला दिलेल्या code चा समावेश होतो, जिने याच बाबींची खात्री दिली आहे. Clause (d) नुसार योगदान आणि तुमच्या sign-off मधील वैयक्तिक माहिती सार्वजनिक असेल आणि अनिश्चित काळासाठी जतन केली जाईल, याची तुम्हाला जाणीव आहे.

यात कोणती बाब नमूद केलेली नाही ते लक्षात घ्या. DCO मध्ये तुम्ही प्रत्येक अक्षर स्वतः टाइप केलेले असावे, असे कधीही म्हटलेले नाही. त्यात तुम्हाला हा code या license अंतर्गत सादर करण्याचा अधिकार आहे, असे म्हटले आहे. म्हणून generated code या प्रक्रियेत संदिग्ध ठरतो: प्रश्न authorship चा नाही; code च्या उगमाची जबाबदारी तुम्ही स्पष्ट करू शकता का, हा प्रश्न आहे. Sign-off आवश्यक असलेले बहुतेक प्रकल्प खरे नावही आवश्यक करतात. त्यामुळे pseudonym ही तपासणी पूर्ण करू शकत नाही. git commit -s असलेली line जोडा. ती user.name आणि user.email तुमच्या git config मधून घेते. DCO bot तुमचा PR नाकारून ज्या commit मध्ये ही line नाही त्याचे नाव दाखवतो, तेव्हा git rebase --signoff origin/main करा आणि तुमच्या branch वर force push केल्याने ही समस्या सुटते.

कमिटवर स्वाक्षरी करणे आणि sign-off करणे एकसारखे नाही

git commit -s मजकुराची एक ओळ जोडते. git commit -S तुमची GPG किंवा SSH key वापरून commit object वर cryptographic signature तयार करते. हे दोन्ही वेगवेगळ्या प्रश्नांची उत्तरे देतात. ही signature सांगते की हा commit त्या key च्या धारकाकडून आला आहे आणि त्यानंतर त्यात बदल केलेला नाही. मात्र, त्यातील code कुठून आला याबद्दल ती काहीही सांगत नाही. त्यामुळे उघड न केलेल्या generated code ने भरलेला signed commit स्वाक्षरी केलेला असला तरी policy चे उल्लंघन ठरू शकतो. sign-off हा code च्या origin बद्दलचा दावा आहे. signature ही ओळख पटवणारा दावा आहे. दोन्ही आवश्यक असलेल्या projects मध्ये दोन्ही मागितले जातात.

परीक्षणात स्पष्ट करता येणार नाही असा code कधीही submit करू नका

हीच चाचणी आहे; आणि ती प्रत्यक्षात प्रामाणिकपणाबद्दल नाही. प्रत्येक line साठी विचारा: याचा उपयोग काय आहे आणि हे नसल्यास काय बिघडते? यापैकी एकही उत्तर नसल्यास patch तयार नाही. कारण review comment येणारच आहे आणि तुमचे उत्तर पुन्हा generation च्या एका फेरीत जाईल. Reviewers हे ओळखू शकतात. त्या क्षणी contributor प्रकल्पासाठी खर्चाचे कारण बनतो. Edges, रिक्त input, failure path आणि दुसरा caller यांच्याबद्दलही हाच प्रश्न विचारा.

तो code चालवून पाहा. तो build करा, प्रकल्पाचा test suite चालवा आणि तुम्ही दुरुस्त केल्याचा दावा करत असलेल्या bug साठी reproducer लिहा. Kernel documentation मध्ये स्पष्ट शब्दांत योग्य fallback दिला आहे: "जर fix build किंवा test करता आला नाही किंवा reproducer तयार करता आला नाही, तर ते स्पष्टपणे सांगा: maintainers सध्या पडताळणी न केलेले reports आणि test न केलेले fixes तपासण्यात खूप वेळ वाया घालवत आहेत." "I could not test this on real hardware" असे लिहिल्याने तुमचे काहीही नुकसान होत नाही. तुम्ही ते केले असा अप्रत्यक्ष दावा केल्यास प्रकल्पाचे नुकसान होते.

Review commentsना तुमच्या स्वतःच्या शब्दांत आणि तुमच्या वेळेनुसार स्वतः उत्तर द्या. Comment आल्यानंतर तीस सेकंदांनी आलेले उत्तर आणि तोच मुद्दा पाच परिच्छेदांत पुन्हा मांडणे, यामुळे नेमके काय घडले हे maintainerला स्पष्ट कळते. Diff देखील लहान ठेवा. तुम्हाला पूर्णपणे समजलेल्या चाळीस lines या तुम्ही देखरेख केलेल्या चारशे linesच्या refactorपेक्षा प्रकल्पासाठी अधिक उपयुक्त असतात. तुमच्या मागणीपेक्षा agent वारंवार अधिक code देत असेल, तर काम करणारा सर्वात लहान बदलच स्वीकारण्यास भाग पाडणारे skill patch इतकाच मर्यादित ठेवण्याचा एक मार्ग आहे की तुम्ही अजूनही प्रत्येक lineचे समर्थन करू शकाल.

रेपॉझिटरीमध्ये agent च्या सूचना ठेवा

तुम्ही agent ला देता त्या सूचना तुमच्या toolchain चा भाग असतात. त्यामुळे त्यांना code प्रमाणे हाताळा. रेपॉझिटरीच्या root मध्ये असलेली फाइल, साधारणपणे AGENTS.md, build command, test command, commit message format, sign-off requirement आणि प्रकल्पात आधीपासून दस्तऐवजीकरण केलेले style rules ठेवते. या फाइलची versioning आणि review करता येते. आज ज्या सूचना आहेत त्याच उद्याही राहतात. प्रत्येक session मध्ये memory मधून पुन्हा टाइप केलेल्या सूचनांमुळे प्रत्येक session मध्ये वेगळा patch तयार होतो. कोणत्या session मध्ये reject झालेला patch तयार झाला हे तुम्हाला कळणार नाही. agent आणि मानव दोघांनाही वाचता येईल अशी AGENTS.md लिहिणे या फाइलबद्दल माहिती देते.

इतरांच्या रेपॉझिटरींबाबत एक सावधगिरी. तुम्ही maintain करत नसलेल्या प्रकल्पात agent instruction file जोडणारा PR तुमचे पहिले contribution म्हणून पाठवू नका. यामुळे तुम्ही बाहेरून प्रकल्पाचे tooling policy ठरवण्याचा प्रयत्न करत आहात असे दिसते. तसेच maintainers आधीच कंटाळलेल्या गोष्टीशी तुमचे account जोडले जाण्याचा हा जलद मार्ग आहे. कोणी मागणी करेपर्यंत ही फाइल तुमच्या fork मध्ये ठेवा.

तुम्ही agent कुठे चालवता हेही याच कारणामुळे महत्त्वाचे आहे. तुमच्या नियंत्रणाखालील sandbox मध्ये प्रकल्प build करून त्याच्या tests चालवता येणारा agent तुम्हाला प्रत्यक्ष पडताळलेला patch देतो. Assistance उघड करणे आणि केवळ अंदाज उघड करणे यातील फरक हाच आहे. तुमच्या स्वतःच्या VPS वर coding agent चालवणे या setup बद्दल माहिती देते. Claude Code, Cursor, Codex आणि Copilot यांमधील व्यावहारिक फरक ही tools दिवसेंदिवस कशी वेगळी असतात ते स्पष्ट करते.

पद्धत, धोरण बदलल्यानंतर

1. काहीही लिहिण्यापूर्वी नमूद केलेले धोरण शोधा: repository, developer docs, website, tracker.
2. धोरण उपलब्ध नसेल, तर issue मध्ये एका वाक्यात विचारणा करा आणि उत्तर जतन करा.
3. प्रकल्पाने वापरलेल्या स्वरूपात, commit trailer मध्ये माहिती जाहीर करा आणि प्रकल्प squash करत असल्यास ती PR body मध्येही पुन्हा नमूद करा.
4. तुमच्या खऱ्या नावाने sign off करा. त्या ओळीमधून कोड सादर करण्याचा तुमचा अधिकार असल्याचा दावा केला जातो, हे लक्षात ठेवा.
5. तुमचा patch एखाद्या अनोळखी व्यक्तीने लिहिल्याप्रमाणे स्वतः तपासा, कारण तो खरोखरच अनोळखी व्यक्तीने लिहिलेला आहे.

तुम्ही हे वाचाल तोपर्यंत या पृष्ठावर नमूद केलेला प्रत्येक प्रकल्प बदललेला असेल. ही पाच पावले मात्र बदलणार नाहीत.

FAQ

मी AI coding agent वापरल्याचे जाहीर करणे आवश्यक आहे का?

प्रकल्पाची माहिती तपासा, कारण याचे उत्तर प्रकल्पानुसार ठरते. योगदानाचा महत्त्वपूर्ण भाग कोणत्याही बदलांशिवाय एखाद्या साधनातून आला असल्यास Fedora जाहीर करणे आवश्यक करते. Linux kernel मध्ये Assisted-by trailer आवश्यक आहे. August 2026 पर्यंत Gentoo आणि QEMU यांना असे योगदान अजिबात नको आहे. काहीही लिखित स्वरूपात दिलेले नसले तरी commit trailer मध्ये ते जाहीर करा. Maintainer ला नंतर याची माहिती मिळाल्यास त्याची प्रतिक्रिया त्या साधनावर नव्हे, तर माहिती न दिल्याच्या कृतीवर असते. त्या प्रतिक्रियेचा परिणाम तुम्ही पाठवलेल्या इतर सर्व गोष्टींवरही होतो.

कोणते open source प्रकल्प AI-generated code वर बंदी घालतात?

August 2026 मधील स्थितीनुसार: April 2024 पासून Gentoo, LLM च्या output ला core approval आवश्यक असलेला tainted code मानणारे NetBSD, generated content मधून तयार केलेले योगदान नाकारणारे QEMU, तसेच Loupe आणि Calendar यांसह अनेक GNOME applications. या यादीऐवजी प्रत्येक प्रकल्पाचा स्वतःचा मजकूर वाचा, कारण ही माहिती कालबाह्य होऊ शकते. यांपैकी बहुतेक प्रकल्पांमध्ये एक समान सूट आहे: API चा अभ्यास करण्यासाठी, static analysis चालवण्यासाठी किंवा debugging मध्ये मदत घेण्यासाठी model वापरणे सामान्यतः स्वीकार्य असते, मात्र त्याचे output patch मध्ये नसावे.

Signed-off-by आणि signed commit यांमध्ये काय फरक आहे?

Signed-off-by ही git commit -s ने जोडलेली साधी text line आहे. ती developer certificate of origin प्रमाणित करते. म्हणजेच, प्रकल्पाच्या license अंतर्गत हा code सादर करण्याचा अधिकार तुमच्याकडे आहे. git commit -S वापरून केलेला signed commit हा तुमच्या GPG किंवा SSH key ने commit object वर केलेला cryptographic signature असतो. त्यामुळे commit तुमच्या key कडून आला आहे आणि त्यात बदल केलेला नाही, हे सिद्ध होते. Origin आणि identity हे स्वतंत्र दावे आहेत. त्यामुळे signed commit तरीही AI policy चे उल्लंघन करू शकतो.

Commit message ऐवजी disclosure pull request description मध्ये ठेवू शकतो का?

ते commit message मध्ये ठेवा, कारण git history मध्ये समाविष्ट होणारी आणि नंतर repository clone करणाऱ्या प्रत्येक व्यक्तीसोबत code सोबत जाणारी नोंद तीच असते. Pull request description नंतर edit करता येते आणि ती hosting platform वर राहते. प्रकल्प squash merge करत असल्यास ते PR body मध्येही जोडा, कारण squash मुळे तुमचा commit message पुन्हा लिहिला जातो आणि trailer गाळला जाऊ शकतो.

माझे pull request AI-generated असल्यामुळे बंद करण्यात आले. आता काय करावे?

Thread मध्ये policy वर वाद घालू नका, कारण ते नियम बंद करणाऱ्या व्यक्तीने एकट्याने लिहिलेले नसतात आणि बदल करण्याचे ठिकाण thread नसते. Policy चा मजकूर वाचा आणि मग ती पूर्ण करणे तुम्हाला शक्य आहे का ते ठरवा. प्रकल्प generated patches वर बंदी घालत असल्यास reproducer असलेला आणि patch नसलेला स्पष्ट bug report तरीही स्वीकारला जातो. अनेकदा तेच अधिक उपयुक्त योगदान ठरते. पुन्हा code सादर करताना, प्रत्येक ओळ स्पष्टपणे समजावून सांगता येईल असा लहान बदल सादर करा.