كيف تساهم بكود منشأ بواسطة الذكاء الاصطناعي في المشاريع؟

ما يجب فعله قبل إرسال كود مُنشأ بواسطة الذكاء الاصطناعي إلى المستودع الرئيسي

تنشر مشاريع المصادر المفتوحة الآن سياسات تتعلق بالكود المُنشأ بواسطة الذكاء الاصطناعي، وهذه السياسات غير متوافقة فيما بينها. لذا، القاعدة بسيطة: ابحث عن السياسة قبل كتابة التعديل (patch)، وأفصح عن مصدر الكود بدقة عند إرساله. هناك قاعدة واحدة تندرج تحت كلتا الحالتين: لا ترسل أبداً سطراً لا يمكنك شرحه أثناء المراجعة.

سيتم إغلاق التعديل الصحيح برمجياً إذا كان المشروع يحظر الكود المُنشأ آلياً، أو إذا أخفيت مصدر هذا الكود. يقع الضرر على سمعتك ويستمر، لأن المشرف الذي يكتشف هذا الإغفال لاحقاً لن يجد سبباً للثقة ببقية مساهماتك السابقة. لنبدأ ببعض المصطلحات، لأن السياسات تعتمد عليها. الـLLM (نموذج لغوي ضخم) هو النموذج الذي يعمل خلف مساعد البرمجة الخاص بك. الـPR (طلب سحب) على GitHub هو نفسه الـMR (طلب دمج) على GitLab، وكل ما يلي ينطبق على كليهما. الـDCO (شهادة منشأ المطور) هي سطر التوقيع في أسفل رسالة الالتزام (commit message)، وقد تبين أنها محور الجدل بأكمله.

إلى أين وصلت سياسات المصادر المفتوحة بشأن كود الذكاء الاصطناعي

استقرت المشاريع على أربع فئات. كل مثال أدناه مؤرخ، لأن هذه النصوص تتغير باستمرار.

الحظر. صوّت مجلس Gentoo في 14 أبريل 2024 على أنّه "يُمنع صراحةً المساهمة في Gentoo بأي محتوى تم إنشاؤه بمساعدة أدوات الذكاء الاصطناعي لمعالجة اللغات الطبيعية". تصف إرشادات الالتزام في NetBSD مخرجات نماذج اللغة الكبيرة (LLM) بأنها "كود ملوث" و"يجب عدم اعتماده دون موافقة خطية مسبقة من الفريق الأساسي". لا تزال وثيقة مصدر الكود في QEMU، اعتباراً من أغسطس 2026، تنص على أن المشروع "سيرفض أي مساهمات يُعتقد أنها تتضمن أو تشتق من محتوى تم إنشاؤه بواسطة الذكاء الاصطناعي".

التحليل فقط. معظم حالات الحظر أضيق مما توحي به العناوين. تنص وثيقة QEMU على أن السياسة "لا تنطبق على الاستخدامات الأخرى للذكاء الاصطناعي، مثل البحث في واجهات البرمجة (APIs) أو الخوارزميات، أو التحليل الساكن، أو تصحيح الأخطاء، بشرط عدم تضمين مخرجاتها في المساهمات". يمكنك استخدام الوكيل لقراءة الكود، لكن لا يمكنك شحن ما كتبه. هذا التمييز هو الخط الفاصل العملي داخل معظم المشاريع المقيدة، وهو ما يغفل عنه الكثيرون.

الإفصاح مطلوب. وافق مجلس Fedora على سياسة بشأن المساهمات المدعومة بالذكاء الاصطناعي في أكتوبر 2025. تسمح السياسة باستخدام الأدوات وتضع المسؤولية على عاتق الشخص: المساهم هو المؤلف، وهو المسؤول بالكامل عن المساهمة بأكملها، ويجب عليه الإفصاح عندما يكون جزء كبير منها قد جاء من أداة دون تعديلات. أضافت نواة Linux صفحة لمساعدي البرمجة في وثائق عملياتها في ديسمبر 2025، مع ملحق لتسجيل الأداة وقاعدة صارمة حول من يحق له التوقيع على الكود.

