AI కోడ్‌ను open source కు పంపే ముందు తెలుసుకోవాల్సినవి

AI సహాయంతో తయారు చేసిన కోడ్‌ను upstream కు పంపే ముందు చేయాల్సినవి

Open source ప్రాజెక్ట్‌లు ఇప్పుడు AI సహాయంతో తయారు చేసిన కోడ్‌పై విధానాలను ప్రచురిస్తున్నాయి. అయితే ఆ విధానాలు ఒకదానితో మరొకటి ఏకీభవించవు. కాబట్టి పాటించాల్సిన సులభమైన పద్ధతి ఇదే: patch రాయడానికి ముందు ఆ విధానాన్ని కనుగొనండి. దాన్ని పంపేటప్పుడు వివరాలను ఖచ్చితంగా వెల్లడించండి. ఈ రెండింటికీ ఆధారమైన ఒక నియమం ఉంది. code review లో వివరించలేని ఏ line ను సమర్పించవద్దు.

ప్రాజెక్ట్ generated code ను నిషేధిస్తే, లేదా code ఎక్కడి నుంచి వచ్చిందో మీరు దాచిపెడితే, సరైన patch కూడా close చేయబడుతుంది. దాని ప్రభావం మీ పేరుపై పడుతుంది. అది అక్కడే మిగిలిపోతుంది. ఎందుకంటే maintainer తరువాత ఆ విషయాన్ని గుర్తిస్తే, మీ మిగిలిన చరిత్రను నమ్మడానికి అతనికి కారణం ఉండదు. ముందుగా కొన్ని పదాల అర్థాలు తెలుసుకుందాం, ఎందుకంటే policies లో అవే పదాలు ఉపయోగిస్తారు. LLM (large language model) అనేది మీ coding agent వెనుక పనిచేసే model. GitHub లోని PR (pull request) ను GitLab లో MR (merge request) అంటారు. దిగువన ఉన్న విషయం రెండింటికీ వర్తిస్తుంది. DCO (developer certificate of origin) అనేది commit message చివర ఉండే sign-off line. మొత్తం చర్చలో ఇది ప్రధాన అంశంగా మారుతుంది.

AI కోడ్‌పై open source విధానాలు ఎక్కడికి చేరుకున్నాయి

ప్రాజెక్టులు నాలుగు విధాన వర్గాల్లో స్థిరపడ్డాయి. కింది ప్రతి ఉదాహరణకు తేదీ ఉంది, ఎందుకంటే ఈ పాఠ్యాలు మారుతూ ఉంటాయి.

నిషేధం. 14 April 2024న Gentoo కౌన్సిల్ ఓటు వేసి, “Natural Language Processing artificial intelligence tools సహాయంతో సృష్టించిన ఏ contentనైనా Gentooకి contribute చేయడం స్పష్టంగా నిషేధం” అని నిర్ణయించింది. NetBSD commit guidelines, LLM నుంచి వచ్చిన outputను “tainted code”గా పేర్కొంటాయి. core నుంచి ముందస్తు లిఖితపూర్వక అనుమతి లేకుండా దాన్ని commit చేయకూడదని అవి చెబుతాయి. August 2026 నాటికి QEMU code provenance document కూడా, AI generated contentను కలిగి ఉందని లేదా దాని నుంచి ఉద్భవించిందని భావించే contributionsను project “DECLINE” చేస్తుందని ఇప్పటికీ చెబుతోంది.

విశ్లేషణకు మాత్రమే. చాలా నిషేధాలు headlineలో కనిపించేదానికంటే పరిమితమైనవి. “APIs లేదా algorithms పరిశోధించడం, static analysis, debugging వంటి AI ఇతర వినియోగాలకు ఈ విధానం వర్తించదు; అయితే వాటి output contributionsలో చేర్చకూడదు” అని QEMU document చెబుతోంది. కోడ్ చదవడానికి మీరు agentను ఉపయోగించవచ్చు. అది రాసినదాన్ని మీరు ship చేయకూడదు. చాలా restrictive projectsలో అమలులో ఉన్న ప్రధాన సరిహద్దు ఇదే. చాలామంది పట్టించుకోని తేడా కూడా ఇదే.

