AI code পাঠানোর আগে open source policy জানুন

AI-সহায়তায় তৈরি কোড upstream-এ পাঠানোর আগে কী করবেন

Open source project-গুলো এখন AI-সহায়তায় তৈরি কোড নিয়ে policy প্রকাশ করে, এবং সেই policy-গুলো পরস্পরের সঙ্গে একমত নয়। তাই অভ্যাসটি সহজ: patch লেখার আগে policy খুঁজে দেখুন, এবং patch পাঠানোর সময় নির্ভুলভাবে তথ্য প্রকাশ করুন। উভয় ক্ষেত্রেই একটি নিয়ম প্রযোজ্য। Review-এ যে line ব্যাখ্যা করতে পারবেন না, সেটি কখনো submit করবেন না।

Project generated code নিষিদ্ধ করলে, অথবা কোডের উৎস গোপন করলে, সঠিক patch-ও বন্ধ হয়ে যেতে পারে। এর দায় আপনার নামের সঙ্গে যুক্ত থাকে, কারণ কোনো maintainer পরে এই তথ্য গোপনের বিষয়টি জানতে পারলে আপনার বাকি কাজের ইতিহাসের ওপর আস্থা রাখার কারণ থাকে না। আগে কয়েকটি শব্দের অর্থ জানা দরকার, কারণ policy-গুলোতে এগুলো ব্যবহৃত হয়। 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 code নিয়ে open source নীতিমালা কোথায় দাঁড়িয়েছে

প্রকল্পগুলো চারটি ভাগে স্থির হয়েছে। নিচের প্রতিটি উদাহরণে তারিখ দেওয়া আছে, কারণ এই নথিগুলো পরিবর্তিত হয়।

নিষিদ্ধ। Gentoo-এর council 14 April 2024 তারিখে ভোট দিয়ে সিদ্ধান্ত নিয়েছে যে “Natural Language Processing artificial intelligence tools-এর সহায়তায় তৈরি কোনো content Gentoo-তে contribute করা expressively forbidden”। NetBSD-এর commit guideline-এ LLM-এর output-কে “tainted code” বলা হয়েছে, যা “core-এর prior written approval ছাড়া commit করা যাবে না”। August 2026 অনুযায়ী QEMU-এর code provenance document-এ এখনও বলা আছে যে প্রকল্পটি “AI generated content অন্তর্ভুক্ত বা সেখান থেকে উদ্ভূত বলে মনে হওয়া যেকোনো contribution DECLINE করবে”।

শুধু analysis। অধিকাংশ নিষেধাজ্ঞা শিরোনাম থেকে বেশি সীমিত। QEMU-এর document-এ বলা হয়েছে, এই policy “AI-এর অন্যান্য ব্যবহারের ক্ষেত্রে প্রযোজ্য নয়, যেমন API বা algorithm গবেষণা, static analysis অথবা debugging—যতক্ষণ তাদের output contribution-এর মধ্যে অন্তর্ভুক্ত না হয়”। আপনি code পড়ার জন্য agent ব্যবহার করতে পারেন। এটি যা লিখেছে, তা সরাসরি ship করতে পারবেন না। অধিকাংশ restrictive project-এ কার্যকর সীমারেখা এটাই, এবং মানুষ সাধারণত এই পার্থক্যটি উপেক্ষা করে।

Disclosure আবশ্যক। Fedora-এর council October 2025-এ AI-assisted contribution নিয়ে একটি policy অনুমোদন করেছে। এতে tools ব্যবহারের অনুমতি রয়েছে, তবে দায়িত্ব contributor-এর ওপর রাখা হয়েছে: contributor-ই author, পুরো contribution-এর জন্য তিনিই সম্পূর্ণভাবে accountable, এবং কোনো tool-এর কাছ থেকে আসা contribution-এর উল্লেখযোগ্য অংশ পরিবর্তন না করে ব্যবহার করা হলে তা disclose করতে হবে। Linux kernel December 2025-এ তার process documentation-এ coding assistants page যোগ করেছে। সেখানে tool record করার জন্য একটি trailer এবং কে sign off করতে পারবেন, সে বিষয়ে একটি কঠোর rule রয়েছে।