لا توجد سياسة مكتوبة. لا تزال هذه هي الحالة الشائعة. مسح بحثي أولي من مايو 2026 شمل 1,000 مستودع شهير على GitHub ووجد أن 118 منها فقط لديها سياسة مكتوبة بشأن الذكاء الاصطناعي. الصمت لا يعني الإذن. اسأل في نظام تتبع المشكلات بجملة واحدة قبل كتابة الرقعة البرمجية (patch)، وستصبح الإجابة سجلاً عاماً يمكنك الرجوع إليه لاحقاً.

لماذا وضع المشرفون هذه القواعد

السبب الأول هو عبء المراجعة، والحسابات تسير في اتجاه واحد. يُنتج الوكيل طلب دمج (merge request) مقنعاً بطول 400 سطر في دقيقة واحدة. مراجعة هذا الطلب بشكل صحيح تكلّف المشرف فترة بعد الظهر كاملة، ومعظم المشرفين متطوعون. تكلفة الإرسال انخفضت إلى ما يقرب من الصفر، بينما لم تتحرك تكلفة المراجعة على الإطلاق.

يُظهر مشروع curl الطرف الأقصى من هذا المنحنى. أفاد Daniel Stenberg في منتصف عام 2025 أن حوالي خُمس تقارير الأمان التي تصل عبر برنامج مكافآت الأخطاء (bug bounty) الخاص بالمشروع كانت ما يسميه "نفايات الذكاء الاصطناعي": تقارير تذكر دوال برمجية حقيقية ومسارات كود فعلية، وتصف هجوماً مقنعاً، لكنها لا تحتوي على أي شيء مفيد. أنهى المشروع برنامج المكافآت في أوائل عام 2026 بدلاً من الاستمرار في تمويل هذا الطوفان. كانت تلك تقارير وليست رقعاً برمجية (patches)، لكنها نفس الآلية التي تجعل المشرف يفتح طلب الدمج الخاص بك وهو يشعر بالإرهاق بالفعل.

دوّن مشروع GNOME Calendar المشكلة في شكل وسم (label). في يونيو 2026، أدخل المشروع وسم "Probabilistically Automated" لطلبات الدمج التي تُظهر "اعتماداً كلياً أو رئيسياً على 'الذكاء' الاصطناعي لتوليد الكود"، وحدد العرض بدقة: "عادة ما يكون مصحوباً بنقص في الاختبارات المناسبة، وإتمام الرقع البرمجية بناءً على السلوك النظري المقصود بدلاً من صحة الكود". اقرأ هذه العبارة الأخيرة مرتين. يبدو الكود كما لو كان يجب أن يعمل، لكن لم يتحقق أحد مما إذا كان يعمل فعلاً.

السبب الثاني هو المصدر (provenance)، أي من أين جاء الكود وتحت أي ترخيص. يوضح مشروع QEMU هذا التعارض ببساطة: التوقيع على الكود (signing off) يؤكد أنك "تفهم تماماً حالة حقوق النشر والترخيص للمحتوى" الذي تساهم به، وحالة حقوق النشر لمخرجات النماذج لا تزال غير محسومة. قدم مجلس Gentoo نفس السبب، إلى جانب الجودة والأخلاقيات. لست مضطراً للاتفاق مع التفسير القانوني، لكن عليك أن تدرك أن القرار يعود للمشرف، وليس لك.

كيف أعثر على سياسة الذكاء الاصطناعي الخاصة بمشروع ما؟

ابحث في هذه الأماكن، بهذا الترتيب:

• ملف CONTRIBUTING.md في المجلد الجذر للمستودع، ثم .github/CONTRIBUTING.md، ثم أي ملف DCO بجانبه.
• وثائق المطورين. يحتفظ مشروع QEMU بقواعده في docs/devel/code-provenance.rst. ويحتفظ النواة (kernel) بقواعده في Documentation/process/coding-assistants.rst.
• موقع المشروع أو الـwiki. تقع سياسة Gentoo في صفحة الـwiki الخاصة بالمجلس، بينما تقع سياسة NetBSD ضمن إرشادات الالتزام (commit guidelines).
• نظام تتبع المشكلات (issue tracker) وأرشيف القائمة البريدية. عادة ما توجد السياسة هناك لأشهر قبل أن يدوّنها أحد في المستودع.