వెల్లడింపు తప్పనిసరి. October 2025లో Fedora కౌన్సిల్ AI-assisted contributionsపై విధానాన్ని ఆమోదించింది. ఇది tools వినియోగాన్ని అనుమతిస్తుంది, బాధ్యతను వ్యక్తిపైనే ఉంచుతుంది: contributorనే authorగా పరిగణిస్తారు, మొత్తం contributionకు అతనే పూర్తి బాధ్యత వహించాలి, అలాగే ఒక tool నుంచి వచ్చిన contentలో ముఖ్యమైన భాగాన్ని మార్పులు లేకుండా ఉపయోగించినప్పుడు దాన్ని వెల్లడించాలి. December 2025లో Linux kernel తన process documentationలో coding assistants pageను చేర్చింది. అందులో toolను నమోదు చేయడానికి trailer, అలాగే ఎవరు sign off చేయవచ్చో నిర్దేశించే కఠిన నియమం ఉన్నాయి.

లిఖితపూర్వకంగా ఏమీ లేదు. ఇప్పటికీ ఇదే సాధారణ పరిస్థితి. May 2026లో వచ్చిన ఒక preprint 1,000 ప్రసిద్ధ GitHub repositoriesను పరిశీలించింది. వాటిలో ఏదైనా లిఖితపూర్వక AI విధానం ఉన్నవి 118 మాత్రమే అని తేలింది. మౌనం అనుమతి కాదు. మీరు patch రాయడానికి ముందు issue trackerలో ఒక వాక్యంతో ప్రశ్న అడగండి. అప్పుడు వచ్చిన సమాధానం తర్వాత చూపించగలిగే public recordగా మారుతుంది.

నిర్వాహకులు ఈ నియమాలను ఎందుకు రూపొందించారు

మొదటి కారణం review load, మరియు లెక్క ఒకే దిశలో సాగుతుంది. ఒక agent ఒక నిమిషంలో నమ్మదగినదిగా కనిపించే 400 line merge request ను రూపొందించగలదు. ఆ request ను సరిగ్గా review చేయడానికి maintainer కు ఒక మధ్యాహ్నం పడుతుంది; చాలా మంది maintainers volunteers. సమర్పణ ఖర్చు దాదాపు శూన్యానికి తగ్గింది. Review ఖర్చులో మాత్రం ఎలాంటి మార్పు రాలేదు.

ఆ వక్రరేఖకు చివరి భాగాన్ని curl చూపిస్తుంది. 2025 మధ్యలో Daniel Stenberg తెలిపిన ప్రకారం, project's bug bounty ద్వారా వచ్చిన security reports లో దాదాపు ఐదవ వంతు ఆయన "AI slop" అని పిలిచేవి: నిజమైన functions మరియు నిజమైన code paths పేర్లు చెప్పే, సాధ్యమైన attack ను వివరించే, కానీ వాస్తవంగా ఏమీ లేని reports. ఆ flood కు నిధులు కొనసాగించకుండా project 2026 ప్రారంభంలో bounty ను నిలిపివేసింది. అవి patches కాకుండా reports అయినప్పటికీ, maintainer మీ PR ను ఇప్పటికే అలసటతో తెరవడానికి కారణమయ్యే mechanism ఇదే.

GNOME Calendar ఈ సమస్యను ఒక label గా నమోదు చేసింది. 2026 June లో, code ను రూపొందించడానికి "artificial 'intelligence' పై ప్రధానంగా లేదా పూర్తిగా ఆధారపడిన" merge requests కోసం project "Probabilistically Automated" అనే label ను ప్రవేశపెట్టింది. ఆ లక్షణాన్ని కూడా స్పష్టంగా పేర్కొంది: "సాధారణంగా సరైన testing లేకపోవడం, మరియు code correctness కంటే ఊహించిన intended behavior ఆధారంగా patches ను finalizing చేయడం దీనితో పాటు కనిపిస్తాయి". చివరి వాక్యాన్ని రెండుసార్లు చదవండి. Code పనిచేయాలి అనిపిస్తుంది. అది నిజంగా పనిచేస్తుందో ఎవరూ తనిఖీ చేయలేదు.