কিছু লিখিত নেই। এখনও এটাই সবচেয়ে সাধারণ পরিস্থিতি। May 2026-এর একটি preprint 1,000টি জনপ্রিয় GitHub repository সমীক্ষা করে দেখেছে, মাত্র 118টিতে কোনো লিখিত AI policy আছে। নীরবতা permission নয়। patch লেখা শুরু করার আগে issue tracker-এ এক বাক্যে জিজ্ঞাসা করুন। তাহলে উত্তরটি একটি public record হয়ে থাকবে, যা পরে প্রয়োজনে দেখাতে পারবেন।

কেন maintainer-রা এই নিয়মগুলো লিখেছেন

প্রথম কারণ হলো review-এর চাপ, এবং হিসাবটি একদিকেই যায়। একটি agent এক মিনিটে বিশ্বাসযোগ্য 400 লাইনের merge request তৈরি করতে পারে। সেই request যথাযথভাবে review করতে একজন maintainer-এর একটি বিকেল লেগে যায়, এবং বেশিরভাগ maintainer স্বেচ্ছাসেবক। জমা দেওয়ার খরচ প্রায় শূন্যে নেমে এসেছে। review করার খরচ একটুও কমেনি।

curl সেই প্রবণতার চরম দিকটি দেখায়। 2025 সালের মাঝামাঝি Daniel Stenberg জানান, প্রকল্পের bug bounty-এর মাধ্যমে আসা security report-এর প্রায় এক-পঞ্চমাংশ ছিল তাঁর ভাষায় AI slop: এমন report, যেখানে প্রকৃত function ও প্রকৃত code path-এর নাম থাকে, একটি বিশ্বাসযোগ্য attack বর্ণনা করা হয়, কিন্তু আসলে কোনো বিষয়বস্তু থাকে না। এই প্রবাহে অর্থায়ন চালিয়ে যাওয়ার বদলে প্রকল্পটি 2026 সালের শুরুতে bounty বন্ধ করে দেয়। সেগুলো patch নয়, report ছিল। তবে mechanism একই, যে mechanism-এর কারণে একজন maintainer আপনার PR খুলেই ক্লান্ত বোধ করেন।

GNOME Calendar সমস্যাটিকে একটি label হিসেবে নথিভুক্ত করেছে। 2026 সালের জুনে প্রকল্পটি এমন merge request-এর জন্য "Probabilistically Automated" label চালু করে, যেগুলোতে code তৈরির জন্য artificial 'intelligence'-এর "major or total reliance" দেখা যায়। তারা লক্ষণটিও স্পষ্টভাবে উল্লেখ করে: "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 দ্বন্দ্বটি স্পষ্টভাবে জানায়: sign-off করার অর্থ হলো আপনি যে content contribute করছেন তার "copyright and license status" "fully understand" করেন—এমন প্রত্যয় দেওয়া। কিন্তু model output-এর copyright status এখনও অনির্ধারিত। Gentoo-এর council quality ও ethics-এর পাশাপাশি একই কারণ উল্লেখ করেছে। এই legal interpretation-এর সঙ্গে আপনার একমত হওয়া বাধ্যতামূলক নয়। তবে বুঝতে হবে, সিদ্ধান্তটি 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

এরপর প্রকল্পটির নিজস্ব history পড়ুন, কারণ summary-এর চেয়ে 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 এই প্রকল্পে বাস্তবে ব্যবহৃত form জানায়। কোনো ফল না পাওয়ার অর্থ হলো এখানে কেউ ওই form-এ disclosure করেনি; এটিও তথ্য। প্রকল্পটি GitHub-এ থাকলে এবং workflow-টি আপনার কাছে নতুন হলে, GitHub-এ pull request ও fork কীভাবে কাজ করে এই section-এ ধরে নেওয়া mechanics ব্যাখ্যা করে।

কমেন্টে নয়, commit trailer-এ প্রকাশ করুন

