ஆல் Open source திட்டங்களில் AI code பங்களிப்பு விதிகள்
Open source திட்டங்களில் AI-உதவியுடன் உருவாக்கப்பட்ட குறியீட்டை சமர்ப்பிக்கும் முன் கவனிக்க வேண்டிய கொள்கைகள் மற்றும் commit trailer-ல் வெளிப்படையாகத் தெரிவிக்கும் முறைகள்.
AI-உதவியுடன் உருவாக்கப்பட்ட குறியீட்டை (code) upstream-க்கு அனுப்பும் முன் செய்ய வேண்டியவை
திறந்தநிலை மென்பொருள் (open source) திட்டங்கள் இப்போது AI-உதவியுடன் உருவாக்கப்பட்ட குறியீடு குறித்த கொள்கைகளை வெளியிட்டு வருகின்றன. இக்கொள்கைகள் ஒவ்வொன்றும் மாறுபடுகின்றன. எனவே, ஒரு எளிய பழக்கத்தைப் பின்பற்றுங்கள்: patch-ஐ எழுதும் முன்பே அத்திட்டத்தின் கொள்கையைக் கண்டறியவும், அதை அனுப்பும்போது வெளிப்படையாகத் தெரிவிக்கவும். இவை இரண்டிற்கும் பொதுவான ஒரு விதி உள்ளது: மதிப்பாய்வின்போது (review) உங்களால் விளக்க முடியாத எந்தவொரு வரியையும் சமர்ப்பிக்காதீர்கள்.
ஒரு திட்டம் தானியங்கி முறையில் உருவாக்கப்பட்ட குறியீட்டைத் தடை செய்திருந்தாலோ, அல்லது அக்குறியீடு எங்கிருந்து வந்தது என்பதை நீங்கள் மறைத்திருந்தாலோ, சரியான patch-ஆக இருந்தாலும் அது நிராகரிக்கப்படும். இதன் விளைவு உங்கள் பெயரையே பாதிக்கும். ஏனெனில், நீங்கள் தகவலை மறைத்ததை ஒரு பராமரிப்பாளர் (maintainer) பிற்காலத்தில் கண்டறிந்தால், உங்கள் முந்தைய பங்களிப்புகள் மீதான நம்பிக்கையை அவர் இழந்துவிடுவார். கொள்கைகளில் பயன்படுத்தப்படும் சில சொற்களை முதலில் புரிந்துகொள்வோம். LLM (large language model) என்பது உங்கள் coding agent-க்கு பின்னால் உள்ள மாதிரி ஆகும். GitHub-ல் உள்ள PR (pull request) என்பது GitLab-ல் MR (merge request) ஆகும்; கீழே உள்ள அனைத்தும் இவை இரண்டிற்கும் பொருந்தும். DCO (developer certificate of origin) என்பது commit message-ன் இறுதியில் உள்ள sign-off வரியாகும்; இதுவே இந்த விவாதத்தின் மையப்புள்ளியாக உள்ளது.
AI code தொடர்பான open source கொள்கைகள் எங்கு நிலைபெற்றுள்ளன
Projects நான்கு பிரிவுகளாகப் பிரிந்துள்ளன. கீழே உள்ள ஒவ்வொரு உதாரணமும் ஒரு குறிப்பிட்ட தேதியைக் கொண்டது, ஏனெனில் இந்த விதிகள் தொடர்ந்து மாறிக்கொண்டே இருக்கின்றன.
தடை செய்யப்பட்டது. Gentoo-வின் council, 14 April 2024 அன்று "Natural Language Processing artificial intelligence கருவிகளின் உதவியுடன் உருவாக்கப்பட்ட எந்தவொரு உள்ளடக்கத்தையும் Gentoo-வில் பங்களிப்பது வெளிப்படையாகத் தடைசெய்யப்பட்டுள்ளது" என்று வாக்களித்தது. NetBSD-யின் commit வழிகாட்டுதல்கள், LLM-லிருந்து வரும் வெளியீட்டை "tainted code" (மாசுபட்ட குறியீடு) என்று அழைப்பதோடு, "core குழுவின் முன் அனுமதியின்றி அதை commit செய்யக்கூடாது" என்றும் கூறுகிறது. QEMU-வின் code provenance ஆவணம், August 2026 நிலவரப்படி, "AI மூலம் உருவாக்கப்பட்ட உள்ளடக்கம் என்று கருதப்படும் அல்லது அதிலிருந்து பெறப்பட்ட எந்தவொரு பங்களிப்பையும் நிராகரிக்கும்" என்று இன்னும் கூறுகிறது.
ஆய்வுக்காக மட்டும். பெரும்பாலான தடைகள் தலைப்புச் செய்திகளில் இருப்பதை விடக் குறுகியவை. QEMU-வின் ஆவணம், "இந்தக் கொள்கை AI-ன் பிற பயன்பாடுகளுக்குப் பொருந்தாது, உதாரணமாக API-கள் அல்லது algorithms-ஐ ஆய்வு செய்தல், static analysis, அல்லது debugging போன்றவற்றுக்கு இதைப் பயன்படுத்தலாம், ஆனால் அவற்றின் வெளியீடு பங்களிப்புகளில் சேர்க்கப்படக்கூடாது" என்று கூறுகிறது. நீங்கள் code-ஐப் படிக்க AI agent-ஐப் பயன்படுத்தலாம். ஆனால் அது எழுதியதை நீங்கள் ship செய்யக்கூடாது. இந்த வேறுபாடே பெரும்பாலான கட்டுப்பாடுகள் கொண்ட projects-ல் உள்ள நடைமுறை விதியாகும், இதைத்தான் பலர் கவனிக்கத் தவறிவிடுகிறார்கள்.
வெளிப்படுத்தல் கட்டாயம். Fedora-வின் council, October 2025-ல் AI-உதவி பெற்ற பங்களிப்புகள் குறித்த கொள்கைக்கு ஒப்புதல் அளித்தது. இது கருவிகளைப் பயன்படுத்த அனுமதிக்கிறது, ஆனால் பொறுப்பை அந்த நபரின் மீது சுமத்துகிறது: பங்களிப்பாளர் தான் ஆசிரியர், முழு பங்களிப்பிற்கும் அவரே முழுப் பொறுப்பு, மேலும் ஒரு குறிப்பிடத்தக்க பகுதி மாற்றங்கள் இன்றி கருவி மூலம் பெறப்பட்டிருந்தால் அதை அவர் வெளிப்படுத்த வேண்டும். Linux kernel, December 2025-ல் அதன் process ஆவணத்தில் coding assistants பக்கத்தைச் சேர்த்தது. அதில் கருவியைப் பதிவு செய்வதற்கான ஒரு பகுதியும், யார் sign off செய்யலாம் என்பது குறித்த கடுமையான விதியும் உள்ளன.
எழுதப்பட்ட விதிகள் இல்லை. இதுவே இப்போதும் பொதுவான நிலையாக உள்ளது. May 2026-ல் வெளியான ஒரு preprint, 1,000 பிரபலமான GitHub repositories-ஐ ஆய்வு செய்து, அதில் 118-ல் மட்டுமே எழுதப்பட்ட AI கொள்கை இருப்பதைக் கண்டறிந்தது. மௌனம் என்பது அனுமதியல்ல. patch-ஐ எழுதுவதற்கு முன், issue tracker-ல் ஒரே வரியில் கேளுங்கள்; அதன் பதில் ஒரு பொதுவான பதிவாக மாறிவிடும், அதை நீங்கள் பிற்காலத்தில் ஆதாரமாகக் காட்டலாம்.
பராமரிப்பாளர்கள் ஏன் இந்த விதிகளை எழுதினார்கள்
முதல் காரணம் ஆய்வுச் சுமை (review load), இதன் கணக்கீடு ஒரு திசையில் மட்டுமே செல்கிறது. ஒரு AI agent ஒரு நிமிடத்தில் 400 வரிகள் கொண்ட நம்பத்தகுந்த merge request-ஐ உருவாக்குகிறது. அந்த request-ஐ முறையாக ஆய்வு செய்ய ஒரு பராமரிப்பாளருக்கு ஒரு மதிய நேரம் தேவைப்படுகிறது, மேலும் பெரும்பாலான பராமரிப்பாளர்கள் தன்னார்வலர்கள். சமர்ப்பிப்பதற்கான செலவு பூஜ்ஜியத்திற்கு அருகில் குறைந்துவிட்டது. ஆனால் ஆய்வு செய்வதற்கான செலவு சிறிதும் குறையவில்லை.
curl இந்த வளைவின் இறுதி நிலையை காட்டுகிறது. 2025-ன் மத்தியில் Daniel Stenberg குறிப்பிட்டபடி, திட்டத்தின் bug bounty மூலம் வந்த பாதுகாப்பு அறிக்கைகளில் ஐந்தில் ஒரு பங்கு அவர் "AI slop" என்று அழைப்பவை ஆகும்: இவை உண்மையான functions மற்றும் code paths-களைக் குறிப்பிடுகின்றன, நம்பத்தகுந்த தாக்குதலை விவரிக்கின்றன, ஆனால் உள்ளடக்கத்தில் எதுவுமே இல்லை. அந்த வெள்ளத்திற்கு நிதி வழங்குவதை விட, 2026-ன் தொடக்கத்தில் அந்தத் திட்டமே bounty-ஐ முடித்துக்கொண்டது. அவை patches அல்ல, அறிக்கைகள் மட்டுமே; ஆனால் அதே நுட்பம்தான் ஒரு பராமரிப்பாளர் உங்கள் PR-ஐத் திறக்கும்போதே சோர்வாக இருக்கக் காரணமாகிறது.
GNOME Calendar இந்தச் சிக்கலை ஒரு label-ஆகக் குறிப்பிட்டது. ஜூன் 2026-ல், "குறியீட்டை உருவாக்க செயற்கை 'அறிவுத்திறனை' பெருமளவில் அல்லது முழுமையாகச் சார்ந்திருக்கும்" merge request-களுக்காக "Probabilistically Automated" என்ற label-ஐ அறிமுகப்படுத்தியது. அதன் அறிகுறியை மிகத் துல்லியமாகப் பெயரிட்டது: "பொதுவாக முறையான சோதனைகள் இல்லாமை மற்றும் குறியீட்டின் சரியான தன்மையை விட, கோட்பாட்டு ரீதியான நோக்கம் கொண்ட செயல்பாட்டின் அடிப்படையில் patches-ஐ முடித்தல்". அந்த கடைசி வாக்கியத்தை இருமுறை வாசிக்கவும். குறியீடு வேலை செய்வது போலத் தோன்றும். ஆனால் அது உண்மையில் வேலை செய்கிறதா என்று யாரும் சரிபார்க்கவில்லை.
இரண்டாவது காரணம் provenance, அதாவது குறியீடு எங்கிருந்து வந்தது மற்றும் எந்த உரிமத்தின் (license) கீழ் உள்ளது என்பது. QEMU இந்த முரண்பாட்டைத் தெளிவாகக் கூறுகிறது: நீங்கள் சமர்ப்பிக்கும் உள்ளடக்கத்தின் "பதிப்புரிமை மற்றும் உரிம நிலையை நீங்கள் முழுமையாகப் புரிந்துகொண்டுள்ளீர்கள்" என்பதை உறுதிப்படுத்துவதே signing off ஆகும், மேலும் model output-ன் பதிப்புரிமை நிலை இன்னும் தீர்க்கப்படவில்லை. Gentoo-வின் council தரம் மற்றும் அறநெறியுடன் சேர்த்து அதே காரணத்தைக் கூறியது. நீங்கள் இந்த சட்ட விளக்கத்தை ஏற்க வேண்டிய அவசியமில்லை. ஆனால் இது பராமரிப்பாளரின் முடிவு, உங்களுடையது அல்ல என்பதை நீங்கள் கவனிக்க வேண்டும்.
ஒரு திட்டத்தின் AI கொள்கையை எவ்வாறு கண்டறிவது?
இந்த இடங்களில், இந்த வரிசையில் தேடவும்.
- களஞ்சியத்தின் (repository) முதன்மைப் பகுதியில்
CONTRIBUTING.md, பிறகு.github/CONTRIBUTING.md, அதன் அருகில் ஏதேனும்DCOகோப்பு இருந்தால் அதையும் பார்க்கவும். - டெவலப்பர் ஆவணங்கள். QEMU தனது விதியை
docs/devel/code-provenance.rst-ல் வைத்துள்ளது. கர்னல் தனது விதியைDocumentation/process/coding-assistants.rst-ல் வைத்துள்ளது. - திட்டத்தின் இணையதளம் அல்லது விக்கி. Gentoo-வின் கொள்கை கவுன்சிலின் விக்கி பக்கத்திலும், NetBSD-யின் கொள்கை கமிட் வழிகாட்டுதல்களிலும் உள்ளன.
- சிக்கல் கண்காணிப்பு (issue tracker) மற்றும் மின்னஞ்சல் பட்டியல் காப்பகம். ஒரு கொள்கை களஞ்சியத்தில் எழுதப்படுவதற்கு பல மாதங்களுக்கு முன்பே அங்கு விவாதிக்கப்பட்டிருக்கும்.
ஒரு checkout-க்குள் இருந்து, இந்த ஒரு 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-ல் இருந்து, அதன் பணிப்பாய்வு உங்களுக்குப் புதியதாக இருந்தால், GitHub-ல் pull requests மற்றும் forks எவ்வாறு செயல்படுகின்றன என்பது இந்தப் பகுதியில் கருதப்படும் நுட்பங்களை விளக்குகிறது.
Commit trailer-ல் வெளிப்படுத்துங்கள், comment-ல் அல்ல
Trailer என்பது commit message-ன் கடைசி பத்தியில் உள்ள ஒரு Key: value வரியாகும். Git ஏற்கனவே Signed-off-by: மற்றும் Co-authored-by:-க்கு இந்த அமைப்பையே பயன்படுத்துகிறது, மேலும் கருவிகள் இதை 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] என்று ஆவணப்படுத்துகிறது, மேலும் வரியின் வரம்பு குறித்து அது தெளிவாக உள்ளது: "AI முகவர்கள் Signed-off-by tags-ஐச் சேர்க்கக்கூடாது. மனிதர்கள் மட்டுமே சட்டப்பூர்வமாக Developer Certificate of Origin (DCO)-ஐச் சான்றளிக்க முடியும்." முகவரின் பெயர் Assisted-by-ல் இடம்பெற வேண்டும். உங்கள் பெயர் Signed-off-by-ல் இடம்பெற வேண்டும். ஒரு கருவியை இரண்டாவது பெயரை எழுத அனுமதிக்காதீர்கள், மேலும் யாருக்கும் சொந்தமில்லாத Co-authored-by முகவரியை உருவாக்கவும் அனுமதிக்காதீர்கள்.
பெயர்கள் மாறுபடும் என்பதால், நீங்களாக உருவாக்குவதற்குப் பதிலாக உள்ளூர் பெயரை நகலெடுக்கவும். மே 2026-ல் QEMU பட்டியலில் பதிவேற்றப்பட்ட ஒரு patch, இயந்திரத்தனமான மாற்றங்கள், சோதனைகள், ஆவணங்கள் மற்றும் இருபது வரிகளுக்குக் குறைவான bug fixes ஆகியவற்றிற்கு அந்தத் திட்டத்தின் தடையைத் தளர்த்த முன்மொழிந்தது, இது AI-used-for: tests, docs போன்ற ஒரு trailer-உடன் பதிவு செய்யப்பட்டது. ஆகஸ்ட் 2026 நிலவரப்படி, அது ஒரு mailing list-ல் உள்ள முன்மொழிவு மட்டுமே, மேலும் committed ஆவணம் இன்னும் உருவாக்கப்பட்ட உள்ளடக்கத்தை ஏற்கவில்லை. ஒரு திட்டம் 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 அல்லது புதிய பதிப்பு தேவை. இரண்டாவது கட்டளை மதிப்பை உங்களுக்கு அப்படியே திருப்பித் தர வேண்டும். காலியான வரி என்பது git அந்த trailer-ஐ parse செய்யவில்லை என்று பொருள், இதற்கு முக்கிய காரணம் message-ன் இறுதியில் உள்ள trailer block-க்குள் ஒரு வெற்று வரி அல்லது சாதாரண வாக்கியம் இருப்பதுதான். நீங்கள் ஏற்கனவே எழுதிய தொடருக்கு, 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 செய்யும் ஒரு திட்டத்தில், maintainer படிக்கும் PR description-ல் வெளிப்படுத்தலை மீண்டும் குறிப்பிடவும். மேலும், review comment என்பது ஒரு பதிவு அல்ல, ஏனெனில் comments-ஐத் திருத்த முடியும் மற்றும் அவை ஒருபோதும் git வரலாற்றில் சேராது.
துல்லியம் இருபுறமும் பொருந்தும். நீங்கள் கையால் தட்டச்சு செய்த commit-ல் Assisted-by இருப்பது தேவையற்றது, இது உங்கள் உண்மையான வெளிப்படுத்தல்களின் மதிப்பைக் குறைக்கும். முகவர் எழுதிய commit-ல் அதைச் சேர்க்காமல் விடுவதுதான் உறவை முடிவுக்குக் கொண்டுவரும் செயலாகும்.
Signed-off-by உண்மையில் எதை உறுதிப்படுத்துகிறது?
DCO என்பது ஒரு சிறிய உரை, பதிப்பு 1.1, இது developercertificate.org-ல் வெளியிடப்பட்டுள்ளது. இதை Linux kernel, QEMU மற்றும் பல திட்டங்கள் பயன்படுத்துகின்றன. Signed-off-by: Your Name <you@example.com>-ஐச் சேர்ப்பதன் மூலம், நீங்கள் அதைச் சான்றளிக்கிறீர்கள் என்று பொருள். நீங்கள் எதைச் சான்றளிக்கிறீர்கள் என்பதைப் படியுங்கள், ஏனெனில் பெரும்பாலானோர் அதைப் படிக்காமலேயே கையொப்பமிடுகிறார்கள்.
பிரிவு (a), நீங்கள் பங்களிக்கும் குறியீடு "முழுமையாகவோ அல்லது பகுதியாகவோ என்னால் உருவாக்கப்பட்டது மற்றும் கோப்பில் குறிப்பிடப்பட்டுள்ள open source உரிமத்தின் கீழ் அதைச் சமர்ப்பிக்க எனக்கு உரிமை உண்டு" என்று கூறுகிறது. பிரிவு (b), நீங்கள் மாற்றங்களுடன் பகிர உரிமை உள்ள முந்தைய open source குறியீட்டை அடிப்படையாகக் கொண்ட பணிகளை உள்ளடக்கியது. பிரிவு (c), அதே விஷயத்தைச் சான்றளித்த ஒருவரிடமிருந்து உங்களுக்குக் கிடைத்த குறியீட்டை உள்ளடக்கியது. பிரிவு (d), பங்களிப்பு மற்றும் உங்கள் sign-off-ல் உள்ள தனிப்பட்ட தகவல்கள் பொதுவானவை மற்றும் காலவரையின்றி பாதுகாக்கப்படும் என்பதை நீங்கள் புரிந்துகொள்கிறீர்கள் என்று கூறுகிறது.
இதில் விடுபட்டவற்றைக் கவனியுங்கள். நீங்கள் ஒவ்வொரு எழுத்தையும் நீங்களே தட்டச்சு செய்தீர்கள் என்று DCO ஒருபோதும் கூறவில்லை. இந்த உரிமத்தின் கீழ் குறியீட்டைச் சமர்ப்பிக்க உங்களுக்கு உரிமை உண்டு என்றுதான் அது கூறுகிறது. இதனால்தான் உருவாக்கப்பட்ட குறியீடு (generated code) இதில் சிக்கலை ஏற்படுத்துகிறது: கேள்வி படைப்பாற்றலைப் பற்றியது அல்ல, அதன் தோற்றத்திற்கு நீங்கள் பொறுப்பேற்க முடியுமா என்பதுதான். 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-ஐ உருவாக்குகிறது. இவை இரண்டு வெவ்வேறு கேள்விகளுக்குப் பதிலளிக்கின்றன. ஒரு commit அந்த key-ஐ வைத்திருப்பவரிடமிருந்துதான் வந்தது என்பதையும், அது மாற்றப்படவில்லை என்பதையும் அந்த signature உறுதிப்படுத்துகிறது. ஆனால், அந்த code எங்கிருந்து வந்தது என்பது பற்றி அது எதையும் கூறவில்லை; எனவே, வெளிப்படுத்தப்படாத generated code-ஐக் கொண்ட ஒரு signed commit, policy மீறலாகவே கருதப்படும். Sign-off என்பது மூலத்தைப் (origin) பற்றியது. Signature என்பது அடையாளத்தைப் (identity) பற்றியது. இரண்டையும் எதிர்பார்க்கும் திட்டங்கள், இரண்டையுமே சமர்ப்பிக்கக் கோரும்.
விளக்க முடியாத குறியீட்டை ஒருபோதும் சமர்ப்பிக்க வேண்டாம்
இது ஒரு சோதனை, இது நேர்மை பற்றியது மட்டுமல்ல. ஒவ்வொரு வரியையும் கவனியுங்கள்: இது எதற்காக, இதை நீக்கினால் என்ன பாதிப்பு ஏற்படும்? இந்த இரண்டு கேள்விகளில் ஒன்றுக்கு பதில் தெரியவில்லை என்றாலும், அந்த patch தயாராக இல்லை என்று அர்த்தம். ஏனெனில், review-வின் போது இந்த கேள்வி நிச்சயம் கேட்கப்படும், அப்போது நீங்கள் மீண்டும் விளக்கம் அளிக்க வேண்டியிருக்கும். Review செய்பவர்களால் இதை எளிதில் கண்டறிய முடியும். அந்த தருணத்தில் தான் ஒரு பங்களிப்பாளர் (contributor) திட்டத்திற்கு சுமையாக மாறுகிறார். விளிம்புநிலைச் சூழல்கள் (edges), காலியான உள்ளீடு (empty input), தோல்விப் பாதை (failure path), மற்றும் இரண்டாவது அழைப்பாளர் (second caller) ஆகியவற்றிடமும் இதே கேள்வியைக் கேளுங்கள்.
அந்தக் குறியீட்டை இயக்கிப் பாருங்கள். அதை build செய்து, திட்டத்தின் test suite-ஐ இயக்கி, நீங்கள் சரிசெய்யும் பிழைக்கான ஒரு reproducer-ஐ உருவாக்குங்கள். Kernel ஆவணங்கள் இதற்கான நேர்மையான வழியைத் தெளிவாகக் கூறுகின்றன: "ஒரு திருத்தத்தை build செய்யவோ அல்லது சோதிக்கவோ முடியவில்லை என்றாலோ, அல்லது reproducer-ஐ உருவாக்க முடியவில்லை என்றாலோ, அதை வெளிப்படையாகக் கூறுங்கள்: சரிபார்க்கப்படாத அறிக்கைகள் மற்றும் சோதிக்கப்படாத திருத்தங்களை ஆய்வு செய்வதில் maintainer-கள் அதிக நேரத்தை வீணடிக்கிறார்கள்." "என்னால் இதை உண்மையான வன்பொருளில் (real hardware) சோதிக்க முடியவில்லை" என்று எழுதுவதால் உங்களுக்கு எந்த இழப்பும் இல்லை. ஆனால், சோதித்ததாகக் கூறுவது உங்கள் மீதான நம்பிக்கையைத் தகர்த்துவிடும்.
Review கருத்துகளுக்கு நீங்களே, உங்கள் சொந்த வார்த்தைகளில், உங்கள் நேரத்தைப் பயன்படுத்தி பதிலளியுங்கள். ஒரு கருத்து வந்த முப்பது வினாடிகளுக்குள், அதை ஐந்து பத்திகளில் மீண்டும் விவரிக்கும் பதில், என்ன நடந்தது என்பதை maintainer-க்குத் தெளிவாக உணர்த்திவிடும். Diff-ஐச் சிறியதாக வைத்திருங்கள். நீங்கள் முழுமையாகப் புரிந்துகொண்ட நாற்பது வரிகள், நீங்கள் மேற்பார்வை செய்த நானூறு வரி refactor-ஐ விடத் திட்டத்திற்கு அதிக மதிப்புடையவை. உங்கள் agent நீங்கள் கேட்டதை விட அதிகமாக வழங்கினால், வேலை செய்யும் மிகச்சிறிய மாற்றத்திற்கு அதை உட்படுத்தும் திறன் என்பது, patch-ஐ உங்களால் வரி வரியாக விளக்கக்கூடிய அளவில் வைத்திருக்க ஒரு வழியாகும்.
ஏஜென்ட் அறிவுறுத்தல்களை களஞ்சியத்தில் (repository) வைத்திருத்தல்
நீங்கள் உங்கள் ஏஜென்ட்டிற்கு வழங்கும் அறிவுறுத்தல்கள் உங்கள் டூல்கெயினின் (toolchain) ஒரு பகுதியாகும், எனவே அவற்றை குறியீட்டைப் போலவே கையாளவும். களஞ்சியத்தின் ரூட் (root) கோப்பகத்தில் உள்ள ஒரு கோப்பு, பொதுவாக AGENTS.md, பில்ட் கட்டளை (build command), சோதனை கட்டளை (test command), கமிட் மெசேஜ் வடிவம் (commit message format), சைன்-ஆஃப் தேவை (sign-off requirement) மற்றும் திட்டத்தில் ஏற்கனவே ஆவணப்படுத்தப்பட்ட ஸ்டைல் விதிகளை உள்ளடக்கியிருக்கும். அந்தக் கோப்பு பதிப்பு கட்டுப்பாடு (versioned) மற்றும் மறுஆய்வு செய்யக்கூடியது; அது இன்று எப்படியோ, நாளையும் அப்படியே இருக்கும். ஒவ்வொரு முறையும் நினைவிலிருந்து தட்டச்சு செய்யப்படும் அறிவுறுத்தல்கள் ஒவ்வொரு முறையும் வெவ்வேறு பேட்ச்களை (patch) உருவாக்கும்; நிராகரிக்கப்பட்ட பேட்ச் எந்த அமர்வில் உருவாக்கப்பட்டது என்பதை உங்களால் அறிய முடியாது. ஏஜென்ட் மற்றும் மனிதர் இருவருக்கும் புரியும் வகையில் AGENTS.md எழுதுதல் என்பது அந்தக் கோப்பைப் பற்றியது.
மற்றவர்களின் களஞ்சியங்கள் குறித்து ஒரு எச்சரிக்கை. நீங்கள் பராமரிக்காத ஒரு திட்டத்தில், ஏஜென்ட் அறிவுறுத்தல் கோப்பைச் சேர்க்கும் முதல் பங்களிப்பை (PR) செய்யாதீர்கள். இது வெளியிலிருந்து திட்டத்தின் டூலிங் கொள்கையை (tooling policy) தீர்மானிக்க முயற்சிப்பது போலத் தோன்றும், மேலும் இது பராமரிப்பாளர்கள் ஏற்கனவே சலிப்படைந்த ஒரு விஷயத்துடன் உங்கள் கணக்கை இணைக்க விரைவான வழியாகும். யாராவது கேட்கும் வரை அந்தக் கோப்பை உங்கள் ஃபோர்க்கிலேயே (fork) வைத்திருங்கள்.
நீங்கள் ஏஜென்ட்டை எங்கு இயக்குகிறீர்கள் என்பதும் அதே காரணத்திற்காக முக்கியமானது. நீங்கள் கட்டுப்படுத்தும் ஒரு சாண்ட்பாக்ஸில் (sandbox) திட்டத்தை பில்ட் செய்து சோதனைகளை இயக்கக்கூடிய ஒரு ஏஜென்ட், நீங்கள் உண்மையில் சரிபார்த்த ஒரு பேட்சை உங்களுக்கு வழங்கும். இது உதவியை வெளிப்படுத்துவதற்கும், ஒரு யூகத்தை வெளிப்படுத்துவதற்கும் உள்ள வித்தியாசமாகும். உங்கள் சொந்த VPS-ல் கோடிங் ஏஜென்ட்டை இயக்குதல் அந்த அமைப்பைப் பற்றியது, மேலும் Claude Code, Cursor, Codex மற்றும் Copilot ஆகியவற்றிற்கு இடையிலான நடைமுறை வேறுபாடுகள் இந்த கருவிகள் அன்றாடம் எவ்வாறு வேறுபடுகின்றன என்பதை விளக்குகிறது.
கொள்கை மாற்றங்களுக்குப் பிறகு பின்பற்ற வேண்டிய முறை
- எதையும் எழுதுவதற்கு முன்பு, repository, developer docs, website, அல்லது tracker ஆகியவற்றில் குறிப்பிடப்பட்டுள்ள கொள்கையைக் கண்டறியவும்.
- கொள்கை எதுவும் இல்லை என்றால், issue-ல் ஒரே வரியில் கேட்டு, அதற்கான பதிலைச் சேமித்து வைக்கவும்.
- அந்தத் திட்டம் பயன்படுத்தும் படிவத்தில் தகவலை வெளிப்படுத்தவும், commit trailer-ல் குறிப்பிடவும், ஒருவேளை அந்தத் திட்டம் PR-ஐ squash செய்தால், PR body-யிலும் அதை மீண்டும் பதிவிடவும்.
- உங்கள் உண்மையான பெயருடன் sign off செய்யவும்; இந்த வரி நீங்கள் குறியீட்டைச் சமர்ப்பிப்பதற்கான உரிமையைக் கோருகிறது என்பதை உணர்ந்திருக்கவும்.
- உங்கள் சொந்த patch-ஐ ஒரு அந்நியர் எழுதியது போல மறுபரிசீலனை செய்யவும், ஏனெனில் உண்மையில் அது ஒரு அந்நியரால் எழுதப்பட்டதுதான்.
இந்தத் தளத்தில் பெயரிடப்பட்டுள்ள ஒவ்வொரு திட்டமும் நீங்கள் இதைப் படிக்கும் நேரத்திற்குள் மாறியிருக்கக்கூடும். ஆனால், இந்த ஐந்து படிகள் மாறாது.
FAQ
நான் AI coding agent-ஐப் பயன்படுத்தினேன் என்பதைத் தெரிவிக்க வேண்டுமா?
திட்டத்தின் விதிமுறைகளைச் சரிபார்க்கவும், ஏனெனில் இதற்கான பதில் அந்தந்த அளவில் (locally) நிர்ணயிக்கப்படுகிறது. Fedora-வில், மாற்றங்கள் ஏதுமின்றி ஒரு கருவியின் மூலம் உருவாக்கப்பட்ட கணிசமான பங்களிப்பு இருந்தால், அதைத் தெரிவிக்க வேண்டும். Linux kernel ஒரு Assisted-by trailer-ஐக் கோருகிறது. ஆகஸ்ட் 2026 நிலவரப்படி, Gentoo மற்றும் QEMU இத்தகைய பங்களிப்புகளை ஏற்பதில்லை. எங்கும் எழுதப்பட்ட விதிமுறைகள் இல்லை எனில், commit trailer-ல் அதைத் தெரிவிப்பது நல்லது. ஒரு maintainer இதைப் பிற்காலத்தில் கண்டறிந்தால், அவர் அந்தத் கருவியை விட, தகவலை மறைத்ததையே பெரிதாகக் கருதுவார்; அந்த எதிர்மறை எண்ணம் நீங்கள் அனுப்பிய மற்ற அனைத்துப் பங்களிப்புகளையும் பாதிக்கும்.
எந்தெந்த open source திட்டங்கள் AI-ஆல் உருவாக்கப்பட்ட code-ஐத் தடை செய்கின்றன?
ஆகஸ்ட் 2026-ன் நிலவரப்படி: ஏப்ரல் 2024 முதல் Gentoo, LLM வெளியீட்டைத் தரம் குறைந்த code-ஆகக் கருதி core குழுவின் அனுமதி கோரும் NetBSD, உருவாக்கப்பட்ட உள்ளடக்கத்திலிருந்து பெறப்பட்ட பங்களிப்புகளை மறுக்கும் QEMU, மற்றும் Loupe, Calendar உள்ளிட்ட பல GNOME applications. இந்த பட்டியலை விட அந்தந்த திட்டத்தின் சொந்த ஆவணங்களைப் படிக்கவும், ஏனெனில் இவை காலப்போக்கில் மாறக்கூடும். பெரும்பாலான திட்டங்களில் உள்ள விலக்கு இதுதான்: ஒரு API-ஐப் பற்றி ஆராய்ச்சி செய்ய, static analysis செய்ய அல்லது debug செய்ய ஒரு மாதிரியைப் பயன்படுத்துவது பொதுவாக அனுமதிக்கப்படும், அதன் வெளியீடு patch-ல் இல்லாத வரை.
Signed-off-by மற்றும் signed commit-க்கு என்ன வித்தியாசம்?
Signed-off-by என்பது git commit -s மூலம் சேர்க்கப்படும் ஒரு plain text வரியாகும். இது developer certificate of origin-ஐ உறுதிப்படுத்துகிறது, அதாவது அந்தத் திட்டத்தின் உரிமத்தின் கீழ் இந்த code-ஐச் சமர்ப்பிக்க உங்களுக்கு உரிமை உண்டு என்று பொருள். git commit -S மூலம் செய்யப்படும் signed commit என்பது, உங்கள் GPG அல்லது SSH key-ஐப் பயன்படுத்தி commit object-ன் மீது இடப்படும் ஒரு cryptographic signature ஆகும். இது அந்த commit உங்கள் key-லிருந்துதான் வந்தது என்பதையும், அது மாற்றப்படவில்லை என்பதையும் நிரூபிக்கிறது. தோற்றம் (origin) மற்றும் அடையாளம் (identity) ஆகிய இரண்டும் தனித்தனி உரிமைகோரல்கள், எனவே ஒரு signed commit-ம் AI கொள்கையை மீறக்கூடும்.
disclosure-ஐ commit message-க்குப் பதிலாக pull request description-ல் வைக்கலாமா?
அதை commit message-லேயே வைக்கவும், ஏனெனில் அதுதான் git வரலாற்றில் பதிவாகி, பிற்காலத்தில் அந்த repository-ஐ clone செய்யும் அனைவருக்கும் சென்றடையும். Pull request description-ஐப் பிற்காலத்தில் திருத்த முடியும், மேலும் அது hosting platform-ல் மட்டுமே இருக்கும். திட்டம் squash merge செய்யும்போது, PR body-யிலும் அதைச் சேர்க்கவும், ஏனெனில் squash உங்கள் commit message-ஐ மாற்றி, trailer-ஐ நீக்கிவிட வாய்ப்புள்ளது.
எனது pull request AI-ஆல் உருவாக்கப்பட்டது என்ற காரணத்தால் மூடப்பட்டது. இப்போது என்ன செய்வது?
அந்த thread-ல் கொள்கை குறித்து விவாதிக்க வேண்டாம், ஏனெனில் அதை மூடியவர் மட்டும் அந்த விதியை உருவாக்கவில்லை, அந்த thread-ல் கொள்கை மாறப்போவதும் இல்லை. கொள்கை ஆவணத்தைப் படித்துவிட்டு, உங்களால் அதை நிறைவேற்ற முடியுமா என்று முடிவு செய்யுங்கள். ஒரு திட்டம் உருவாக்கப்பட்ட patch-களைத் தடை செய்திருந்தால், patch இல்லாமல் ஒரு தெளிவான bug report மற்றும் அதை மீண்டும் உருவாக்கும் வழிமுறைகளை (reproducer) சமர்ப்பிக்கலாம்; இது பெரும்பாலும் அதிக பயனுள்ள பங்களிப்பாக இருக்கும். மீண்டும் code-உடன் வருவதாக இருந்தால், ஒவ்வொரு வரியையும் உங்களால் விளக்கக்கூடிய சிறிய மாற்றத்துடன் வாருங்கள்.