రెండవ కారణం provenance. అంటే code ఎక్కడి నుంచి వచ్చింది, ఏ license కింద వచ్చింది అన్నది. QEMU ఈ conflict ను స్పష్టంగా చెబుతుంది: sign off చేయడం ద్వారా మీరు సమర్పిస్తున్న content యొక్క "copyright మరియు license status ను పూర్తిగా అర్థం చేసుకున్నారని" ధృవీకరిస్తారు; model output యొక్క copyright status ఇంకా స్పష్టంగా నిర్ణయించబడలేదు. Quality మరియు ethics తో పాటు ఇదే కారణాన్ని Gentoo council కూడా పేర్కొంది. ఈ legal reading తో మీరు ఏకీభవించాల్సిన అవసరం లేదు. కానీ నిర్ణయం maintainer తీసుకోవాల్సిందే, మీరు కాదు, అన్న విషయాన్ని గుర్తించాలి.

ప్రాజెక్ట్ యొక్క AI విధానాన్ని ఎలా కనుగొనాలి?

క్రింది ప్రదేశాల్లో ఈ క్రమంలో చూడండి.

• Repository root లోని CONTRIBUTING.md, తరువాత .github/CONTRIBUTING.md, ఆ తరువాత దాని పక్కన ఉన్న ఏదైనా DCO file.
• Developer docs. 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 ఆదేశం ద్వారా దీనిలో ఎక్కువ భాగాన్ని కనుగొనవచ్చు:

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

తరువాత ప్రాజెక్ట్ యొక్క స్వంత history చదవండి. దాని సారాంశం కంటే committed convention కు ప్రాధాన్యత ఉంటుంది:

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 వాస్తవంగా ఉపయోగించే రూపాన్ని తెలియజేస్తుంది. ఫలితం ఖాళీగా ఉంటే, ఇక్కడ ఎవరూ ఆ రూపంలో disclosure చేయలేదని అర్థం; అది కూడా ఉపయోగకరమైన సమాచారం. Project GitHub పై ఉంటే, ఈ workflow మీకు కొత్తదైతే, ఈ section ఆధారపడే విధానాన్ని GitHub లో pull requests మరియు forks ఎలా పనిచేస్తాయో వివరిస్తుంది.

కామెంట్‌లో కాకుండా commit trailer లో వెల్లడించండి

Trailer అనేది commit message చివరి paragraph లోని Key: value line. Git ఇప్పటికే Signed-off-by: మరియు Co-authored-by: కోసం ఇదే నిర్మాణాన్ని ఉపయోగిస్తుంది. 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]గా document చేస్తుంది. ఆ 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 ను అది స్వయంగా సృష్టించనివ్వకండి.

పేర్లు మారవచ్చు. మీ స్వంతదాన్ని ఊహించి రాయడం కంటే, స్థానికంగా ఉపయోగించేదాన్ని copy చేయండి. May 2026లో QEMU list కు పంపిన patch, mechanical changes, tests, docs మరియు ఇరవై lines లేదా అంతకంటే తక్కువ ఉన్న bug fixes కోసం ఆ project ban ను సడలించాలని ప్రతిపాదించింది. ఇది AI-used-for: tests, docs వంటి trailer తో నమోదు చేయబడింది. August 2026 నాటికి ఇది mailing list లోని proposal మాత్రమే. Committed document ఇంకా generated content ను అనుమతించదు. ఒక project 2023 నుంచి 2026 మధ్య తన వైఖరిని రెండుసార్లు మార్చింది. తదుపరి మార్పు మీ కోసం వేచి ఉండదు. అందుకే list కంటే method ముఖ్యమైనది.

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 చేయాలి. ఖాళీ line వస్తే git trailer ను parse చేయలేదని అర్థం. సాధారణంగా message దిగువన ఉన్న trailer block లో blank line లేదా సాధారణ sentence ఉండటమే కారణం. ఇప్పటికే రాసిన 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 ను తిరిగి రాస్తుంది. అందువల్ల squash చేసే project లో maintainer చూసే PR description లో disclosure ను మళ్లీ చేర్చండి. Review comment record కాదు. Comments ను edit చేయవచ్చు, అవి 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) ప్రకారం, contribution "was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file". Clause (b) మీరు మార్పులతో పాటు అందించే హక్కు కలిగిన, ముందుగా ఉన్న open source code ఆధారంగా చేసిన పనిని వర్తిస్తుంది. Clause (c) అదే విషయాన్ని ధృవీకరించిన మరొక వ్యక్తి మీకు అందించిన code ను వర్తిస్తుంది. Clause (d) ప్రకారం, contribution మరియు మీ sign-off లోని వ్యక్తిగత సమాచారం public గా ఉంటాయని, నిరవధికంగా నిల్వ చేయబడుతుందని మీరు అర్థం చేసుకున్నట్లు ప్రకటిస్తారు.