একটি trailer হলো commit message-এর শেষ paragraph-এর একটি Key: value line। Git ইতিমধ্যে Signed-off-by: এবং Co-authored-by:-এর জন্য এই format ব্যবহার করে, এবং বিভিন্ন tool এটি parse করে। তাই code tree-তে code-এর সঙ্গে থাকা 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 নিজে থেকে তৈরি করতেও দেবেন না।

নাম বিভিন্ন project-এ ভিন্ন হতে পারে। তাই নিজের মতো করে তৈরি না করে local format-টি copy করুন। May 2026-এ QEMU mailing list-এ একটি patch প্রস্তাব করেছিল যে mechanical change, test, documentation এবং twenty lines বা তার কম bug fix-এর ক্ষেত্রে projectটির নিষেধাজ্ঞা শিথিল করা যায়। এটি AI-used-for: tests, docs-এর মতো trailer দিয়ে record করা হয়েছিল। 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 সরাসরি output করার কথা। Empty line-এর অর্থ Git trailer parse করেনি। সাধারণত commit 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 mode আগে থেকেই বিবেচনা করা উচিত। Squash merge commit message নতুন করে লেখে। তাই যে project squash merge করে, সেখানে PR description-এ disclosure-টি আবার লিখুন, যাতে maintainer এটি পড়তে পারেন। Review comment কোনো স্থায়ী record নয়, কারণ comment edit করা যায় এবং এটি কখনও Git history-তে যায় না।

নির্ভুলতা দুই দিকেই প্রযোজ্য। নিজে হাতে লেখা commit-এ Assisted-by যোগ করা অপ্রয়োজনীয় noise এবং এতে আপনার প্রকৃত disclosure-এর মূল্য কমে যায়। Agent যে commit লিখেছে, সেটিতে এটি বাদ দেওয়াই সম্পর্ক শেষ করার কারণ।

Signed-off-by বলতে আসলে কী প্রত্যয়ন করা হয়?

DCO হলো 1.1 সংস্করণের একটি সংক্ষিপ্ত লেখা। এটি developercertificate.org-এ প্রকাশিত এবং kernel, QEMU ও আরও অনেক প্রকল্পে ব্যবহৃত হয়। Signed-off-by: Your Name <you@example.com> যোগ করার অর্থ হলো আপনি এর বিষয়বস্তু প্রত্যয়ন করছেন। আপনি কী প্রত্যয়ন করছেন তা পড়ে নিন, কারণ অধিকাংশ মানুষ এটি কখনো না পড়েই sign করে।

ধারা (a)-তে বলা হয়েছে, contribution-টি “সম্পূর্ণ বা আংশিকভাবে আমার তৈরি এবং ফাইলে উল্লেখিত open source license-এর অধীনে এটি জমা দেওয়ার অধিকার আমার আছে”। ধারা (b) এমন কাজের ক্ষেত্রে প্রযোজ্য, যা আগের open source code-এর ওপর ভিত্তি করে তৈরি এবং যা পরিবর্তনসহ হস্তান্তর করার অধিকার আপনার আছে। ধারা (c) আপনার কাছে এমন কারও দেওয়া code-এর ক্ষেত্রে প্রযোজ্য, যিনি একই বিষয় প্রত্যয়ন করেছেন। ধারা (d)-তে বলা হয়েছে, contribution এবং আপনার sign-off-এ থাকা ব্যক্তিগত তথ্য public থাকবে এবং অনির্দিষ্টকাল সংরক্ষিত হবে।

এখানে কী অনুপস্থিত, তা লক্ষ্য করুন। DCO কখনো বলে না যে প্রতিটি character আপনি নিজে টাইপ করেছেন। এতে বলা হয়, এই license-এর অধীনে code জমা দেওয়ার অধিকার আপনার আছে। তাই generated code-এর ক্ষেত্রে বিষয়টি কিছুটা অস্পষ্ট: প্রশ্নটি authorship নয়, বরং code-এর origin সম্পর্কে আপনি দায়বদ্ধভাবে তথ্য দিতে পারেন কি না। Sign-off বাধ্যতামূলক এমন অধিকাংশ project-এ real name-ও বাধ্যতামূলক থাকে, তাই pseudonym ব্যবহার করলে check ব্যর্থ হয়। git commit -s দিয়ে line-টি যোগ করুন; এতে user.name এবং user.email আপনার git config থেকে পড়া হয়। DCO bot আপনার PR প্রত্যাখ্যান করে কোন commit-এ line-টি নেই তা জানালে, git rebase --signoff origin/main চালিয়ে আপনার branch-এ force push করলেই সমস্যাটি ঠিক হয়।