من داخل نسخة العمل (checkout)، يغطي أمر grep واحد معظم هذه الأماكن:

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

بعد ذلك، اقرأ تاريخ المشروع نفسه، لأن العرف المعتمد في الالتزامات (commits) يتفوق على أي ملخص له:

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 بالشكل الذي يستخدمه هذا المشروع فعلياً. النتيجة الفارغة تعني أنه لم يفصح أحد بهذا الشكل هنا، وهي معلومة مفيدة أيضاً. إذا كان المشروع مستضافاً على GitHub وكان سير العمل جديداً عليك، فإن كيفية عمل طلبات السحب (pull requests) والـforks على GitHub تغطي الآليات التي يفترضها هذا القسم.

أفصح عن ذلك في تذييل الالتزام (commit trailer)، لا في تعليق

التذييل هو سطر Key: value في الفقرة الأخيرة من رسالة الالتزام. يستخدم Git هذا الشكل بالفعل لـ Signed-off-by: و Co-authored-by:، وتقوم الأدوات بتحليله، لذا فهو الإفصاح الوحيد الذي ينتقل مع الكود إلى شجرة المصدر.

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>

يوثق النواة هذا التنسيق كـ Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]، وهو صريح بشأن حدود هذا السطر: "يجب ألا تضيف وكلاء الذكاء الاصطناعي وسوم Signed-off-by. البشر فقط هم من يمكنهم قانوناً التصديق على شهادة منشأ المطور (DCO)". يوضع اسم الوكيل في Assisted-by. ويُوضع اسمك في Signed-off-by. لا تسمح أبداً لأداة بكتابة الاسم الثاني، ولا تسمح لها باختراع عنوان Co-authored-by لا يخص أحداً.

تختلف الأسماء، لذا انسخ الاسم المحلي بدلاً من اختراع اسم خاص بك. اقترح تصحيح (patch) نُشر في قائمة QEMU في مايو 2026 تخفيف حظر ذلك المشروع بالنسبة للتغييرات الآلية، والاختبارات، والوثائق، وإصلاحات الأخطاء التي تتكون من 20 سطراً أو أقل، مع تسجيل ذلك بتذييل مثل AI-used-for: tests, docs. اعتباراً من أغسطس 2026، لا يزال هذا مقترحاً في قائمة بريدية، ولا تزال الوثيقة المعتمدة ترفض المحتوى المُنشأ آلياً. غيّر أحد المشاريع موقفه مرتين بين عامي 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 لم يحلل التذييل، وغالباً ما يحدث هذا بسبب وجود سطر فارغ أو جملة عادية داخل كتلة التذييل في أسفل الرسالة. بالنسبة لسلسلة التزامات كتبتها بالفعل، يضيف git rebase --signoff origin/main التوقيع إلى كل التزام، ويقوم git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt بتعديل ملف الرسالة.

هناك نمطان من الفشل يستحقان التخطيط لهما. يؤدي دمج الـ squash إلى إعادة كتابة رسالة الالتزام، لذا في المشاريع التي تستخدم الـ squash، كرر الإفصاح في وصف طلب السحب (PR) حيث يقرأه المشرف. كما أن تعليق المراجعة ليس سجلاً، لأن التعليقات قابلة للتعديل ولا تصل أبداً إلى سجل git.

الدقة سلاح ذو حدين. إن وضع Assisted-by على التزام كتبته بيدك هو ضجيج، ويجعل إفصاحاتك الحقيقية أقل قيمة. أما تركه خارج التزام كتبه الوكيل فهو الأمر الذي ينهي العلاقة.

ما الذي يثبته فعلياً توقيع Signed-off-by؟

إن DCO عبارة عن نص قصير، الإصدار 1.1، منشور على developercertificate.org وتستخدمه النواة، وQEMU، والعديد من المشاريع الأخرى. إضافة Signed-off-by: Your Name <you@example.com> تعني أنك تصادق عليه. اقرأ ما تصادق عليه، لأن معظم الناس يوقعونه دون قراءته أبداً.