ఇందులో లేనిదాన్ని గమనించండి. DCOలోని ప్రతి character ను మీరు స్వయంగా టైప్ చేశారని ఎక్కడా చెప్పదు. ఈ license కింద code ను submit చేసే హక్కు మీకు ఉందని మాత్రమే చెబుతుంది. అందుకే generated code విషయంలో ఇది స్పష్టంగా సరిపోదు. ప్రశ్న authorship గురించి కాదు. code యొక్క origin ను మీరు వివరించగలరా అనేదే ప్రశ్న. Sign-off అవసరమయ్యే చాలా projects లో real name కూడా అవసరం. అందువల్ల pseudonym ఈ తనిఖీలో విఫలమవుతుంది. git commit -s ఉన్న line ను జోడించండి. అది user.name మరియు user.email ను మీ git config నుంచి చదువుతుంది. DCO bot మీ PR ను విఫలపరిచి, line లేని commit ను పేర్కొంటే, 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 మూలం గురించి చేసే ప్రకటన. Signature అనేది గుర్తింపు గురించి చేసే ప్రకటన. రెండూ కావాలనుకునే projects రెండింటినీ అడుగుతాయి.

మీ సమీక్షలో వివరించలేని కోడ్‌ను ఎప్పుడూ సమర్పించవద్దు

ఇదే పరీక్ష. ఇది నిజాయితీ గురించి మాత్రమే కాదు. ప్రతి లైన్‌ గురించి అడగండి: ఇది దేనికి? ఇది లేకపోతే ఏమి విఫలమవుతుంది? ఈ రెండు ప్రశ్నల్లో ఏదో ఒకదానికి సమాధానం లేకపోతే patch సిద్ధంగా లేదు. ఎందుకంటే review comment వస్తుంది, దానికి మీ సమాధానం మరో generation దశగా మారుతుంది. Reviewers దీన్ని గుర్తించగలరు. ఆ సమయంలో contributor ప్రాజెక్ట్‌కు ఖర్చుగా మారతాడు. అంచు పరిస్థితులు, ఖాళీ input, failure path, రెండో caller గురించి కూడా ఇదే ప్రశ్న అడగండి.

ఆ పని అమలు చేయండి. దాన్ని build చేయండి, ప్రాజెక్ట్ test suite ను run చేయండి, అలాగే మీరు పరిష్కరిస్తున్నామని చెప్పే bug కోసం reproducer రాయండి. Kernel documentation స్పష్టంగా ఇలా చెబుతుంది: "If the fix could not be built or tested, or if no reproducer could be produced, say so explicitly: maintainers currently waste too much time analyzing unverified reports and untested fixes." "నేను దీన్ని real hardware పై test చేయలేకపోయాను" అని రాయడం వల్ల మీకు ఎలాంటి నష్టం లేదు. మీరు test చేశారని సూచించడం వల్ల ప్రాజెక్ట్‌కు నష్టం కలుగుతుంది.

Review comments కు మీరే, మీ స్వంత మాటల్లో, మీ స్వంత సమయానికి సమాధానం ఇవ్వండి. Comment వచ్చిన ముప్పై seconds లోనే reply చేసి, దాన్ని ఐదు paragraphs లో మళ్లీ చెప్పడం ద్వారా ఏమి జరిగిందో maintainer కు స్పష్టంగా తెలుస్తుంది. Diff ను కూడా చిన్నదిగా ఉంచండి. మీరు పూర్తిగా అర్థం చేసుకున్న నలభై lines, మీరు పర్యవేక్షించిన నాలుగు వందల lines refactor కంటే ప్రాజెక్ట్‌కు ఎక్కువ విలువైనవి. మీరు అడిగినదానికంటే ఎక్కువ code ను మీ agent పదే పదే తిరిగి ఇస్తే, పనిచేసే అతి చిన్న మార్పుకే దాన్ని పరిమితం చేసే skill patch ను మీరు line by line సమర్థించగల పరిమాణంలో ఉంచడానికి ఒక మార్గం.