Commit sign করা এবং sign-off করা এক বিষয় নয়

git commit -s একটি text line যোগ করে। git commit -S আপনার GPG বা SSH key ব্যবহার করে commit object-এর ওপর cryptographic signature তৈরি করে। এগুলো ভিন্ন প্রশ্নের উত্তর দেয়। Signature প্রমাণ করে যে এই commit ওই key-এর ধারকের কাছ থেকে এসেছে এবং এরপর থেকে পরিবর্তিত হয়নি। এটি code-এর ভেতরের অংশ কোথা থেকে এসেছে সে সম্পর্কে কিছু বলে না। তাই গোপনে তৈরি করা code-এ পূর্ণ একটি signed commit-ও signed হতে পারে, কিন্তু তবু policy লঙ্ঘন করতে পারে। Sign-off হলো code-এর origin সম্পর্কে দাবি। Signature হলো পরিচয় সম্পর্কে দাবি। যে project দুটিই চায়, তারা উভয়টিই চাইবে।

এমন code কখনো submit করবেন না, যা review-এ ব্যাখ্যা করতে পারবেন না

এটাই পরীক্ষা, এবং এটি আসলে সততা নিয়ে নয়। প্রতিটি লাইনের জন্য জিজ্ঞেস করুন: এটি কী কাজে ব্যবহৃত হয়, এবং এটি ছাড়া কী ব্যর্থ হবে? কোনো একটি প্রশ্নের উত্তর না থাকলে patch প্রস্তুত নয়, কারণ review comment আসবে এবং আপনার উত্তরকে আরও একটি generation round-এর মধ্য দিয়ে যেতে হবে। Reviewers তা বুঝতে পারেন। তখন contributor প্রকল্পের জন্য একটি খরচে পরিণত হয়। একই প্রশ্ন edge case, empty input, failure path এবং দ্বিতীয় caller-এর ক্ষেত্রেও করুন।

কাজটি চালান। এটি build করুন, প্রকল্পের test suite চালান, এবং যে bug ঠিক করার দাবি করছেন তার জন্য একটি reproducer লিখুন। Kernel documentation-এ সৎ fallback স্পষ্ট ভাষায় দেওয়া আছে: "যদি fix build বা test করা না যায়, অথবা কোনো reproducer তৈরি করা না যায়, তাহলে তা স্পষ্টভাবে জানান: unverified report এবং untested fix বিশ্লেষণ করতে maintainers বর্তমানে অতিরিক্ত সময় ব্যয় করছেন।" "I could not test this on real hardware" লিখলে আপনার কোনো ক্ষতি হয় না। আপনি test করেছেন এমন ইঙ্গিত দিলে প্রকল্পের ক্ষতি হয়।

Review comment-এর উত্তর নিজে দিন, নিজের ভাষায় এবং নিজের সময় অনুযায়ী। Comment আসার ত্রিশ সেকেন্ড পর দেওয়া এমন একটি reply, যা পাঁচটি paragraph-এ comment-টিই পুনরাবৃত্তি করে, maintainer-কে ঠিক কী ঘটেছে তা জানিয়ে দেয়। Diff-ও ছোট রাখুন। সম্পূর্ণভাবে বোঝেন এমন চল্লিশটি line প্রকল্পের জন্য এমন একটি চারশো line-এর refactor-এর চেয়ে বেশি মূল্যবান, যা আপনি শুধু তত্ত্বাবধান করেছেন। আপনার agent যদি বারবার চাওয়ার চেয়ে বেশি পরিবর্তন ফিরিয়ে দেয়, যে skill কার্যকর হওয়া সবচেয়ে ছোট পরিবর্তনের মধ্যে তাকে সীমাবদ্ধ রাখে তা patch-কে এমন আকারে রাখতে সাহায্য করতে পারে, যা আপনি এখনও line ধরে defend করতে পারবেন।