تنص الفقرة (أ) على أن المساهمة "تم إنشاؤها كلياً أو جزئياً من قبلي، وأنا أملك الحق في تقديمها بموجب ترخيص المصدر المفتوح المشار إليه في الملف". تغطي الفقرة (ب) العمل القائم على كود مفتوح المصدر سابق تملك الحق في تمريره مع إجراء تعديلات عليه. تغطي الفقرة (ج) الكود الذي سلمه لك شخص صادق على الشيء نفسه. تنص الفقرة (د) على أنك تدرك أن المساهمة والمعلومات الشخصية في توقيعك عامة ومحفوظة لأجل غير مسمى.

لاحظ ما هو مفقود. لا تنص DCO أبداً على أنك كتبت كل حرف بنفسك. بل تنص على أنك تملك الحق في تقديم الكود بموجب هذا الترخيص. لهذا السبب يبدو الكود المُنشأ آلياً في وضع محرج هنا: السؤال ليس عن التأليف، بل عما إذا كان بإمكانك إثبات المصدر. تتطلب معظم المشاريع التي تشترط التوقيع اسماً حقيقياً أيضاً، لذا فإن استخدام اسم مستعار يفشل في اجتياز الفحص. أضف السطر باستخدام git commit -s، الذي يقرأ user.name وuser.email من إعدادات git الخاصة بك. عندما يرفض بوت DCO طلب السحب (PR) الخاص بك ويحدد الالتزام (commit) الذي يفتقر إلى السطر، فإن git rebase --signoff origin/main متبوعاً بـ force push إلى فرعك يحل المشكلة.

توقيع الالتزام (Commit) ليس كالتوقيع عليه (Sign-off)

git commit -s يضيف سطراً من النص. أما git commit -S فينشئ توقيعاً مشفراً فوق كائن الالتزام باستخدام مفتاح GPG أو SSH الخاص بك. كلاهما يجيب على أسئلة مختلفة. التوقيع يثبت أن هذا الالتزام صدر عن صاحب ذلك المفتاح ولم يتم تعديله منذ ذلك الحين. وهو لا يذكر شيئاً عن مصدر الكود البرمجي الموجود بداخله، لذا فإن التزاماً موقعاً ومليئاً بكود مُوَلَّد غير مُفصح عنه يظل التزاماً موقعاً ولكنه لا يزال انتهاكاً للسياسة. التوقيع (Sign-off) هو إقرار بشأن المصدر، بينما التوقيع المشفر هو إقرار بشأن الهوية. المشاريع التي تتطلب كليهما ستطلب منك القيام بهما معاً.

لا ترسل أبداً شيفرة لا يمكنك شرحها أثناء المراجعة

هذا هو الاختبار، وهو لا يتعلق بالصدق في الحقيقة. بالنسبة لكل سطر: ما الغرض منه، وما الذي سيتعطل في حال غيابه؟ إذا كانت إحدى الإجابتين مفقودة، فإن التصحيح (patch) ليس جاهزاً، لأن تعليق المراجعة قادم وإجابتك ستكون جولة أخرى من التوليد. يستطيع المراجعون كشف ذلك. تلك هي اللحظة التي يتحول فيها المساهم إلى عبء. اطرح السؤال نفسه حول الحالات الطرفية، والمدخلات الفارغة، ومسار الفشل، والمستدعي الثاني.

شغّل الشيء. ابنِ المشروع، وشغّل مجموعة اختبارات المشروع، واكتب أداة إعادة إنتاج للخطأ الذي تدعي إصلاحه. تقدم وثائق النواة (kernel documentation) البديل الصادق بكلمات واضحة: "إذا تعذر بناء الإصلاح أو اختباره، أو إذا تعذر إنتاج أداة إعادة إنتاج، فاذكر ذلك صراحة: يهدر المشرفون حالياً الكثير من الوقت في تحليل التقارير غير المتحقق منها والإصلاحات غير المختبرة". كتابة "لم أتمكن من اختبار هذا على عتاد حقيقي" لا تكلفك شيئاً. أما الإيحاء بأنك فعلت ذلك فيكلفك مكانتك في المشروع.