రిపోజిటరీలో agent సూచనలను ఉంచండి

మీ agent కు ఇచ్చే సూచనలు మీ toolchain లో భాగం. కాబట్టి వాటిని code లాగా పరిగణించండి. సాధారణంగా AGENTS.md అనే ఫైల్ రిపోజిటరీ root లో ఉంటుంది. ఇందులో build command, test command, commit message format, sign-off requirement, అలాగే ప్రాజెక్ట్ ఇప్పటికే నమోదు చేసిన style rules ఉంటాయి. ఆ ఫైల్ version control లో ఉంటుంది, దానిని review చేయవచ్చు. ఈరోజు ఉన్న సూచనలే రేపు కూడా ఉంటాయి. ప్రతి session లో జ్ఞాపకం నుంచి మళ్లీ టైప్ చేసిన సూచనలు ప్రతి session లో వేర్వేరు patch ను తయారు చేస్తాయి. ఏ session తయారు చేసిన patch reject అయిందో మీకు తెలియదు. agent మరియు మానవుడు ఇద్దరూ చదవగలిగే AGENTS.md రాయడంలో ఆ ఫైల్ గురించి వివరించబడింది.

ఇతరుల రిపోజిటరీల విషయంలో ఒక జాగ్రత్త పాటించండి. మీరు నిర్వహించని ప్రాజెక్ట్‌కు చేసే మొదటి contribution గా agent instruction file ను జోడించే PR చేయవద్దు. అది బయట నుంచి ప్రాజెక్ట్ tooling policy ని నిర్ణయించడానికి చేస్తున్న ప్రయత్నంలా కనిపిస్తుంది. Maintainers ఇప్పటికే విసిగిపోయిన విషయంతో మీ account ను అనుసంధానించుకోవడానికి ఇది వేగవంతమైన మార్గం. ఎవరైనా అడిగే వరకు ఆ ఫైల్‌ను మీ fork లోనే ఉంచండి.

అదే కారణంతో agent ను ఎక్కడ నడుపుతున్నారన్నది కూడా ముఖ్యం. మీరు నియంత్రించే sandbox లో agent ప్రాజెక్ట్‌ను build చేసి, దాని tests ను run చేయగలిగితే, మీరు నిజంగా verify చేసిన patch లభిస్తుంది. Assistance ను వెల్లడించడం మరియు ఊహ ఆధారంగా చేసిన మార్పును వెల్లడించడం మధ్య ఇదే తేడా. మీ స్వంత VPS పై coding agent ను నడపడంలో ఆ setup గురించి వివరించబడింది. Claude Code, Cursor, Codex మరియు Copilot మధ్య ఆచరణాత్మక తేడాలులో ఈ tools రోజువారీ వినియోగంలో ఎలా వేర్వేరుగా ఉంటాయో వివరించబడింది.

విధానం మారిన తర్వాత అనుసరించాల్సిన పద్ధతి

1. ఏదైనా రాయడానికి ముందు పేర్కొన్న విధానాన్ని కనుగొనండి: repository, developer docs, website, tracker.
2. విధానం లేకపోతే, issue లో ఒక వాక్యంలో అడిగి, వచ్చిన సమాధానాన్ని భద్రపరచండి.
3. project ఉపయోగించే రూపంలో disclosure ఇవ్వండి. దాన్ని commit trailer లో చేర్చండి. project squash చేస్తే PR body లో కూడా మళ్లీ చేర్చండి.
4. మీరు సమర్పిస్తున్న code ను సమర్పించే హక్కు మీకు ఉందని తెలిపే ప్రకటనగా ఆ పంక్తి ఉంటుంది. అందువల్ల మీ అసలు పేరుతో sign off చేయండి.
5. మీ patch ను అపరిచితుడు రాసినట్లుగా స్వయంగా review చేయండి. ఎందుకంటే దాన్ని వాస్తవంగా అపరిచితుడే review చేయవచ్చు.