রিপোজিটরিতে agent-এর নির্দেশনা রাখুন

আপনি agent-কে যে নির্দেশনা দেন, সেগুলো আপনার toolchain-এর অংশ। তাই এগুলোকে code-এর মতোই বিবেচনা করুন। সাধারণত repository root-এ থাকা AGENTS.md ফাইলে build command, test command, commit message-এর format, sign-off-এর প্রয়োজনীয়তা এবং project-এ ইতিমধ্যে নথিভুক্ত style rule থাকে। এই ফাইল version করা যায় এবং review করা যায়। আজ যেমন আছে, আগামীকালও এটি তেমনই থাকবে। প্রতিটি session-এ স্মৃতি থেকে নির্দেশনা আবার লিখলে প্রতিটি session-এ আলাদা patch তৈরি হবে। কোন session-এ প্রত্যাখ্যাত patch তৈরি হয়েছিল, তা তখন জানা যাবে না। agent এবং মানুষ উভয়েই পড়তে পারে এমন AGENTS.md লেখা ফাইলটি নিয়ে বিস্তারিত ব্যাখ্যা করে।

অন্যের repository নিয়ে একটি বিষয়ে সতর্ক থাকুন। আপনি যে project রক্ষণাবেক্ষণ করেন না, সেখানে agent instruction file যোগ করে প্রথম contribution হিসেবে PR খুলবেন না। এতে মনে হতে পারে, আপনি বাইরে থেকে project-এর tooling policy নির্ধারণের চেষ্টা করছেন। Maintainer-রা যে বিষয়টি নিয়ে ইতিমধ্যে বিরক্ত, তার সঙ্গে আপনার account যুক্ত হওয়ার এটি দ্রুত একটি উপায়। কেউ অনুরোধ না করা পর্যন্ত ফাইলটি আপনার fork-এ রাখুন।

একই কারণে agent কোথায় চালাবেন, সেটিও গুরুত্বপূর্ণ। আপনার নিয়ন্ত্রণাধীন sandbox-এর ভেতরে project build এবং test চালাতে পারে এমন agent আপনাকে এমন একটি patch দেয়, যা আপনি বাস্তবে যাচাই করেছেন। সহায়তা ব্যবহারের কথা জানানো এবং অনুমানভিত্তিক ফল জানানো—এই দুটির মধ্যে এটিই পার্থক্য। নিজের VPS-এ coding agent চালানো সেই setup ব্যাখ্যা করে। Claude Code, Cursor, Codex এবং Copilot-এর ব্যবহারিক পার্থক্য প্রতিদিনের ব্যবহারে tool-গুলোর পার্থক্য ব্যাখ্যা করে।

পলিসি পরিবর্তনের পর পদ্ধতিটি

1. কিছু লেখার আগে প্রকল্পে নির্ধারিত policy খুঁজে বের করুন: repository, developer docs, website বা tracker-এ দেখুন।
2. কোনো policy না থাকলে issue-তে এক বাক্যে জিজ্ঞাসা করুন এবং উত্তরটি সংরক্ষণ করুন।
3. প্রকল্পে নির্ধারিত form-এ, commit trailer-এ disclosure দিন। প্রকল্পটি squash করলে PR body-তেও একই disclosure পুনরাবৃত্তি করুন।
4. নিজের প্রকৃত নাম দিয়ে sign off করুন। মনে রাখুন, এই লাইনটি code জমা দেওয়ার আপনার অধিকারের একটি দাবি।
5. নিজের patch এমনভাবে review করুন, যেন এটি কোনো অপরিচিত ব্যক্তি লিখেছে। কারণ বাস্তবে সেটিই হয়েছে।

আপনি এটি পড়ার সময় এই পৃষ্ঠায় উল্লেখ করা প্রতিটি project-এর অবস্থান বদলে যাবে। কিন্তু এই পাঁচটি ধাপ বদলাবে না।

FAQ

আমাকে কি জানাতে হবে যে আমি একটি AI coding agent ব্যবহার করেছি?