أجب على تعليقات المراجعة بنفسك، بكلماتك الخاصة وفي وقتك الخاص. الرد الذي يصل بعد ثلاثين ثانية من التعليق ويعيد صياغته في خمس فقرات يخبر المشرف بالضبط بما حدث. حافظ على صغر حجم الـdiff أيضاً. أربعون سطراً تفهمها بالكامل تساوي للمشروع أكثر من إعادة هيكلة (refactor) من أربعمائة سطر أشرفت عليها. إذا استمر وكيلك في تقديم أكثر مما طلبت، فإن مهارة إلزامه بأصغر تغيير فعال هي إحدى الطرق للحفاظ على التصحيح في حدود ما يمكنك الدفاع عنه سطراً بسطر.

احتفظ بتعليمات الوكيل في المستودع

تُعد التعليمات التي تقدمها للوكيل جزءاً من سلسلة أدواتك، لذا تعامل معها كأنها شيفرة برمجية. يوجد ملف في المجلد الجذر للمستودع، وعادة ما يكون AGENTS.md، يحتوي على أمر البناء، وأمر الاختبار، وتنسيق رسالة الالتزام (commit message)، ومتطلبات التوقيع، وقواعد الأسلوب التي يوثقها المشروع بالفعل. هذا الملف يخضع للتحكم في الإصدار وقابل للمراجعة، ويظل ثابتاً لا يتغير بين اليوم والغد. إن إعادة كتابة التعليمات من الذاكرة في كل جلسة تؤدي إلى إنتاج رقعة (patch) مختلفة في كل مرة، ولن تعرف أي جلسة هي التي أنتجت الرقعة التي تم رفضها. يتناول كتابة ملف AGENTS.md يمكن لكل من الوكيل والبشر قراءته تفاصيل هذا الملف.

تحذير بخصوص مستودعات الآخرين: لا تجعل مساهمتك الأولى عبارة عن طلب سحب (PR) يضيف ملف تعليمات وكيل إلى مشروع لا تديره أنت. يُنظر إلى هذا التصرف كمحاولة لفرض سياسة الأدوات الخاصة بالمشروع من الخارج، وهو طريق سريع لجعل حسابك مرتبطاً بالأمور التي سئم منها مديرو المشروع بالفعل. احتفظ بالملف في نسختك المتفرعة (fork) حتى يطلبه شخص ما.

المكان الذي تشغّل فيه الوكيل مهم للسبب ذاته. فالوكيل الذي يمكنه بناء المشروع وتشغيل اختباراته داخل بيئة معزولة (sandbox) تتحكم فيها يمنحك رقعة برمجية تحققت منها فعلياً، وهذا هو الفرق بين الإفصاح عن المساعدة والإفصاح عن التخمين. يتناول تشغيل وكيل برمجي على خادم VPS خاص بك هذا الإعداد، بينما يغطي الفروقات العملية بين Claude Code وCursor وCodex وCopilot كيفية اختلاف هذه الأدوات في الاستخدام اليومي.

المنهجية، بمجرد تغير السياسة

1. ابحث عن السياسة المعلنة قبل كتابة أي شيء: المستودع، أو وثائق المطورين، أو الموقع الإلكتروني، أو نظام تتبع المشكلات.
2. إذا لم تكن هناك سياسة، اسأل في المشكلة بجملة واحدة، واحتفظ بالإجابة.
3. أفصح عن المعلومات بالصيغة التي يستخدمها المشروع، في تذييل الـcommit، وكرر ذلك في متن طلب السحب (PR) إذا كان المشروع يقوم بعملية دمج (squash) للالتزامات.
4. وقّع باسمك الحقيقي، مع إدراك أن هذا السطر يمثل إقراراً بحقك في تقديم الكود.
5. راجع رقعتك البرمجية (patch) كما لو أن شخصاً غريباً كتبها، لأن شخصاً غريباً قد فعل ذلك بالفعل.

كل مشروع مذكور في هذه الصفحة سيكون قد انتقل من مكانه بحلول الوقت الذي تقرأ فيه هذا. الخطوات الخمس لا تتغير.