మీరు దీన్ని చదివే సమయానికి ఈ పేజీలో పేర్కొన్న ప్రతి project మారిపోయి ఉంటుంది. ఈ ఐదు దశలు మాత్రం మారవు.

FAQ

నేను AI coding agent ను ఉపయోగించానని వెల్లడించాలా?

ప్రాజెక్ట్ నియమాలను పరిశీలించండి, ఎందుకంటే సమాధానం ప్రతి ప్రాజెక్ట్‌లో వేరుగా ఉంటుంది. మార్పులు చేయకుండా ఒక tool ద్వారా contribution లో గణనీయమైన భాగం రూపొందితే Fedora దాని వెల్లడిని కోరుతుంది. Linux kernel ఒక Assisted-by trailer ను కోరుతుంది. August 2026 నాటికి Gentoo మరియు QEMU contribution ను పూర్తిగా అంగీకరించవు. ఎక్కడా నియమం రాసి లేకపోయినా commit trailer లో వెల్లడించండి. తరువాత ఈ విషయం maintainer కు తెలిసినప్పుడు, tool ను కాకుండా వెల్లడించకపోవడాన్ని వారు విమర్శిస్తారు. ఆ స్పందన మీరు పంపిన ఇతర మార్పులన్నింటిపైనా ప్రభావం చూపుతుంది.

AI ద్వారా రూపొందించిన code ను ఏ open source ప్రాజెక్ట్‌లు నిషేధిస్తున్నాయి?

August 2026 నాటి పరిస్థితి ప్రకారం: April 2024 నుంచి Gentoo, LLM output ను core approval అవసరమైన tainted code గా పరిగణించే NetBSD, generated content నుంచి ఉద్భవించిన contributions ను తిరస్కరించే QEMU, అలాగే Loupe మరియు Calendar సహా అనేక GNOME applications. ఈ జాబితా త్వరగా పాతబడే అవకాశం ఉన్నందున, దీనికన్నా ప్రతి ప్రాజెక్ట్ స్వంత నియమాలను చదవండి. వీటిలో చాలావరకు పంచుకునే మినహాయింపును గమనించండి: API ను పరిశోధించడానికి, static analysis నడపడానికి లేదా debugging లో సహాయం పొందడానికి model ను ఉపయోగించడం సాధారణంగా అనుమతించబడుతుంది; దాని output patch లో ఉండకూడదు.

Signed-off-by మరియు signed commit మధ్య తేడా ఏమిటి?

Signed-off-by అనేది git commit -s చే జోడించబడే plain text line. ఇది developer certificate of origin ను ధృవీకరిస్తుంది. అంటే, project license కింద ఈ code ను submit చేసే హక్కు మీకు ఉందని అర్థం. 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 లో నిలిచే record మరియు తరువాత repository ను clone చేసే ప్రతి వ్యక్తి వద్దకు code తో పాటు చేరే సమాచారం. Pull request description ను తరువాత మార్చవచ్చు. అది hosting platform లోనే ఉంటుంది. Project squash merge ఉపయోగిస్తే PR body లో కూడా దీన్ని జోడించండి. ఎందుకంటే squash మీ commit message ను తిరిగి రాసి trailer ను తొలగించవచ్చు.

నా pull request AI ద్వారా రూపొందించబడిందని మూసివేశారు. ఇప్పుడు ఏమి చేయాలి?

Thread లో policy గురించి వాదించవద్దు. దాన్ని మూసివేసిన వ్యక్తి ఆ నియమాన్ని ఒంటరిగా రూపొందించలేదు. Thread లో ఆ నియమం మారదు. Policy text ను చదివి, దాన్ని మీరు పాటించగలరా అని నిర్ణయించండి. Project generated patches ను నిషేధించినప్పుడు, reproducer తో కూడిన స్పష్టమైన bug report ను patch లేకుండా సమర్పించడం ఇప్పటికీ స్వాగతించబడుతుంది. తరచుగా అదే మరింత ఉపయోగకరమైన contribution అవుతుంది. Code తో తిరిగి వస్తే, ప్రతి line ను సమర్థించగల చిన్న మార్పుతో రండి.