প্রকল্পটির নিয়ম দেখুন, কারণ উত্তরটি স্থানীয় নীতির ওপর নির্ভর করে। কোনো টুলের সাহায্যে contribution-এর উল্লেখযোগ্য অংশ তৈরি হয়ে থাকলে এবং তাতে পরিবর্তন না করা হলে Fedora তা জানানো বাধ্যতামূলক করে। Linux kernel একটি Assisted-by trailer চায়। August 2026 অনুযায়ী Gentoo এবং QEMU এই ধরনের contribution একেবারেই চায় না। কোথাও লিখিত নির্দেশনা না থাকলেও commit trailer-এ তা জানিয়ে দিন। কোনো maintainer পরে বিষয়টি জানতে পারলে সাধারণত টুল ব্যবহারের চেয়ে তথ্য গোপন করার বিষয়টিকে বেশি গুরুত্ব দেন। সেই প্রতিক্রিয়ার প্রভাব আপনার পাঠানো অন্যান্য কাজেও পড়বে।

কোন open source প্রকল্প AI-generated code নিষিদ্ধ করে?

August 2026-এর অবস্থা অনুযায়ী, April 2024 থেকে Gentoo, NetBSD—যারা LLM-এর output-কে core approval প্রয়োজন এমন tainted code হিসেবে বিবেচনা করে—QEMU—যারা generated content থেকে তৈরি contribution গ্রহণ করে না—এবং Loupe ও Calendar-সহ কয়েকটি GNOME application AI-generated code নিষিদ্ধ করে। এই তালিকার বদলে প্রতিটি প্রকল্পের নিজস্ব নীতিমালা পড়ুন, কারণ তালিকাটি পুরোনো হয়ে যেতে পারে। অধিকাংশ প্রকল্পের একটি সাধারণ ব্যতিক্রম আছে: 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 প্রত্যয়ন করে। অর্থাৎ, প্রকল্পের license-এর অধীনে এই code জমা দেওয়ার অধিকার আপনার আছে। git commit -S দিয়ে তৈরি signed commit হলো আপনার GPG বা SSH key দিয়ে commit object-এর ওপর করা একটি cryptographic signature। এটি প্রমাণ করে যে commitটি আপনার key থেকে এসেছে এবং পরিবর্তন করা হয়নি। Origin এবং identity আলাদা দাবি। তাই signed commit থাকলেও সেটি AI policy লঙ্ঘন করতে পারে।

Commit message-এর বদলে pull request description-এ disclosure দিতে পারি কি?

Commit message-এ এটি লিখুন, কারণ git history-তে যে record যুক্ত হয় এবং পরে repository clone করা প্রত্যেকের কাছে code-এর সঙ্গে যে record পৌঁছায়, সেটি হলো commit message। Pull request description পরে সম্পাদনা করা যায় এবং এটি hosting platform-এ থাকে। প্রকল্পটি squash merge করলে PR body-তেও এটি যোগ করুন, কারণ squash আপনার commit message নতুন করে তৈরি করতে পারে এবং trailer বাদ পড়তে পারে।

AI-generated হওয়ার কারণে আমার pull request বন্ধ করে দেওয়া হয়েছে। এখন কী করব?

Thread-এ policy নিয়ে তর্ক করবেন না, কারণ যিনি এটি বন্ধ করেছেন তিনি একা নিয়মটি তৈরি করেননি এবং নিয়ম পরিবর্তনের স্থানও সেই thread নয়। Policy text পড়ুন, তারপর সিদ্ধান্ত নিন আপনি সেটি মেনে চলতে পারবেন কি না। প্রকল্পটি generated patch নিষিদ্ধ করলে reproducer-সহ একটি পরিষ্কার bug report, কিন্তু কোনো patch ছাড়া, এখনও স্বাগত হতে পারে এবং প্রায়ই সেটিই বেশি কার্যকর contribution। আবার code নিয়ে আসলে এমন একটি ছোট পরিবর্তন নিয়ে আসুন, যা আপনি প্রতিটি line ধরে ব্যাখ্যা ও সমর্থন করতে পারেন।