FAQ

هل يجب عليّ الإفصاح عن استخدامي لوكيل برمجة يعمل بالذكاء الاصطناعي؟

تحقق من المشروع، لأن الإجابة تُحدَّد محلياً. تطلب Fedora الإفصاح عند مساهمة جزء كبير من العمل بواسطة أداة دون إجراء تعديلات عليه. يطلب نواة Linux إضافة Assisted-by. أما Gentoo وQEMU، فاعتباراً من أغسطس 2026، لا تقبلان هذه المساهمة إطلاقاً. في حال عدم وجود نص مكتوب، أفصح عن ذلك في commit trailer. فالمشرف الذي يكتشف الأمر لاحقاً سيتفاعل مع الإخفاء لا مع الأداة نفسها، وهذا التفاعل سيؤثر على كل ما أرسلته سابقاً.

ما هي مشاريع المصادر المفتوحة التي تحظر الكود الموَلَّد بالذكاء الاصطناعي؟

بناءً على نظرة عامة في أغسطس 2026: Gentoo منذ أبريل 2024، وNetBSD التي تعامل مخرجات النماذج اللغوية الكبيرة ككود ملوث يحتاج لموافقة جوهرية، وQEMU التي ترفض المساهمات المشتقة من محتوى موَلَّد، والعديد من تطبيقات GNOME بما فيها Loupe وCalendar. اقرأ النص الخاص بكل مشروع بدلاً من الاعتماد على هذه القائمة، لأنها ستتقادم. لاحظ الاستثناء الذي تشترك فيه معظمها: استخدام نموذج للبحث عن API، أو تشغيل تحليل ثابت، أو المساعدة في تصحيح الأخطاء (debug) هو أمر مقبول عادةً، طالما أن مخرجاته ليست جزءاً من الـpatch.

ما الفرق بين Signed-off-by والـcommit الموقَّع؟

Signed-off-by هو سطر نصي بسيط يُضاف بواسطة git commit -s. وهو يوثق شهادة منشأ المطور، مما يعني أن لديك الحق في تقديم هذا الكود تحت رخصة المشروع. أما الـcommit الموقَّع، الذي يتم باستخدام git commit -S، فهو توقيع تشفيري على كائن الـcommit باستخدام مفتاح GPG أو SSH الخاص بك. وهو يثبت أن الـcommit جاء من مفتاحك ولم يتم تعديله. المنشأ والهوية ادعاءان منفصلان، لذا يمكن للـcommit الموقَّع أن يظل مخالفاً لسياسة الذكاء الاصطناعي.

هل يمكنني وضع الإفصاح في وصف الـpull request بدلاً من رسالة الـcommit؟

ضعه في رسالة الـcommit، لأنها السجل الذي يستقر في تاريخ git وينتقل مع الكود إلى أي شخص يستنسخ (clone) المستودع لاحقاً. يمكن تعديل وصف الـpull request لاحقاً وهو يعيش على منصة الاستضافة فقط. أضفه إلى متن الـPR أيضاً في حال كان المشروع يستخدم squash merge، لأن الـsquash يعيد كتابة رسالة الـcommit الخاصة بك وقد يؤدي إلى حذف الـtrailer.

تم إغلاق الـpull request الخاص بي لأنه موَلَّد بالذكاء الاصطناعي. ماذا أفعل الآن؟

لا تجادل حول السياسة في سلسلة النقاش، لأن الشخص الذي أغلقه لم يضع القاعدة بمفرده، وسلسلة النقاش ليست المكان المناسب لتغييرها. اقرأ نص السياسة، ثم قرر ما إذا كان بإمكانك الالتزام بها. في المشاريع التي تحظر الـpatches الموَلَّدة، لا يزال تقرير الأخطاء الواضح مع وسيلة لإعادة إنتاج الخطأ (reproducer) دون إرفاق patch مرحباً به، وغالباً ما يكون مساهمة أكثر فائدة. إذا عدت بالكود، فعد بتغيير صغير يمكنك الدفاع عنه سطراً بسطر.