diff --git a/contributor_docs/ar/access.md b/contributor_docs/ar/access.md
new file mode 100644
index 0000000000..03921f3a0a
--- /dev/null
+++ b/contributor_docs/ar/access.md
@@ -0,0 +1,56 @@
+# تركيزنا على الإتاحة
+
+في [مؤتمر المساهمين لعام 2019](https://p5js.org/events/contributors-conference-2019)، التزمت مكتبة p5.js بعدم إضافة أي ميزات جديدة إلا إذا كانت تزيد من الإتاحة (بمعنى الشمولية وسهولة الوصول). لن نقبل طلبات الميزات التي لا تدعم هذه الجهود. نحن ملتزمون بالاعتراف بالعوائق وتفكيكها ومنعها. وهذا يشمل أخذ التجارب المتقاطعة[^1] للتنوع في الاعتبار، والتي قد تؤثر على الإتاحة والمشاركة. من بين هذه التجارب: الجندر، العرق، الإثنية، التوجه الجنسي، اللغة، الموقع الجغرافي، وغيرها. 
+نحن نضع احتياجات الفئات المهمشة في مقدمة الأولويات على حساب راحة الفئات ذات الامتيازات داخل مجتمع p5.js. نحن نستكشف بشكل جماعي معنى الإتاحة، ونتعلم كيفية ممارستها وتعليمها. نحن نختار أن ننظر إلى الإتاحة من خلال أطر واسعة ومتقاطعة وتحالفية. هذا الالتزام جزء من القيم الأساسية لمكتبة p5.js، كما هو موضح في [بيان المجتمع](https://p5js.org/about/#community-statement).
+
+## أنزاع الإتاحة
+
+إن زيادة الإتاحة لا تعني التركيز على زيادة العدد الإجمالي للأشخاص في مجتمع p5.js. بل هي التزام مستمر بجعل مكتبة p5.js متاحة وسهلة الوصول للأشخاص الذين تم استبعادهم من هذا المجتمع نتيجة للاضطهاد البنيوي. يمتد هذا الالتزام ليشمل الأدوات والمنصات التي تقدمها مكتبة p5.js، وكذلك تشكيل القيادة وعمليات اتخاذ القرار والإجراءات التي تتخذها قيادة p5.js. نحن نرفض ثقافة التكنولوجيا القائمة على السرعة والنمو والمنافسة. نحن نولي الأولوية للوعي، والتمهل، وتوفير التسهيلات، والمساءلة باعتبارها أفعالًا من الرعاية الجماعية.
+
+تعني الإتاحة هنا جعل p5.js عادلة ومنصفة لـ:
+
+- الأشخاص الذين يتحدثون لغات غير الإنجليزية  
+- الأشخاص السود، والسكان الأصليين، والأشخاص الملونين، والأشخاص من الأعراق المهمشة  
+- الأشخاص المثليين والمثليات ومزدوجي التوجه الجنسي والكوير وغير محددي الهوية الجنسية والبانسكسوال واللاجنسيين  
+- الأشخاص المتحولين جنسيًا، وأصحاب الهوية الجندرية غير الثابتة، واللاجندريين، والأشخاص ثنائيي الجنس، وأصحاب الهويات الجندرية المتنوعة، والنساء، وغيرهم من أصحاب الهويات الجندرية المهمشة  
+- الأشخاص المكفوفين، أو الصم (d/Deaf)[^2] أو ضعاف السمع، أو ذوي الإعاقة، أو ذوي التنوع العصبي، أو المصابين بأمراض مزمنة[^3] 
+- الأشخاص من ذوي الدخل المنخفض أو الذين يفتقرون إلى الموارد المالية أو الثقافية  
+- الأشخاص الذين لديهم خبرة قليلة أو معدومة في المصادر المفتوحة أو البرمجة الإبداعية  
+- الأشخاص من خلفيات تعليمية متنوعة  
+- الأشخاص من جميع الفئات العمرية، بما في ذلك الأطفال وكبار السن  
+- الأشخاص الذين يمتلكون مستويات متفاوتة من المهارات التقنية والأدوات وإمكانية الوصول للإنترنت  
+- الأشخاص من خلفيات دينية متنوعة  
+- أي أشخاص آخرين يتعرضون بشكل منهجي للإقصاء أو تم تمثيلهم تاريخيًا بشكل ناقص  
+- وجميع التقاطعات بين هذه الهويات
+
+نحن ندرك مدى تعقيد المصطلحات المستخدمة لوصف هوياتنا المختلفة. فاللغة متغيرة، دقيقة، وتخضع دائمًا للنقاش. هذه القائمة ليست شاملة أو نهائية، لكنها محاولة لتسمية التزاماتنا وتحمل المسؤولية تجاهها، وتجاه الاحتياجات المتنوعة لمجتمع p5.js.
+
+
+### أمثلة  
+فيما يلي أمثلة على الجهود التي نعتقد أنها تزيد من الإتاحة:
+
+- ترجمة الوثائق والمواد الأخرى إلى لغات أكثر، مع تقليل هيمنة اللغة الإنجليزية[^4] (على سبيل المثال: مشروع رولاندو فارغاس [برمجة بلغة كونا](https://medium.com/@ProcessingOrg/culture-as-translation-processing-in-kuna-language-with-rolando-vargas-and-edinson-izquierdo-8079f14851f7)، ومشروع فيليبي سانتوس غوميز وجوليا برازيل وكاثرين فين زاندر ومارسيا مانسينو [Pê Cinco: الترجمة والترويج للناطقين بالبرتغالية](https://medium.com/processing-foundation/translating-p5-js-into-portuguese-for-the-brazilian-community-14b969e77ab1))  
+- تحسين دعمنا للتقنيات المساعدة، مثل برامج قراءة الشاشة (على سبيل المثال: مشروع كايتي ليو [إضافة نص بديل في p5.js](https://medium.com/processing-foundation/adding-alt-text-e2c7684e44f8)، ومشروع كلير كيرني-فولب [مشروع إتاحة p5](https://medium.com/processing-foundation/p5-accessibility-115d84535fa8))  
+- اتباع [إرشادات إمكانية الوصول لمحتوى الويب (WCAG)](https://www.w3.org/TR/WCAG21/) في أدواتنا، والعمل على تسهيل اتباعها من قِبل المستخدمين في مشاريعهم  
+- جعل رسائل الأخطاء في مكتبة p5.js أكثر وضوحًا ودعمًا للأشخاص الذين يستخدمون الأداة (على سبيل المثال: [نظام الأخطاء الودية في p5.js (FES)](./friendly_error_system.md))  
+- الإرشاد ودعم متعلمي p5.js داخل المجتمعات التي تم استبعادها تاريخيًا وتهميشها في مجالات البرمجة الإبداعية والفنون الرقمية  
+- استضافة فعاليات مجتمعية (على سبيل المثال: [يوم إتاحة p5.js لعام 2022](https://p5js.org/events/p5js-access-day-2022)، وفعالية [الويب الذي نريده: p5.js x W3C TPAC 2020](https://medium.com/processing-foundation/p5-js-x-w3c-tpac-bee4c621a053)) باستخدام أساليب تنظيمية تركز على الإتاحة (مثل: توفير مترجم لغة الإشارة الأمريكية ASL، والتعليقات المباشرة، واختيار أماكن ميسّرة للجميع)  
+- دعم إنشاء موارد تعليمية (على سبيل المثال: منهج أديكيمي سيجواد-أوكاديكي [A11y Syllabus](http://a11ysyllabus.site/))  
+- نشر وثائق وتقارير عن عملنا تتبع إرشادات WCAG، وتستخدم لغة بسيطة، وتركز على المبتدئين من خلفيات متنوعة (على سبيل المثال: [تقرير إتاحة p5.js من OSACC](https://github.com/processing/OSACC-p5.js-Access-Report))
+
+
+## إدارة المشروع وإستمرارية العمل عليه
+نحن لا نقبل طلبات الميزات الجديدة التي لا تدعم جهودنا في زيادة الإتاحة. ستجدون هذا المعيار منعكسًا في الـIssues والـPull Requests لدينا. كما نؤكد التزامنا بالحفاظ على مجموعة الميزات الحالية في مكتبة p5.js. نرغب في إصلاح الأخطاء بغض النظر عن الجزء الذي توجد فيه داخل قاعدة الكود. نحن نؤمن بأن الحفاظ على استمرارية الأداة يجعلها أكثر سهولةً للمبتدئين.
+
+___
+
+يرجى اعتبار هذا المستند "مستندًا حيًا" قابلًا للتحديث المستمر. سنواصل النقاش حول معنى إعطاء الأولوية للإتاحة، وندعو مجتمعنا للمشاركة والتفاعل مع هذا المستند والقيم التي يصفها. إذا كانت لديك أفكار أو اقتراحات، ندعوك لمشاركتها عبر فتح Issue على GitHub أو عبر إرسال بريد إلكتروني إلى: hello@p5js.org.
+
+تمت مراجعة هذه النسخة من بيان الإتاحة الخاص بـ p5.js بالتعاون مع: إيفلين ماسو، نات ديكر، بوبي جو سميث الثالث، سامي فيلر، سونيا (سوه يون) تشوي، شين شين، كيت هولينباخ، لورين لي مكارثي، كارولين سيندرز، تشيان تشيان يي، تريستان جوفاني ماغنو إسبينوزا، تانفي شارما، تسيجي تافيسي، وسارة سيستون، وذلك خلال مؤتمر مساهمي الفنون مفتوحة المصدر 2023.
+
+تمت صياغته النهائية ونشره بواسطة بوبي جو سميث الثالث ونات ديكر بدعم من برنامج زمالة مؤسسة Processing.
+
+[^1]: كرينشو، كيمبرلي (1989). "إزالة التهميش عند تقاطع العرق والجنس: نقد نسوي أسود لعقيدة مكافحة التمييز، والنظرية النسوية، والسياسات المناهضة للعنصرية". منتدى القانون بجامعة شيكاغو. 1989 (1): 139–167. الرقم الدولي المعياري للدوريات: ISSN 0892-5593. النص الكامل متاح على Archive.org.
+[^2]: الحرف الكبير "D" في كلمة Deaf يشير إلى الأشخاص الذين ينتمون ثقافيًا إلى مجتمع الصم ويعتبرون جزءًا منه، بينما الحرف الصغير "d" في كلمة deaf فهو مصطلح سمعي يصف الأشخاص الذين يعانون من ضعف السمع لكنهم ليسوا بالضرورة مرتبطين بهوية ثقافية خاصة بمجتمع الصم.
+[^3]: توجد تفضيلات متباينة داخل مجتمع ذوي الإحتياجيات الخاصة فيما يتعلق باستخدام اللغة التي تُقدِّم الشخص أولًا (*person-first language*) مقارنةً باللغة التي تُقدِّم الهوية أولًا (*identity-first language*). يمكن الاطلاع على المزيد حول هذا النقاش في المقال: [تفكيك الجدل حول اللغة التي تُقدِّم الشخص أولًا مقابل الهوية أولًا داخل مجتمع التوحد](https://news.northeastern.edu/2018/07/12/unpacking-the-debate-over-person-first-vs-identity-first-language-in-the-autism-community/)، بالإضافة إلى مقال [لغة تعزيز الإعاقة: اللغة التي تُقدِّم الشخص أولًا مقابل اللغة التي تُقدِّم الهوية أولًا](https://editorstorontoblog.com/2024/02/23/disability-affirming-language-person-first-versus-identity-first-language/)، وأيضًا [مسرد اللغة التي تُقدِّم الشخص أولًا واللغة التي تُقدِّم الهوية أولًا](https://ogs.ny.gov/system/files/documents/2024/02/person-first-and-identity-first-glossary_english_final.pdf)، الذي يوضح المزيد من المصطلحات ذات الصلة.
+[^4]: يشير مفهوم "الهيمنة اللغوية" أو "الإمبريالية اللغوية" إلى السيطرة المستمرة أو أولوية أو فرض لغات معينة مثل الإنجليزية على حساب اللغات الأصلية، وذلك نتيجة للتوسع الإمبريالي والعولمة.
diff --git a/contributor_docs/ar/contributor_guidelines.md b/contributor_docs/ar/contributor_guidelines.md
new file mode 100644
index 0000000000..2fecb467bb
--- /dev/null
+++ b/contributor_docs/ar/contributor_guidelines.md
@@ -0,0 +1,616 @@
+
+# إرشادات المساهمة
+
+مرحبًا بك في إرشادات المساهمة! هذا المستند موجه للمساهمين الجدد الذين يرغبون في المساهمة في كود p5.js، وللمساهمين الذين يريدون تذكير أنفسهم ببعض الخطوات التقنية، أو لأي شيء آخر متعلق بالمساهمات البرمجية في p5.js.
+
+إذا كنت ترغب في المساهمة خارج ريبوز p5.js (مثل كتابة دروس، تخطيط حصص، أو تنظيم فعاليات)، يُرجى الاطلاع على الصفحات ذات الصلة بدلًا من ذلك. المشرفون أو Maintainers قد يجدون [إرشادات المشرفين](./steward_guidelines.md) أكثر فائدة فيما يتعلق بمراجعة الـIssues والـPull Requests.
+
+هذا مستند طويل وشامل نسبيًا، لكننا سنحاول توضيح كل خطوة وكل نقطة بشكل واضح قدر الإمكان. يُرجى استخدام جدول المحتويات للوصول إلى الأقسام ذات الصلة بك. لا تتردد في تخطي الأقسام التي لا تهمك أو ليست متعلقة بالمساهمات التي تخطط لها.
+
+**إذا كنت مساهمًا جديدًا، قد ترغب في بدء القراءة من القسم الأول "كل شيء عن الـIssues". وإذا كنت تريد خطوات سريعة لإعداد بيئة التطوير، يمكنك الانتقال إلى قسم "البدء السريع للمطورين".**
+
+
+
+
+# جدول المحتويات
+
+- [كل شيء عن الـIssues](#كل-شيء-عن-الـIssues)
+  - [ما هي الـIssues؟](#ما-هي-الـIssues)
+  - [قوالب الـIssues](#قوالب-الـIssues)
+    - [اكتشفت Bug](#اكتشفت-Bug)
+    - [تحسين ميزة موجودة](#تحسين-ميزة-موجودة)
+    - [طلب ميزة جديدة](#طلب-ميزة-جديدة)
+    - [نقاش](#نقاش)
+- [العمل على الكود الأساسي الخاص بـ p5.js](#العمل-على-الكود-الأساسي-الخاص-بـ-p5js)
+  - [المتطلبات الأساسية](https://github.com/islml/p5.js/blob/Arabic-translations-for-contributor_docs/contributor_docs/ar/contributor_guidelines.md#المتطلبات-الأساسية)
+  - [المقدمة](https://github.com/islml/p5.js/blob/Arabic-translations-for-contributor_docs/contributor_docs/ar/contributor_guidelines.md#المقدمة)
+  - [البدء السريع للمطورين](#البدء-السريع-للمطورين)
+  - [استخدام ميزة التعديل المباشر في Github](#استخدام-ميزة-التعديل-المباشر-في-Github)
+  - [عمل Fork للريبو الأساسية](عمل-fork-للريبو-الأساسية)
+    - [استخدام Github Desktop](#استخدام-Github-Desktop)
+    - [استخدام واجهة أوامر git](#استخدام-واجهة-أوامر-git)
+  - [نظرة عامة على بنية المشروع](#نظرة-عامة-على-بنية-المشروع)
+  - [إعداد بيئة العمل Build Setup](#إعداد-بيئة-العمل-Build-Setup)
+  - [سير العمل مع Git](#سير-العمل-مع-Git)
+    - [كود المصدر](#كود-المصدر)
+    - [الـUnit testsg](#الـUnit-tests)
+    - [التوثيق المضمن Inline Documentation](#التوثيق-المضمن-Inline-Documentation)
+    - [إتاحة الوصول Accessibility](#إتاحة-الوصول-Accessibility)
+  - [معايير كتابة الكود](#معايير-كتابة-الكود)
+  - [مبادئ تصميم البرمجيات](#مبادئ-تصميم-البرمجيات)
+- [الـPull Requests](#الـPull-Requests)
+  - [إنشاء الـPull Request](#إنشاء-الـPull-Request)
+    - [معلومات الـPull Request](#معلومات-الـPull-Request)
+    - [العنوان Title](#العنوان-Title)
+    - [خانة Resolves](#خانة-Resolves)
+    - [التغييرات](#التغييرات)
+    - [لقطات الشاشة للتغيير](#لقطات-الشاشة-للتغيير)
+    - [قائمة التحقق للـPR](#قائمة-التحقق-للـPR)
+    - [إعادة الترتيب وحل التعارضات Rebase and resolve conflicts](#إعادة-الترتيب-وحل-التعارضات-Rebase-and-resolve-conflicts)
+  - [النقاش والتعديل](#النقاش-والتعديل)
+
+---
+
+
+# كل شيء عن الـIssues
+
+معظم الأنشطة في ريبو p5.js على GitHub تحدث في الـIssues، وهي مكان رائع لبدء رحلتك في المساهمة.
+
+
+## ما هي الـIssues؟
+
+![لقطة شاشة مقصوصة من ريبو مكتبة p5.js على GitHub، تُظهر فقط الزاوية العلوية اليمنى. مربع أحمر مُضاف على الصورة يُحيط بعلامة تبويب الـIssues.](../images/issues-tab.png)
+
+الـIssue هي الاسم العامي لمنشور على GitHub يهدف إلى وصف، كما هو واضح من الاسم، مشكلة. يمكن أن تكون الـIssue تقريرًا عن bug، أو طلبًا لإضافة ميزة جديدة، أو نقاشًا، أو أي شيء يعمل كمنشور مرتبط بتطوير مكتبة p5.js. يمكن لأي شخص يمتلك حسابًا على GitHub إضافة تعليقات أسفل كل Issue، بما في ذلك البوتات! هذا هو المكان الذي يناقش فيه المساهمون المواضيع المتعلقة بتطوير المشروع داخل الريبو.
+
+على الرغم من أنه يمكن فتح Issue لأسباب متنوعة، إلا أننا عادةً ما نستخدم الـIssues فقط لمناقشة تطوير الكود المصدري الخاصة بـp5.js. أما المواضيع مثل تصحيح الأخطاء (debugging) في كودك الخاصة، أو دعوة متعاونين لمشروعك، أو أي مواضيع غير ذات صلة، فمن الأفضل مناقشتها إما في [المنتدى](https://discourse.processing.com) أو على منصات أخرى مثل [Discord](https://discord.gg/SHQ8dH25r9).
+
+لقد أنشأنا قوالب Issues سهلة الاستخدام لمساعدتك في تحديد ما إذا كان الموضوع الذي تريد طرحه مناسبًا كـIssue على GitHub أم أنه من الأفضل نشره في مكان آخر!
+
+
+
+## قوالب الـIssues
+
+تُسهِّل قوالب الـIssues في مكتبة p5.js على المشرفين (Stewards) والمسؤولين (Maintainers) فهم الـIssues ومراجعتها. كما أنها تجعل من الأسهل عليك تقديم الـIssue المناسبة والحصول على رد أسرع.
+
+![لقطة شاشة لمثال على شكل Issue على GitHub. عنوان الـIssue في الصورة هو "Warning being logged in Safari when using a filter shader in 2D mode #6597"](../images/github-issue.png)
+
+لتقديم Issue جديدة، ما عليك سوى التوجه إلى تبويب "الـIssues" في ريبو p5.js، ثم النقر على زر "New issue" الموجود على الجهة اليمنى. ستظهر لك مجموعة من الخيارات المختلفة، وكل خيار إما مرتبط بقالب Issue معين أو يُوجِّهك إلى المكان المناسب لطرح سؤالك. نوصي باختيار الخيار الأكثر صلة بمشكلتك لضمان حصول الـIssue الخاصة بك على الاهتمام المناسب في الوقت المناسب.
+
+![لقطة شاشة مقصوصة لصفحة الـIssues في مستودع GitHub مع تمييز زر "New issue" الأخضر داخل إطار أحمر.](../images/new-issue.png)
+
+
+## ["اكتشفت Bug"](https://github.com/processing/p5.js/issues/new?assignees=\&labels=Bug\&projects=\&template=found-a-bug.yml)
+
+عندما تواجه سلوكًا غير صحيح محتمل في p5.js أو شيئًا لا يعمل كما هو موصوف في التوثيق، استخدم [هذا القالب](https://github.com/processing/p5.js/issues/new?assignees=\&labels=Bug\&projects=\&template=found-a-bug.yml). يرجى الانتباه أنه إذا كنت تحاول تصحيح شيفرتك وتعتقد أن المشكلة قد تكون بسبب الكود الخاص بك، فمن الأفضل أن تسأل أولًا في [منتدى Discourse](https://discourse.processing.org).
+
+هناك بعض الحقول التي تحتاج إلى تعبئتها في هذا القالب:
+
+1. **أكثر جزء مناسب من مكتبة p5.js؟** - يساعدنا هذا في تحديد القسم المسؤول عن المشكلة، مما يسمح بإضافة الوسوم المناسبة تلقائيًا إلى الـIssue.
+2. **إصدار p5.js** - يمكنك العثور على رقم إصدار p5.js إما في وسم `<script>` أو في السطر الأول من ملف `p5.js` أو `p5.min.js`. سيبدو الرقم تقريبًا بهذا الشكل: `1.4.2` (ثلاثة أرقام مفصولة بنقاط).
+3. **متصفح الويب والإصدار** - هذا يساعدنا في تحديد ما إذا كانت المشكلة خاصة بمتصفح معين. يمكنك العثور على رقم إصدار المتصفح باتباع التعليمات في الجدول أدناه:
+
+<table>
+<tr>
+<td>Chrome</td>
+<td>Firefox</td>
+<td>Safari</td>
+</tr>
+<tr>
+<td>في شريط العنوان، اكتب: <br>`chrome://version`</td>
+<td>في شريط العنوان، اكتب: <br>`about:support`</td>
+<td>من قائمة "Safari" في الشريط العلوي، اختر "About Safari"</td>
+</tr>
+</table>
+
+4. **نظام التشغيل** - يُفضَّل تضمين رقم إصدار نظام التشغيل أيضًا، مثل: `macOS 12.5`، لأن بعض الـBugs تكون متعلقة بتصرفات النظام نفسه.
+5. **خطوات إعادة إنتاج المشكلة** - هذا هو واحد من أهم الخانات. يُفضل كتابة خطوات واضحة ومفصلة لتوضيح كيفية تكرار الـBug الذي تواجهه. مشاركة كود بسيط يُظهر المشكلة سيساعد جدًا في فهم المشكلة والبدء في العمل على حلها.
+
+**إمكانية إعادة إنتاج الـBug أمر أساسي!** معظم الخانات في هذا القالب موجهة لتسهيل إعادة إنتاج المشكلة. كلما زودتنا بمعلومات دقيقة حول بيئة عمل الكود الخاص بك، وكيف يمكن للآخرين إعادة إنتاج المشكلة، كلما كان من الأسهل فهم المشكلة والعمل على حلها.
+
+**كن دقيقًا قدر الإمكان وتجنب العبارات العامة**. على سبيل المثال، لا تقل "دالة `image()` لا تعمل"، بل كن أكثر تحديدًا مثل "دالة `image()` لا تعرض صورة GIF بالحجم الصحيح". من الطرق المفيدة لوصف الـBug أن تذكر نقطتين:
+
+1. ما الذي تتوقع أن يفعله الكود الذي أرفقته (السلوك المتوقع).
+2. ما الذي يفعله الكود فعليًا (السلوك الفعلي).
+
+إذا كنت ترغب في المساهمة بحل للـBug الذي أبلغت عنه، يمكنك الإشارة إلى ذلك في الوصف. كما يمكنك تقديم اقتراح بسيط لكيفية إصلاح المشكلة. هذا سيساعدنا في فهم مقدار الدعم الذي قد تحتاجه أثناء العمل على الحل.
+
+**لا يجب أن تفتح Pull Request (أو تبدأ في تعديل الكود) قبل وجود Issue مقابلة لها أو قبل الموافقة عليها للتنفيذ.** لأن الحل المقترح قد لا يكون مقبولًا، أو قد يحتاج إلى نهج مختلف تمامًا، أو قد تكون المشكلة الفعلية في مكان آخر. أي Pull Request يتم تقديمها قبل الموافقة على الـIssue ستُغلق لحين الموافقة على الـIssue ذاتها.
+
+حتى يتم قبول تقارير الـBugs والعمل عليها، يجب أن تحصل على موافقة من قبل **أحد المشرفين أو المسؤولين على الأقل** قبل البدء في أي Pull Request.
+
+
+## ["تحسين ميزة موجودة"](https://github.com/processing/p5.js/issues/new?assignees=\&labels=Enhancement\&projects=\&template=existing-feature-enhancement.yml)
+
+ينبغي استخدام هذا القالب إذا رغبت في اقتراح تغييرات أو إضافة وظائف جديدة إلى ميزات موجودة في مكتبة p5.js (مثل الدوال أو الثوابت أو عمليات الرسم أو غيرها). على سبيل المثال، إذا أردت إضافة طريقة جديدة لتحديد اللون في الدالة `color()` والدوال الأخرى التي تقبل الألوان، فهذا هو القالب المناسب للاستخدام.
+
+هناك عدة خانات في هذا القالب ينبغي تعبئتها:
+
+1. *تعزيز الإتاحة* - هذه خانة إلزامية، حيث تقوم فيها بإدخال بيان يوضح كيف ستساهم الميزة المقترحة في [تعزيز الإتاحة](./access.md) للأشخاص الذين تعرضوا تاريخيًا للتهميش في مجال الفنون الإبداعية أو التكنولوجيا. **لن يتم قبول أي اقتراحات بدون هذه الخانة**، ولكن يمكنك إدخال "لست متأكدًا" مع دعوة بقية أفراد المجتمع للمساعدة في تقديم هذا البيان إذا تمكنوا من ربط الميزة بتحسين الوصول في p5.js.
+2. *الجزء الأنسب من مكتبة p5.js؟* - هذه الخانة تساعدنا على تحديد المجال المناسب للـIssue والتفاعل معها بشكل أسرع. كما سيتم تلقائيًا إضافة الوسوم المناسبة من [قائمة الوسوم](https://github.com/processing/p5.js/labels).
+3. *تفاصيل تحسين الميزة* - هذه الخانة مخصصة لوصف اقتراحك بالتفصيل. الاقتراح الجيد لتحسين ميزة يتضمن عادةً حالة استخدام واضحة: ماذا تريد؟ متى؟ كيف؟ ولماذا هذا التحسين ضروري؟
+
+حتى يتم قبول اقتراحات تحسين الميزات، يجب أن تحصل على موافقة من *على الأقل* [مشرف أو Maintainer مختص بالمجال](https://github.com/processing/p5.js#stewards) قبل البدء في العمل على الـPull Request.
+
+**لا يجب إنشاء Pull Request (أو البدء في أي تغييرات برمجية) بدون وجود Issue مقابلة أو قبل حصول الـIssue على الموافقة للتنفيذ**، لأنه لا يوجد ضمان لقبول الاقتراح. سيتم إغلاق أي Pull Requests يتم تقديمها قبل الموافقة على الـIssue حتى يتم منح الموافقة رسميًا.
+
+
+### ["طلب ميزة جديدة"](https://github.com/processing/p5.js/issues/new?assignees=\&labels=Feature+Request\&projects=\&template=feature-request.yml)
+
+ينبغي استخدام هذا القالب إذا أردت اقتراح إضافة ميزة جديدة إلى مكتبة p5.js. على سبيل المثال، إذا أردت إضافة دعم لرسم عناصر HTML الأصلية مثل `<table>` عبر دالة جديدة باسم `createTable`. بعض الاقتراحات قد تتداخل مع اقتراحات تحسين الميزات الموجودة، وفي هذه الحالات يمكنك اختيار القالب الذي تشعر أنه الأنسب.
+
+وبناءً على ذلك، فإن خانات النموذج في هذا القالب مشابهة تقريبًا لخانات قالب "تحسين ميزة موجودة". لذلك يمكنك الرجوع إلى [القسم السابق](#تحسين-ميزة-موجودة) للحصول على تفاصيل حول كيفية تعبئة كل خانة.
+
+حتى يتم قبول اقتراحات الميزات الجديدة، يجب أن تحصل على موافقة *على الأقل* من 2 من [المشرفين أو الـMaintainers المختصين بالمجال](https://github.com/processing/p5.js#stewards) قبل البدء في العمل على الـPull Request.
+
+**لا يجب إنشاء Pull Request (أو البدء في أي تغييرات برمجية) بدون وجود Issue مقابلة أو قبل حصول الـIssue على الموافقة للتنفيذ**، لأن الاقتراح قد لا يتم قبوله. سيتم إغلاق أي Pull Requests يتم تقديمها قبل الموافقة على الـIssue حتى يتم منح الموافقة رسميًا.
+
+
+### ["نقاش"](https://github.com/processing/p5.js/issues/new?assignees=\&labels=Discussion\&projects=\&template=discussion.yml)
+
+يُستخدم هذا القالب عندما لا تناسب الIssue التي تريد طرحها أيًا من القوالب المذكورة أعلاه بأي شكل من الأشكال. يجب أن يكون هذا السيناريو نادر الحدوث عمليًا. على سبيل المثال، النقاش حول اعتماد ميزة معينة من واجهة برمجية Web API في مكتبة p5.js يجب أن يُطرح كـ[طلب ميزة جديدة](#طلب-ميزة-جديدة)؛ والنقاش حول إضافة نمط ألوان إضافي إلى الدوال الخاصة بالألوان يجب أن يُطرح كـ[تحسين ميزة موجودة](#تحسين-ميزة-موجودة)؛ أما إعلان عن فعالية محلية حول البرمجة الإبداعية تنظمها، فيجب نشره في المنتدى مع التواصل مع مؤسسة Processing إذا كنت ترغب بالحصول على دعم أو ترويج؛ وهكذا.
+
+عند فتح Issue من نوع "نقاش"، يمكنك استخدام لوحة "Labels" في الجهة الجانبية لإضافة التسميات المناسبة التي تساعد على توجيه الـIssue إلى المجال المناسب. القالب نفسه يحتوي فقط على خانة نصية أساسية. يمكنك الاطلاع على [هذا الرابط](https://github.com/processing/p5.js/issues/6517) كمثال على Issue من نوع "نقاش".
+
+[**⬆ العودة إلى الأعلى**](#إرشادات-المساهمة)
+
+---
+
+
+# العمل على الكود الأساسي الخاص بـ p5.js
+
+## المتطلبات الأساسية
+
+حتى تتمكن من المتابعة، يُفضَّل أن تكون لديك خبرة أساسية في العمل على سطر الأوامر، واستخدام `git`، ومعرفة بـ `node.js` (الإصدار 18 أو أحدث)، بالإضافة إلى إعداد بيئة تطوير محلية على جهازك.
+
+
+## المقدمة
+
+الآن بعد أن تمت مناقشة الـIssue والموافقة على التنفيذ، وأصبحت مستعدًا لإجراء التعديلات البرمجية، يمكنك البدء في العمل على الكود الأساسي للمكتبة.
+
+كذلك، إذا وجدت Issue أو شاركت في نقاش حوله وتمت الموافقة على التنفيذ من قبل الـStewards، ولكن لم يُبدِ كاتب الـIssue الأصلي أو أي من أعضاء المجتمع رغبة في العمل عليه، يمكنك التطوع لتقديم المساهمة هنا وسيتم تعيين الـIssue لك من قبل الـStewards.
+
+**يُرجى عدم تجاوز الأولوية** من خلال تقديم Pull Request لـIssue قام شخص آخر بالفعل بإبداء رغبته في العمل عليه أو تم تعيينه له بالفعل. نحن دائمًا نعتمد مبدأ "الأولوية لمن حصل على التعيين أولًا" عند قبول المساهمات البرمجية لأي Issue.
+
+إذا قمت بتقديم Pull Request لـIssue بينما شخص آخر لا يزال يعمل عليه، فسيتم إغلاق الـPull Request الخاص بك. وإذا لاحظت أن النشاط على الـIssue المعين لشخص آخر قد توقف لبضعة أشهر، يمكنك ترك تعليق مهذّب على الـIssue للاستفسار عن التقدم أو عرض المساعدة في التنفيذ. بشكل عام، نحن نسمح بفترات زمنية طويلة ومعقولة للأشخاص للعمل على مساهماتهم، نظرًا لأن معظم المشاركين يعملون بشكل تطوعي، أو لأن تنفيذ الميزة يحتاج لوقت أطول.
+
+وبنفس الطريقة، يمكنك العمل وفقًا للوتيرتك الخاصة، ولا يوجد حد زمني صارم يلزمك بالانتهاء من المساهمة خلاله. مع ذلك، إذا واجهتك أي صعوبة في أي جزء من مساهمتك البرمجية، فلا تتردد في طلب المساعدة من خلال كتابة تعليق على الـIssue. الـStewards والمشرفون، بالإضافة إلى أعضاء المجتمع، سيبذلون قصارى جهدهم لإرشادك ودعمك!
+
+
+ترجمة الفقرة إلى **العربية الفصحى** (مع مراعاة التفضيلات اللي قلتها سابقًا):
+
+---
+
+## البدء السريع للمطورين
+
+إذا كنت ترغب في العمل أو المساهمة في الكود المصدري الخاص بمكتبة p5.js🌸 كمطور، سواءً لتحسين p5.js نفسها أو لتحسين المشاريع الفرعية التابعة لها مثل [نظام الأخطاء الودية (Friendly Error Systems)](./friendly_error_system.md)، يمكنك اتباع الخطوات التالية:
+
+1. [قم بإنشاء Fork (نسخة متفرعة) من ريبو p5.js.](https://docs.github.com/en/get-started/quickstart/fork-a-repo)
+2. [قم باستنساخ (Clone) النسخة المتفرعة إلى جهازك.](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository)
+3. أضِف الـupstream باستخدام الأمر التالي:  
+
+    ```
+    git remote add upstream https://github.com/processing/p5.js
+    ```
+
+4. تأكد أن جهازك يحتوي على [NodeJs](https://nodejs.org/en/download) عبر التحقق بالأمر التالي:
+
+    ```
+    node -v
+    ```
+
+5. قم بتثبيت الاعتمادات (Dependencies) عبر الأمر:
+
+    ```
+    npm ci
+    ```
+
+6. أنشئ فرعًا جديدًا من الفرع `main` واختر له اسمًا وصفيًا باستخدام:
+
+    ```
+    git checkout -b [branch_name]
+    ```
+
+7. أثناء إجراء التعديلات على الكود المصدري، احرص على تشغيل الاختبارات بشكل متكرر (رغم أنها تستغرق وقتًا، لكنها تضمن عدم كسر السلوكيات الحالية).
+
+
+
+    ```
+    npm test
+    ```
+
+8. أضِف أي اختبارات وحدة (Unit Tests) إذا كنت تعمل على إضافة ميزات جديدة أو تحسين ميزات حالية.
+9. بعد الانتهاء، يمكنك رفع التعديلات (Commit) وإنشاء [Pull Request](#الPull-Requests).
+
+
+## استخدام ميزة التعديل المباشر في GitHub
+
+عند عرض أي ملف عبر واجهة GitHub على الويب، ستجد بالقرب من أعلى محتوى الملف أيقونة قلم (✏️). هذه الأيقونة تتيح ميزة تحرير مريحة يوفرها GitHub، وهي تُبسط الكثير من العمليات التي سنغطيها لاحقًا، ويمكن استخدامها لإجراء تعديلات سريعة وبسيطة على الملف الذي تقوم بعرضه.
+
+![لقطة شاشة مقصوصة لعرض ملف في GitHub من ريبو p5.js، وتحديدًا ملف "src/color/color_conversion.js". يوجد سهم أحمر يشير إلى أيقونة القلم على الجانب الأيمن من الصورة.](../images/edit-file.png)
+
+ولكن، لا يُوصى باستخدام هذه الميزة إلا للتعديلات البسيطة جدًا. أحد الأسباب الرئيسية لذلك هو أنه في حالة التعديلات المعقدة على الكود المصدري، ينبغي بناء المشروع محليًا وتشغيل الاختبارات قبل تقديم الـPull Request. كذلك، فإن العمل من بيئة تطوير محلية يكون عادةً أكثر مرونة مقارنةً ببيئة التحرير البسيطة التي توفرها هذه الميزة.
+
+
+## عمل Fork للريبو االأساسية
+
+أول خطوة للعمل على الكود المصدري لـp5.js هي عمل Fork (نسخة متفرعة) من ريبو p5.js. مصطلح "Fork" له معنى محدد في عالم البرمجيات مفتوحة المصدر، لكن في حالتنا، يعني إنشاء نسخة من الريبو وحفظها في حسابك على GitHub. لعمل Fork، ببساطة اضغط على زر "Fork" الموجود بالقرب من أعلى الصفحة، وسيقوم GitHub بإنشاء نسخة من الريبو في حسابك.
+
+![لقطة شاشة لصفحة الريبو الرئيسية. يوجد زر عليه أيقونة Fork ومعه النص "Fork 59.3k"، ومحدد بإطار برتقالي غامق.](../images/fork.png)
+
+العمل من النسخة المتفرعة (Fork) الخاصة بك من ريبو p5.js أمر ضروري لأنك على الأرجح لن تمتلك صلاحية الكتابة المباشرة على الريبو الرسمي لـp5.js. ومن خلال العمل على Fork خاص بك، يمكنك إجراء التعديلات ثم إرسالها لاحقًا إلى الريبو الرسمي عبر الـPull Requests.
+
+
+### استخدام GitHub Desktop
+يعتبر Gihub Desktop برنامج يتيح لك العمل مع Git من خلال واجهة رسومية بدلاً من كتابة الأوامر في الطرفية (Terminal). يُعد خيارًا جيدًا للمبتدئين في Git، كما يمكنك دائمًا التبديل بين GitHub Desktop والطرفية وقتما تشاء.
+
+أولًا، [قم بتحميل وتثبيت GitHub Desktop.](https://desktop.github.com/) بعد التثبيت، افتح التطبيق. سيطلب منك تسجيل الدخول إلى حسابك على GitHub. بعد تسجيل الدخول، ستظهر قائمة بمشاريعك، بما في ذلك النسخة المتفرعة (Fork) الخاصة بك من p5.js. اختر هذه النسخة، والتي سيكون اسمها `yourUsername/p5.js`، ثم اضغط على زر "Clone" الأزرق. سيطلب منك تحديد مكان حفظ المشروع على جهازك؛ يمكنك إما تغييره أو ترك الإعدادات الافتراضية والمتابعة.
+
+![واجهة مستخدم GitHub Desktop بعد تسجيل الدخول. في النصف الأيمن من الشاشة، تظهر قائمة المشاريع، مع زر Clone في أسفل اليمين.](../images/github-desktop-init.png)
+
+بعد اكتمال الاستنساخ (Clone)، سيطلب منك تحديد كيفية التخطيط لاستخدام الـFork الخاص بك. اختر خيار "المساهمة في المشروع الأصلي" ثم اضغط على "Continue".
+
+![الواجهة بعد استنساخ الـFork. يسألك التطبيق عما إذا كنت تخطط للمساهمة في المشروع الأصلي أو استخدامه لأغراضك الخاصة.](../images/github-desktop-fork.png)
+
+
+### استخدام واجهة أوامر git
+
+بعد إنشاء الـFork، انتقل إلى صفحة الريبو الخاص بك على GitHub، ثم انسخ رابط الـGit بالضغط على الزر الأخضر "Code". سيكون الرابط على شكل:
+
+```
+https://github.com/limzykenneth/p5.js.git
+```
+
+![لقطة شاشة تعرض قائمة الملفات في الصفحة الرئيسية للريبو. زر "Code" مميز بإطار برتقالي غامق.](../images/code-button.png)
+
+بعد ذلك، افتح الطرفية في بيئتك المحلية، وانتقل إلى المجلد الذي ترغب في حفظ الكود المصدري لـp5.js داخله. ثم نفّذ الأمر التالي لاستنساخ الريبو (نسخه إلى جهازك):
+
+```
+git clone [git_url]
+```
+
+استبدل `[git_url]` بالرابط الذي نسخته أعلاه. قد تستغرق العملية عدة دقائق حسب سرعة اتصالك بالإنترنت، وهي فرصة جيدة لتحضير كوب من القهوة! بعد الانتهاء، يمكنك فتح مجلد `p5.js` الذي تم تنزيله في محرر النصوص المفضل لديك والبدء في استكشافه.
+
+
+## نظرة عامة على بنية المشروع
+
+بعض أهم الملفات والمجلدات التي ستجدها داخل مجلد p5.js هي كما يلي:
+
+- `src` - يحتوي على جميع الأكواد التي يتم تجميعها في النهاية داخل ملفي `p5.js` و `p5.min.js`.
+- [`test`](./unit_testing.md) - يحتوي على اختبارات الوحدة (Unit Tests) بالإضافة إلى الأكواد الخاصة باختبار أمثلة التوثيق.
+- `tasks` - يحتوي على أكواد البناء (Build) التفصيلية والمخصصة.
+- `Gruntfile.js` - هو ملف إعدادات البناء الرئيسي.
+- `contributor_docs` - يحتوي على التوثيق وجميع المستندات الأخرى الخاصة بالمساهمين.
+
+أما باقي الملفات والمجلدات فهي إما ملفات إعدادات أو ملفات داعمة أخرى؛ وفي أغلب الحالات، لن تحتاج إلى التعديل عليها.
+
+
+## إعداد بيئة العمل Build setup
+
+قبل القيام بأي شيء، ستحتاج إلى إعداد مجلد المشروع المحلي حتى تتمكن من بناء مكتبة p5.js وتشغيل الاختبارات. بافتراض أنك قمت بتثبيت node.js مسبقًا، نفّذ الأمر التالي:
+
+```
+npm ci
+```
+
+هذه العملية قد تستغرق بعض الوقت، لأن npm سيقوم بتحميل جميع الاعتمادات (Dependencies) المطلوبة. بمجرد الانتهاء، ستكون بيئة العمل جاهزة. الأمر بسيط، أليس كذلك؟
+
+---
+
+## سير العمل مع Git
+
+الآن، أصبحت جاهزًا لإجراء التعديلات المطلوبة. لمزيد من التفاصيل حول الأجزاء المختلفة من الريبو وكيفية تعديلها، يمكنك الرجوع إلى الأقسام الفرعية أدناه. كبداية، قم بتشغيل:
+
+```
+npm test
+```
+
+هذا الأمر سيقوم ببناء مكتبة p5.js من البداية، بالإضافة إلى تشغيل جميع اختبارات الوحدة. يُفترض أن تكتمل العملية دون أي أخطاء. إذا أردت فقط بناء المكتبة بدون تشغيل الاختبارات، يمكنك استخدام:
+
+```
+npm run build
+```
+
+أي من الأوامر أعلاه سيقوم ببناء المكتبة في مجلد `lib/` على شكل الملفين: `p5.js` و `p5.min.js`. يمكنك استخدام هذه الملفات في اختباراتك الخاصة إذا لزم الأمر.
+
+بعد ذلك، يُفضّل إنشاء فرع (Branch) جديد انطلاقًا من الفرع `main` قبل بدء العمل. الفرع في Git هو كما يوحي الاسم: نسخة متفرعة من الريبو يمكنك إضافة التعديلات إليها دون التأثير على فرع `main` أو أي فروع أخرى. الفروع تتيح لك العمل على عدة ميزات في نفس الوقت (من خلال فروع منفصلة) وتمنحك الثقة بأن أي خطأ في أحد الفروع لن يؤثر على الفرع الرئيسي.
+
+في GitHub Desktop، يمكنك القيام بذلك من خلال النقر على زر "Current Branch" الموجود في رأس النافذة. من هناك، يمكنك التنقل بين الفروع أو إدخال اسم فرع جديد لإنشائه. يُفضّل إدخال اسم يعبر عن التغيير الذي ستجريه، ثم اضغط "Create New Branch".
+
+![لقطة شاشة لواجهة GitHub Desktop لقائمة اختيار الفروع. عند إدخال اسم فرع جديد غير موجود، يظهر زر "Create New Branch".](../images/github-desktop-create-branch.png)
+
+من خلال الطرفية، يمكنك إنشاء فرع جديد باستخدام الأمر:
+
+```
+git checkout -b branch_name
+```
+
+استبدل `branch_name` باسم وصفي يعبر عن التعديلات التي ستجريها.
+
+أثناء قيامك بإجراء التعديلات، يُفضّل أن تقوم بتشغيل:
+
+```
+npm test
+```
+
+بشكل متكرر، خصوصًا عند تعديل الكود المصدري. هذا الأمر يستغرق بعض الوقت، لكنه يضمن أن التعديلات التي أجريتها لم تؤدِ إلى كسر أي سلوك قائم. تأكد من تشغيله قبل الانتقال إلى مرحلة "Commit" التي سيتم شرحها أدناه.
+
+بعد إجراء التعديلات على الكود، تحتاج إلى حفظها (Commit) داخل الريبو. الـCommit هو تسجيل لحالة الملفات في الريبو في لحظة معينة، بحيث يمكنك الرجوع إليها لاحقًا.
+
+قد تتساءل: كم مرة يجب أن أقوم بعمل Commit؟ القاعدة العامة: من الأفضل أن تقوم بعمل Commits متكررة بدلاً من جمع العديد من التعديلات الكبيرة داخل Commit واحد. قاعدة جيدة هي أن تقوم بعمل Commit بعد الانتهاء من كل جزء صغير (Subtask) يمكنك وصفه في جملة واحدة.
+
+لعمل Commit عبر GitHub Desktop، افتح التطبيق بعد إجراء التعديلات. سترى قائمة بالملفات التي تم تعديلها في الشريط الجانبي الأيسر، وستظهر التعديلات داخل كل ملف على الجانب الأيمن. اكتب وصفًا مختصرًا وواضحًا للتعديلات في الحقل الموجود أسفل يسار النافذة بجانب أيقونة المستخدم. هذا سيكون عنوان الـCommit. يمكنك إضافة تفاصيل إضافية في الحقل السفلي أو تركه فارغًا. اضغط على زر "Commit" الأزرق لحفظ التغييرات.
+
+![لقطة شاشة لـGitHub Desktop بعد إجراء تعديل. الحقل الذي تكتب فيه عنوان التغيير محاط بدائرة حمراء في أسفل يسار النافذة.](../images/github-desktop-commit.png)
+
+### باستخدام الطرفية (Terminal)
+
+1. للتحقق من الملفات التي تم تعديلها، استخدم الأمر:
+
+```
+git status
+```
+
+إذا ظهرت ملفات لم تقم بتعديلها، ستحتاج إلى استعادتها إلى حالتها الأصلية باستخدام:
+
+```
+git restore
+```
+
+أو التأكد أنها تغييرات مقصودة. لرؤية تفاصيل التعديلات لكل ملف:
+
+```
+git diff
+```
+
+تأكد من عدم تضمين أي تغييرات غير مقصودة داخل الـCommit.
+
+2. لإضافة جميع التعديلات إلى مرحلة الـStaging (التحضير للتسجيل)، نفّذ:
+
+```
+git add .
+```
+
+3. لحفظ التغييرات (Commit)، استخدم:
+
+```
+git commit -m "[your_commit_message]"
+```
+
+استبدل `[your_commit_message]` برسالة تصف التعديلات بشكل واضح. تجنب الرسائل العامة مثل "تعديلات على التوثيق"، وبدلًا من ذلك استخدم رسالة مثل:
+
+```
+git commit -m "إضافة مثال توثيقي لدالة circle()"
+```
+
+كرر هذه الخطوات مع كل مجموعة من التعديلات، مع التأكد من تشغيل:
+
+```
+npm test
+```
+
+بشكل دوري للتأكد من أن الأمور تسير على ما يرام.
+
+
+### كود المصدر
+إذا كنت ستعمل على الشيفرة المصدرية، فإن نقطة البداية الجيدة (في حال كنت تعرف أي ميزة من ميزات p5.js ستعمل عليها) هي زيارة التوثيق الرسمي. في أسفل كل صفحة توثيق لأي دالة أو وظيفة في p5.js، ستجد رابطًا يشير إلى مكان وجود الشيفرة المصدرية لهذه الوظيفة.
+
+![صورة مقصوصة من صفحة مرجعية على موقع p5.js تحتوي على الجملة "هل لاحظت أي أخطاء أو مشاكل؟ يُرجى إخبارنا بذلك. لا تتردد في تعديل الملف src/core/shape/2d_primitives.js وإرسال Pull Request!‎". مع تمييز للرابط الخاص بالمصدر بخط أحمر وسهم يشير إليه.](../images/reference-code-link.png)
+
+
+### الـUnit tests
+
+إذا كنت ستعمل على **الاختبارات الوحدوية** (Unit Tests)، فيُرجى الاطلاع على [هذه الصفحة](./unit_testing.md).  
+لاحظ أنه عند إضافة ميزة جديدة أو تحسين ميزة حالية أو حتى إصلاح بعض الـBugs، فمن الضروري تضمين اختبارات وحدوية (Unit Tests) تغطي الشيفرة الجديدة في الـPull Request.
+
+
+### التوثيق المضمن Inline Documentation
+
+إذا كنت ستعمل على **التوثيق المضمن** أو ما يُعرف بـp5.js Reference، فيمكنك الرجوع إلى [هذه الصفحة](./contributing_to_the_p5js_reference.md).
+
+
+### إتاحة الوصول Accessibility
+
+إذا كنت ستعمل على ميزات تخص **إمكانية الوصول** (Accessibility)، فيُرجى الاطلاع على [هذه الصفحة](./web_accessibility.md).  
+أما بالنسبة لنظام الأخطاء الودية (Friendly Error System)، فيمكنك الاطلاع على [هذه الصفحة](./friendly_error_system.md).
+
+
+## معايير كتابة الكود
+
+معايير كتابة الكود (Code Standard) في p5.js تُفرض عبر أداة [ESLint](https://eslint.org/).  
+يجب أن يمر أي **Commit** أو **Pull Request** بدون أي أخطاء متعلقة بـLinting قبل قبوله.  
+أسهل طريقة لضمان الالتزام بهذه المعايير هي تثبيت إضافة **ESLint** في محرر النصوص الذي تستخدمه، والتي تقوم بعرض أخطاء الـLinting أثناء كتابة الكود (متوفرة لمعظم المحررات المشهورة).
+
+
+## مبادئ تصميم البرمجيات
+
+عند العمل على أي ميزة في p5.js، من المهم جدًا أن تبقي في ذهنك مبادئ التصميم الخاصة بالمشروع.  
+قد تختلف أولوياتنا عن أولويات المشاريع الأخرى، لذلك إذا كنت قادمًا من مشروع آخر، فننصحك بالتعرف على مبادئ p5.js قبل البدء.
+
+- **إتاحة الوصول (Access)**  
+   نحن نضع **إتاحة الوصول** في المقام الأول عند اتخاذ أي قرار. كل قرار يجب أن يأخذ في الاعتبار كيفية زيادة وصول الفئات المهمشة تاريخيًا. يمكنك قراءة المزيد حول هذا [هنا](./access.md)
+
+- **ملاءمة للمبتدئين (Beginner Friendly)**  
+   واجهة برمجة التطبيقات (API) الخاصة بـp5.js مصممة بحيث تكون **صديقة للمبتدئين**، مما يوفر حاجزًا منخفضًا جدًا للبدء في إنشاء محتوى تفاعلي ومرئي باستخدام أحدث تقنيات HTML5/Canvas/DOM.
+
+- **تعليمي (Educational)**  
+   p5.js يركز على توفير **واجهة برمجية (API)** ومنهج تعليمي يدعمان الاستخدام التعليمي. وهذا يشمل مرجعًا كاملًا (Reference) للـAPI مع أمثلة داعمة، بالإضافة إلى دروس ومناهج صفية توضح مبادئ البرمجة الإبداعية بشكل واضح وجذاب.
+
+- **اللغة JavaScript ومجتمعها**  
+   p5.js يسعى لجعل ممارسات تطوير الويب باستخدام JavaScript أكثر سهولة بالنسبة للمبتدئين من خلال تبني أنماط تصميم (Design Patterns) صحيحة بلغة JavaScript، مع إخفاء بعض التعقيدات عند الضرورة.  
+   وكجزء من مشروع مفتوح المصدر، يدمج p5.js أيضًا **مجتمع JavaScript الأوسع** في عملية تطويره وتوثيقه ونشره.
+
+- **اللغة Processing ومجتمعها**  
+   p5.js مستوحى من لغة Processing ومجتمعها، ويهدف إلى جعل **الانتقال** من Processing (بلغة Java) إلى p5.js (بلغة JavaScript) سهلًا وواضحًا.
+
+[**⬆ العودة إلى الأعلى**](#إرشادات-المساهمة)
+---
+
+
+
+# الـPull Requests
+
+الآن بعد أن قمت بإجراء التعديلات اللازمة، بما في ذلك إضافة **الاختبارات الوحدوية** (إن كانت مطلوبة)، وتأكدت أن أمر `npm test` لا يُظهر أي أخطاء، وقمت بعمل **Commit** لهذه التغييرات، يمكنك البدء في تحضير **Pull Request** لإرسال **التعديلات الجديدة** ودمجها في **ريبو** p5.js الرسمي.
+
+الـ**Pull Request**، بشكل رسمي، هو طلب يُرسل إلى **الريبو** (في هذه الحالة ريبو p5.js الرسمي) من أجل **سحب (Pull)** أو **دمج (Merge)** التعديلات القادمة من **الريبو المشتق (Forked Repo)** الخاص بك إلى **سجل Commits** الخاص بالريبو الرسمي.
+
+## إنشاء الـPull Request
+
+أول خطوة هي **دفع التغييرات** (Push) إلى **الـFork** الخاص بك على p5.js — يمكنك اعتبارها عملية رفع التعديلات إلى الـFork.
+
+ باستخدام GitHub Desktop
+
+في تطبيق **GitHub Desktop**، ستجد زرًا على يمين زر تغيير الفروع (Branches) في الشريط العلوي. هذا الزر يُستخدم لدفع تغييراتك إلى **GitHub**. اضغط عليه لدفع التعديلات.
+
+![صورة تعرض GitHub Desktop بعد عمل Commit للتغييرات. زر دفع التعديلات إلى GitHub محاط بدائرة حمراء.](../images/publish-branch.png)
+
+بمجرد رفع الكود، سيظهر زر يطلب منك إنشاء **Pull Request**. الضغط على هذا الزر سيعرض لك معاينة مع زر آخر لتأكيد إنشاء الطلب. اضغط على زر **Create Pull Request** لبدء العملية.
+
+![لقطة شاشة من GitHub Desktop بعد دفع الكود. في الشريط الجانبي الأيسر مكتوب "0 changed items". وفي الجزء الأيمن أسفل عنوان "No local changes"، يوجد زر أزرق باسم "Review Pull Request" محاط بدائرة حمراء.](../images/preview-pull-request.png)
+
+ من خلال الطرفية (Terminal)
+
+لتدفع التغييرات من خلال **الطرفية**، نفّذ الأمر التالي:
+
+```
+git push -u origin [branch_name]
+```
+
+بعد اكتمال عملية الـ**Push**، قد ترى في **الطرفية** رابطًا يتيح لك فتح **Pull Request** مباشرة.  
+أما إذا لم يظهر الرابط، يمكنك الانتقال إلى **الـFork** الخاص بك على GitHub عبر **المتصفح**، ومن هناك قم بالتالي:
+
+1. اختر **الفرع (Branch)** الذي تعمل عليه من القائمة المنسدلة أعلى قائمة الملفات.
+2. اضغط على زر **Contribute**.
+3. اختر **Open pull request**.
+
+![لقطة شاشة تعرض استجابة الطرفية بعد دفع فرع جديد. يظهر فيها رابط GitHub لفتح Pull Request جديد.](../images/new-branch.png)
+
+
+ من خلال صفحة ريبو p5.js
+يمكنك أيضًا رؤية زر يتيح لك **فتح Pull Request** عند زيارة صفحة p5.js على GitHub، إذا كنت قد دفعت تغييرات إلى فرع جديد.
+
+![لقطة شاشة مقصوصة من الصفحة الرئيسية لريبو p5.js على GitHub. يظهر في الأعلى صندوق أصفر يحتوي على زر أخضر باسم "Compare & pull request".](../images/recent-pushes.png)
+
+
+### معلومات الـPull Request
+
+![لقطة شاشة لصفحة "Open a pull request" على GitHub مع وجود القالب الخاص بالـPull Request في p5.js جاهزًا.](../images/new-pr.png)
+
+قبل تقديم الـ**Pull Request**، ستحتاج إلى **ملء القالب** (Template) الخاص به.
+
+
+### العنوان Title
+
+يجب أن يكون **عنوان الـPull Request** وصفًا مختصرًا للتعديلات التي أجريتها. حاول تجنب العبارات العامة أو الغامضة هنا.
+
+---
+
+### خانة Resolves
+
+ضمن القالب، ستجد السطر التالي:
+
+```
+Resolves #[Add issue number here]
+```
+
+يجب استبدال `[Add issue number here]` **برقم الـIssue** الذي تقوم بحله أو معالجته (على سبيل المثال: `Resolves #1234`).
+
+هذا الإجراء يضمن أن **الـIssue سيتم إغلاقه تلقائيًا** بمجرد دمج هذا الـ**Pull Request**.
+
+> إذا كنت لا ترغب في إغلاق الـIssue تلقائيًا (مثلاً لأن هناك تغييرات إضافية ستتم في **Pull Request** منفصل)، يمكنك استبدال كلمة `Resolves` بكلمة `Addresses`.
+
+
+
+### التغييرات
+
+يجب أن توضح بشكل واضح التغييرات التي قمت بها في هذا الـPull Request. قم بتضمين أي تفاصيل متعلقة بالتنفيذ والقرارات التي اتخذتها هنا والتي قد تكون ذات صلة بمن سيقوم بمراجعته.
+
+### لقطات الشاشة للتغيير
+
+هذا القسم اختياري حسب الحالة، ويُفضل تضمينه عند إجراء تغييرات تتعلق بكيفية قيام p5.js بعرض الرسوميات على الـCanvas.  
+لاحظ أن المطلوب هنا ليس لقطة شاشة للمحرر النصي، بل لقطة شاشة لسلوك السكيتش بعد تطبيق التغييرات.
+
+### قائمة التحقق للـPR
+
+تحتوي هذه القائمة على بعض البنود ذات الصلة، والتي يجب تحديدها بوضع علامة `[x]` بدلًا من `[ ]` أينما ينطبق ذلك على تغييراتك.
+
+بعد الانتهاء، اضغط على "Create pull request".
+
+
+
+### إعادة الترتيب وحل التعارضات Rebase and resolve conflicts
+
+![لقطة شاشة لطلب سحب مفتوح (Pull Request) على ريبو p5.js في GitHub. عنوان الـPull Request يقول "Fix filter shaders when rectMode is applied; add tests #6603".](../images/opened-pr.png)
+
+الآن يجب عليك فحص الـPull Request المفتوح والانتباه إلى بعض الأمور:
+
+1. **عدد الـCommits يجب أن يتطابق مع عدد الـCommits التي قمت بها**، بمعنى إذا قمت بعمل Commit مرتين أثناء العمل على هذا الـPR، فيجب أن يظهر فقط Commitان في تبويب "Commits".
+2. **تبويب "Files changed" يجب أن يعرض فقط التغييرات التي أجريتها مقارنةً بريبو p5.js**، ولا شيء إضافي.
+3. **في الأسفل، يجب أن تظهر رسالة "This branch has no conflicts with the base branch"**، وليس "This branch has conflicts that must be resolved".
+
+إذا كان أي من هذه النقاط غير صحيح (يوجد Commits أكثر مما توقعت أو هناك تعارضات)، فقد تحتاج إلى [إعادة الترتيب (Rebase)](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) أو المساعدة في حل التعارضات.  
+التعارضات تحدث عندما تقوم بإجراء تغييرات على ملف حدثت فيه تغييرات أخرى مؤخرًا، ولا يستطيع git تحديد أي التغييرات يجب الاحتفاظ بها. إذا لم تكن واثقًا من كيفية حل هذه المشكلات، فأخبرنا وسنرشدك خلال العملية. الإرشادات الأساسية كما يلي:
+
+في بعض الأحيان، يتيح لك GitHub حل التعارضات مباشرة عبر المتصفح من خلال زر "Resolve Conflicts":  
+![لقطة شاشة لطلب سحب في GitHub يحتوي على تعارضات. تظهر أسماء الملفات التي تحتوي على تعارضات ويوجد زر "Resolve conflicts" مميز.](../images/resolve-conflicts.png)
+
+التعارضات تظهر بين العلامات `<<<<<<<` و`>>>>>>>`، ويفصل بينها `=======`.  
+أحد الجزئين يعرض **الكود الخاص بك**، والجزء الآخر يعرض **التغييرات التي حدثت في الفرع الرئيسي (main)**.
+
+![لقطة شاشة لواجهة حل التعارضات في GitHub. الشريط الجانبي يعرض الملفات التي تحتوي على تعارضات. اللوحة اليمنى تحتوي على الكود المتعارض مع علامات التعارض مميزة.](../images/conflicts-interface.png)
+
+قم بإزالة علامات التعارض واحفظ فقط الكود النهائي الذي ترغب في الإبقاء عليه في الـPR الخاص بك. بعد ذلك، يمكنك الضغط على "Mark as resolved" بعد معالجة جميع التعارضات.
+
+![لقطة شاشة لواجهة GitHub بعد تعديل الكود لإزالة علامات التعارض. زر "mark as resolved" في أعلى اليمين أصبح مفعّلًا.](../images/mark-as-resolved.png)
+
+عند الانتهاء من حل جميع التعارضات في الملفات، يمكنك **تأكيد التغييرات (Commit)**.
+
+![واجهة GitHub بعد حل جميع التعارضات ووضع علامة "تم حلها". أصبح زر "commit merge" الأخضر مفعّلًا.](../images/commit-merge.png)
+
+في بعض الأحيان تكون التعارضات معقدة جدًا بحيث لا يستطيع GitHub عرضها في المتصفح. في هذه الحالة، أو إذا كنت تفضل الحل اليدوي، يمكنك حل التعارضات محليًا:
+
+1. تشغيل الأمر:
+    ```
+    git remote add upstream https://github.com/processing/p5.js
+    ```
+2. جلب آخر التحديثات من الريبو الرئيسي:
+    ```
+    git fetch upstream
+    ```
+3. إعادة الترتيب (Rebase) فوق الفرع الرئيسي:
+    ```
+    git rebase upstream/main
+    ```
+4. إذا واجهت تعارضات، سيتم إعلامك بها!  
+   - إذا كانت فقط في `lib/p5.js` و`lib/p5.min.js`، فالحل بسيط: فقط قم بإعادة بناء المشروع.
+   - إذا ظهرت تعارضات في ملفات أخرى ولم تكن متأكدًا من كيفية حلها، اطلب المساعدة!
+
+    ```
+    npm test
+    git add -u
+    git rebase --continue
+    ```
+
+5. أخيرًا، ادفع التغييرات:
+    ```
+    git push
+    ```
+
+في بعض الحالات، قائمة التحقق (Checklist) في الـPR قد يتم إعادة ضبطها بعد هذه الخطوات، ولكن لا تقلق، سنرشدك إلى أي خطوات إضافية مطلوبة.
+
+
+
+## النقاش والتعديل
+
+الآن بعد أن تم فتح الـPull Request الخاص بك، سيقوم أحد المشرفين أو المديرين (Maintainer) بمراجعته. قد يستغرق الأمر عدة أيام قبل أن يتمكن أحد المشرفين من الرد على الـPR الخاص بك، لذا تحلَّ بالصبر. لماذا لا تستغل هذا الوقت في إلقاء نظرة على بعض الـIssues المفتوحة الأخرى في هذه الأثناء؟
+
+بمجرد أن يراجع المشرف الـPR الخاص بك، يمكن أن يحدث أحد أمرين:
+
+1. تتم الموافقة على الـPR ودمجه... مبروك!
+2. قد يطرح المشرف بعض الأسئلة حول الـPR أو يطلب بعض التعديلات عليه.
+
+إذا حدث الخيار الثاني، فلا داعي للقلق؛ هذا أمر طبيعي تمامًا، والمشرفون دائمًا موجودون لمساعدتك في إتمام مساهمتك!
+
+إذا طُلب منك إجراء تغييرات على الـPR وتمكنت من تنفيذها، اتبع [نفس العملية السابقة](#سير-العمل-مع-git) ولكن فقط تابع من النسخة المحلية (local copy) من الريبو والفرع (branch) المرتبط، وقم بإجراء التغييرات المطلوبة، ثم أضفها في Commit جديد وادفعها (push) إلى الريبو المشتق (forked remote repo) الخاص بك. بمجرد دفع (push) الـCommits الإضافية، ستظهر تلقائيًا في الـPR. ولا تنسَ ترك تعليق في الـPR لإعلام المراجع بأنك أجريت التغييرات المطلوبة. وإذا لم تكن هناك حاجة إلى تغييرات إضافية، سيتم دمج (merge) الـPR!
+
+[**⬆ العودة إلى الأعلى**](#إرشادات-المساهمة)
diff --git a/contributor_docs/ar/steward_guidelines.md b/contributor_docs/ar/steward_guidelines.md
new file mode 100644
index 0000000000..8a31bab11b
--- /dev/null
+++ b/contributor_docs/ar/steward_guidelines.md
@@ -0,0 +1,469 @@
+# المتعهدين/ات والمشرفين/ات
+
+سواءً انضممت إلينا حديثًا كمشرف، أو كنت من المشرفين القدامى على مشروع p5.js، أو في أي مرحلة بينهما، يحتوي هذا الدليل على معلومات بالإضافة إلى نصائح وحيل ستساعدك على المساهمة بفعالية في مشروع p5.js. معظم ما هو مكتوب هنا عبارة عن إرشادات (Guidelines) ما لم يُذكر غير ذلك، وهذا يعني أنه يمكنك تكييف الممارسات الموضحة هنا بما يتناسب مع سير عملك.
+
+
+## جدول المحتويات
+
+- [الـIssues](#الـissues)
+  - [تقرير عن Bug](#تقرير-عن-bug)
+  - [طلب ميزة جديدة](#طلب-ميزة-جديدة)
+  - [تحسين ميزة موجودة](#تحسين-ميزة-موجودة)
+  - [النقاش](#النقاش)
+- [الـPull Requests](#الـpull-requests)
+  - [التعديلات البسيطة](#التعديلات-البسيطة)
+  - [إصلاح Bug](#إصلاح-bug)
+  - [ميزة جديدة او تحسين ميزة موجودة](#ميزة-جديدة-او-تحسين-ميزة-موجودة)
+  - [Dependabot](#dependabot)
+- [عملية البناء](#عملية-البناء)
+  - [مهمة البناء الأساسية](#مهمة-البناء-الأساسية)
+  - [المهام المتنوعة](#المهام-المتنوعة)
+- [عملية الـRelease](#عملية-الـrelease)
+- [نصائح وحيل](#نصائح-وحيل)
+  - [قوالب الردود](#قوالب-الردود)
+  - [GitHub CLI](#github-cli)
+  - [إدارة الإشعارات](#إدارة-الإشعارات)
+ 
+---
+
+## الـIssues
+
+نشجع أن تبدأ معظم المساهمات في الكود المصدري بفتح Issue، ولهذا السبب فإن الـIssues هي المكان الذي تتم فيه أغلب النقاشات. الخطوات التي يتعين على المشرف اتباعها عند مراجعة Issue تعتمد على نوعها. الريبو يستخدم [قوالب GitHub للـIssues](https://github.com/processing/p5.js/blob/main/.github/ISSUE_TEMPLATE) بهدف تنظيم أنواع الـIssues المختلفة وتشجيع أصحابها على تقديم جميع المعلومات ذات الصلة بمشكلاتهم. 
+
+أول خطوة عند مراجعة أي Issue عادةً تكون بقراءة النموذج الذي تم تعبئته، وتحديد ما إذا كنت بحاجة إلى معلومات إضافية (على سبيل المثال: في حالة وجود خانات لم يتم تعبئتها أو تم استخدام قالب غير صحيح).
+
+
+### تقرير عن Bug
+
+يُفترض أن تستخدم الـIssues الخاصة بتقارير الـBugs قالب "Found a bug". ويُعتبر المسار التالي هو النمط المعتاد للتعامل مع تقارير الـBugs:
+
+1. إعادة إنتاج الـBug
+   - الهدف من القالب هو توفير معلومات كافية للمشرف حتى يتمكن من محاولة إعادة إنتاج الـBug المذكور.
+   - إذا كان الـBug المبلّغ عنه لا يخص الريبو الذي تم فتحه فيه (سواء كان p5.js أو p5.js-website أو غيره):
+     - انقل الـIssue إلى الريبو المناسب إذا كان لديك الصلاحية.
+     - إن لم تكن تملك الصلاحية، اترك تعليقًا يوضح أين يجب رفع التقرير (مع توفير رابط مباشر)، ثم أغلق الـIssue.
+   - أول خطوة عند مراجعة تقرير الـBug هي التأكد من وجود معلومات كافية لمحاولة إعادة إنتاجه، وإذا توفرت، قم بالمحاولة.
+
+2. إذا أمكن إعادة إنتاج الـBug:
+   - قد يتطلب الأمر نقاشًا لتحديد أفضل طريقة لإصلاح الـBug. أحيانًا تكون الطريقة واضحة وأحيانًا تكون معقدة. يُرجى الرجوع إلى [مبادئ تصميم p5.js](./contributor_guidelines.md#مبادئ-تصميم-البرمجيات) عند اتخاذ القرار في كل حالة.
+   - إذا أشار صاحب الـIssue في التقرير إلى استعداده للمساهمة في الحل:
+     - وافق على أن يقوم هو بإصلاح الـBug بترك تعليق وتعيينه على الـIssue. يمكنك تعيينه باستخدام زر الإعدادات (⚙️) بجانب "Assignee".
+   - إذا لم يرغب صاحب الـIssue في المساهمة بالإصلاح:
+     - اترك تعليقًا يؤكد أن الـBug تم إعادة إنتاجه.
+     - حاول إصلاحه بنفسك أو أضف وسم `help wanted` للإشارة إلى أن هذا الـIssue بحاجة إلى مساهمة.
+
+3. إذا تعذرت إعادة إنتاج الـBug:
+   - اطلب معلومات إضافية إذا لم تكن متوفرة بالفعل في القالب (مثل إصدار p5.js، إصدار المتصفح، نظام التشغيل...إلخ).
+   - إذا كان بيئة الاختبار لديك تختلف عن المذكورة في التقرير (مثال: متصفح أو نظام تشغيل مختلف):
+     - اترك تعليقًا توضح فيه أنك لم تستطع إعادة إنتاج الـBug في بيئتك.
+     - أضف وسم `help wanted` واطلب من شخص آخر يملك نفس البيئة المذكورة في التقرير أن يحاول إعادة إنتاج الـBug.
+   - أحيانًا تحدث الـBugs في محرر الويب فقط وليس عند الاختبار محليًا. في هذه الحالة، يجب إعادة توجيه الـIssue إلى ريبو [الـWeb Editor](https://github.com/processing/p5.js-web-editor).
+   - إذا نجحت إعادة الإنتاج لاحقًا، ارجع إلى الخطوة 2.
+
+4. إذا كان سبب الـBug هو الكود الذي قدمه المستخدم وليس بسبب سلوك p5.js:
+   - حدد ما إذا كان من الممكن تحسين توثيق p5.js أو الكود أو نظام الأخطاء الودية (friendly error system) لتجنب تكرار نفس الخطأ.
+   - قم بتوجيه المستخدم بلطف إلى [المنتدى](https://discourse.processing.org/) أو [Discord](https://discord.com/invite/SHQ8dH25r9) في حال عدم وجود أي تعديلات لازمة في p5.js، ثم أغلق الـIssue.
+  
+
+### طلب ميزة جديدة
+
+يُفترض أن تستخدم الـIssues الخاصة بطلبات الميزات الجديدة قالب "New Feature Request". والمسار التالي هو النمط المعتاد للتعامل مع طلبات الميزات:
+
+1. كجزء من التزام p5.js بزيادة الوصول، يجب أن يوضح طلب الميزة كيف يساهم في زيادة إتاحة p5.js إلى المجتمعات التي تم تهميشها تاريخيًا في هذا المجال. يمكن العثور على المزيد من التفاصيل [هنا](access.md).
+   - إذا لم يُملأ حقل "زيادة الوصول" بشكل كافٍ في الطلب، يمكنك أن تطلب من صاحب الـIssue توضيح كيف تزيد هذه الميزة من الوصول.
+   - يمكن لأي عضو آخر في المجتمع (بما في ذلك المشرفون على المراجعة) أن يضيف بيانًا حول تأثير الميزة على زيادة الوصول.
+
+2. يتم تقييم طلب الميزة الجديدة للنظر في إدراجه بناءً على المعايير التالية:
+   - هل الميزة المقترحة تناسب نطاق المشروع ومبادئ [تصميم p5.js](./contributor_guidelines.md#مبادئ-تصميم-البرمجيات)؟
+     - على سبيل المثال، قد يتم النظر في طلب إضافة شكل جديد للرسم، بينما طلب تبني بروتوكول إنترنت الأشياء (IOT) في المتصفح سيكون غالبًا خارج النطاق.
+     - بشكل عام، يجب أن يظل نطاق p5.js ضيقًا نسبيًا لتجنب التضخم المفرط الناتج عن إضافة ميزات نادرًا ما تُستخدم.
+     - إذا لم تكن الميزة المقترحة مناسبة لنطاق p5.js، يمكنك اقتراح أن يقوم صاحب الطلب بتنفيذها على شكل مكتبة إضافية (Addon Library).
+     - إذا لم يكن من الواضح ما إذا كانت الميزة مناسبة أو لا، فمن الجيد أحيانًا اقتراح تنفيذها كمكتبة إضافية كتجربة إثبات المفهوم (Proof of Concept). هذا يمنح المستخدمين طريقة لتجربة الميزة ويقدم مثالًا عمليًا أكثر على فائدتها وأهميتها، كما أن المكتبة الإضافية ليست بحاجة لأن تكون مكتملة مثل الميزات المدمجة في صلب p5.js. وإذا ثبتت أهميتها لاحقًا، يمكن دمجها في الكود الأساسي.
+
+   - هل من المحتمل أن تسبب الميزة تغييرات جذرية؟
+     - هل ستتعارض مع دوال أو متغيرات p5.js الحالية؟
+     - هل ستتعارض مع الرسومات (Sketches) الموجودة مسبقًا المكتوبة باستخدام p5.js؟
+     - تعتبر الميزات التي قد تسبب تعارضات مثل هذه تغييرات جذرية. وبدون [إصدار رئيسي جديد](https://docs.npmjs.com/about-semantic-versioning)، يجب تجنب إدخال تغييرات جذرية على p5.js.
+
+   - هل يمكن تنفيذ الميزة المقترحة باستخدام الوظائف الحالية في p5.js أو باستخدام أكواد JavaScript الأصلية البسيطة أو مكتبات أخرى سهلة الاستخدام؟
+     - على سبيل المثال، بدلاً من إضافة دالة p5.js تجمع بين مجموعة من النصوص مثل `join(["Hello", "world!"])`، يُفضل استخدام الدالة الأصلية في JavaScript:  
+     `["Hello", "world!"].join()`.
+
+3. إذا تم استيفاء متطلبات الوصول والمعايير الأخرى، فيجب أن يوافق مشرفان أو اثنان من المسؤولين عن الصيانة (Maintainers) على الأقل على طلب الميزة قبل أن يبدأ العمل على إعداد Pull Request. عملية مراجعة الـPR الخاصة بالميزات الجديدة موضحة أدناه.
+
+
+### تحسين ميزة موجودة
+
+يُفترض أن تستخدم الـIssues الخاصة بتحسين الميزات القائمة قالب "Existing Feature Enhancement". والعملية مشابهة جدًا لطلبات الميزات الجديدة، مع وجود اختلاف بسيط بينهما. أحيانًا قد يكون من الصعب التمييز بين طلب ميزة جديدة وتحسين ميزة قائمة. بشكل عام، تحسين الميزة يتعامل مع الوظائف الموجودة مسبقًا في p5.js، بينما طلب الميزة الجديدة عادةً يطلب إضافة وظائف جديدة بالكامل.
+
+1. على غرار طلبات الميزات الجديدة، لا يُقبل تحسين الميزة إلا إذا ساهم في زيادة الإتاحة إلى p5.js. راجع النقطة 1 في [القسم السابق](#طلب-ميزة-جديدة).
+
+2. معايير قبول تحسين الميزة مشابهة لمعايير قبول الميزات الجديدة، لكن مع التركيز بشكل خاص على احتمال حدوث تغييرات جذرية (Breaking Changes).
+   - إذا كان التحسين يتضمن تعديل دوال موجودة، فيجب أن تظل جميع التوقيعات (Signatures) الصالحة والموثقة لهذه الدوال تعمل بنفس الطريقة دون أي تغييرات.
+
+3. يجب أن يحصل تحسين الميزة على موافقة مشرف (Steward) واحد على الأقل أو أحد مسؤولي الصيانة (Maintainer) قبل أن يبدأ العمل على إعداد الـPull Request. عملية مراجعة الـPR الخاصة بتحسين الميزات موضحة أدناه.
+
+
+### النقاش
+
+هذا النوع من الـIssues يستخدم قالبًا بسيطًا تحت اسم ("Discussion")، ويُفترض استخدامه لجمع الآراء والملاحظات حول موضوع عام قبل تحويله إلى شيء أكثر تحديدًا مثل طلب ميزة جديدة. يمكن إغلاق هذه الـIssues بعد انتهاء النقاش وإنشاء الـIssues الأكثر تحديدًا الناتجة عن هذا النقاش.
+
+- إذا تم فتح Issue على أنها نقاش، لكنها في الواقع بلاغ عن bug مثلًا، فيجب تعديل التصنيف (Label) إلى التصنيف المناسب، وإزالة تصنيف "discussion". كما يجب طلب أي معلومات إضافية حول الـbug من صاحب الـIssue إذا لم تكن موجودة بالفعل.
+- إذا تم فتح Issue على أنها نقاش، لكنها غير مرتبطة بالمساهمة في الكود المصدري أو بعمل ريبوز GitHub أو عملية المساهمة أو مجتمع المساهمين، فيجب إعادة توجيه صاحبها إلى المنتدى أو سيرفر الـDiscord، ثم إغلاق الـIssue.
+- إذا كانت ذات صلة، فمن الأفضل إضافة تصنيفات إضافية (Labels) إلى الـIssues من نوع النقاش لتوضيح نوع النقاش بشكل سريع بمجرد النظر.
+
+
+---
+
+
+## الـPull Requests
+
+تقريبًا جميع المساهمات في الكود المصدري في ريبوز p5.js تتم عبر الـPull Requests. على الرغم من أن المشرفين لديهم صلاحية الدفع المباشر (Push Access) إلى الريبو، إلا أنه من الأفضل لهم اتباع نفس العملية: (Issue → Pull Request → Review) عند المساهمة بالكود. فيما يلي الخطوات المتبعة لمراجعة الـPull Request:
+
+- يمكن العثور على قالب الـPull Request [هنا](https://github.com/processing/p5.js/blob/main/.github/PULL_REQUEST_TEMPLATE.md).
+- معظم الـPull Requests يجب أن تكون مرتبطة مسبقًا بـIssue مفتوح وتمت مناقشته أولًا، مما يعني أنه يجب اتباع [مسار العمل الخاص بالـIssues](#الـissues) قبل أن يقوم أي مشرف أو مدير بمراجعة الـPull Request.
+    - الحالات الوحيدة التي لا ينطبق عليها هذا الأمر هي التعديلات البسيطة جدًا مثل تصحيح الأخطاء الإملائية، والتي لا تتطلب فتح Issue ويمكن لأي شخص لديه صلاحية الدمج (Merge Access) في الريبو دمجها، حتى لو لم يكن مشرفًا على هذا الجزء.
+    - بالرغم من وجود هذا الاستثناء، إلا أننا نفضل عمليًا تشجيع جميع المساهمين على فتح Issue أولًا. بمعنى آخر، في حالة الشك حول ما إذا كان الاستثناء ينطبق، فمن الأفضل فتح Issue على أي حال.
+- إذا كان الـPull Request لا يحل المشكلة المشار إليها بالكامل، يمكنك تعديل المنشور الأصلي وتغيير "Resolve #IssueNumber" إلى "Addresses #IssueNumber" حتى لا يتم إغلاق الـIssue الأصلي تلقائيًا عند دمج الـPR.
+
+
+### التعديلات البسيطة
+
+التعديلات البسيطة، مثل تصحيح خطأ إملائي صغير، يمكن دمجها مباشرةً من قِبل أي شخص لديه صلاحية الدمج (Merge Access).  
+
+تأكد من علامة التبويب **"الملفات المعدلة"** (Files Changed) في الـPull Request للتأكد من أن اختبارات CI التلقائية قد نجحت.
+
+![تبويب "الملفات المعدلة" عند عرض الـPull Request على GitHub](../images/files-changed.png)
+
+![مؤشر "جميع الاختبارات نجحت" على الـPull Request في GitHub، مميزًا فوق زر الدمج](../images/all-checks-passed.png)
+
+
+### إصلاح Bug
+
+1. يجب أن تتم مراجعة إصلاح الBugs من قبل المشرف المسؤول عن المجال المرتبط، ويفضّل أن يكون نفس المشرف الذي وافق على الـIssue الخاصة بهذا الخطأ في البداية.
+2. يمكن استخدام تبويب **"الملفات المعدلة"** (Files Changed) في الـPull Request لإجراء مراجعة أولية والتأكد من أن الإصلاح تم تنفيذه كما نوقش في الـIssue.
+3. يجب اختبار الـPull Request محليًا كلما أمكن وكان ذلك مناسبًا. أداة GitHub CLI يمكن أن تساعد في تسهيل بعض الخطوات. (راجع المزيد في [نصائح وحيل](#نصائح-وحيل)).
+
+   - [ ] يجب أن يعالج الإصلاح المشكلة الأصلية بشكل كافٍ.
+   - [ ] يجب ألا يغير الإصلاح أي سلوكيات قائمة إلا إذا تم الاتفاق على ذلك في الـIssue.
+   - [ ] يجب ألا يؤثر الإصلاح سلبًا على أداء مكتبة p5.js.
+   - [ ] يجب ألا يؤثر الإصلاح على إتاحة مكتبة p5.js.
+   - [ ] يجب أن يلتزم الإصلاح بمعايير كتابة الشيفرة الحديثة في JavaScript.
+   - [ ] يجب أن ينجح الإصلاح في جميع الاختبارات التلقائية، وأن يتضمن اختبارات جديدة إذا كان ذلك مناسبًا.
+
+4. إذا كانت هناك حاجة إلى أي تعديلات إضافية، يمكن إضافة تعليقات مباشرة على الأسطر ذات الصلة كما هو موضح [هنا](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request#adding-line-comments-to-a-pull-request).
+
+   - يمكن أيضًا استخدام **مربع اقتراح** (Suggestion Block) لتقديم تعديلات محددة:  
+     ![زر "اقتراح التغيير" أثناء كتابة تعليق على كود في GitHub Pull Request](../images/suggest-change.png)  
+     ![تغيير مقترح يظهر داخل سياج كود مع وسم "suggestion"](../images/suggested-value-change.png)  
+     ![معاينة التغيير المقترح على شكل diff](../images/suggestion-preview.png)
+
+   - إذا كانت هناك تعديلات كثيرة مطلوبة، لا تضع تعليقات على كل سطر على حدة، بل استخدم الطريقة الموثقة [هنا](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request) لكتابة تعليق واحد يشمل عدة أسطر، ثم طلب التعديلات دفعة واحدة.
+   - إذا كانت التعليقات بغرض التوضيح أو النقاش فقط، اختر "Comment" بدلًا من "Request changes":  
+     ![خيار "Comment" محاط بدائرة داخل قائمة إنهاء المراجعة في GitHub](../images/comment-review.png)
+
+5. بمجرد اكتمال مراجعة الـPR وعدم الحاجة لأي تغييرات إضافية، يمكن للمشرف (Steward) وضع علامة **"Approved"** عبر اختيار "Approve" في الخطوة السابقة، مع أو بدون إضافة تعليقات إضافية. بعد ذلك يمكنه:
+
+   - طلب مراجعة إضافية من مشرف أو Maintainer آخر (اختياري).
+   - دمج الـPR إذا كان لديه صلاحية الدمج.
+   - أو طلب الدمج من أحد الـMaintainers.
+
+6. يجب استدعاء بوت [@all-contributors](https://allcontributors.org/docs/en/emoji-key) لإضافة أي مساهمين جدد إلى قائمة المساهمين في ملف README.md. يمكن تحديد نوع المساهمة في مكان `[contribution type]` كما هو موضح أدناه. قائمة أنواع المساهمات المتاحة بالكامل موجودة في الرابط أعلاه.
+
+```
+@all-contributors please add @[GitHub handle] for [contribution type]
+```
+
+
+### ميزة جديدة او تحسين ميزة موجودة
+
+عملية مراجعة ودمج الـPull Request الخاصة بالميزات الجديدة أو تحسين الميزات القائمة تشبه بشكل كبير عملية مراجعة إصلاح الأخطاء (Bug Fixes)، مع فارق واحد مهم:
+
+- يجب أن تتم مراجعة الـPull Request والموافقة عليها من قبل **مشرفين** أو **Maintainers** على الأقل قبل أن يتم دمجها.
+
+
+
+### Dependabot
+
+طلبات الـPull Requests من Dependabot عادةً لا تكون مرئية إلا لمسؤولي الريبو، لذلك إذا لم تكن مسؤولاً، يمكنك تجاهل هذا القسم.
+
+- يمكن دمج طلبات Dependabot مباشرةً إذا كان التحديث هو تحديث **Patch** وفقًا [لـSemVer](https://semver.org/) واجتاز الفحوصات التلقائية (CI).
+- طلبات Dependabot التي تحتوي على تحديث **Minor** يمكن عادةً دمجها مباشرةً طالما اجتازت الفحوصات التلقائية (CI). يُفضَّل إجراء مراجعة سريعة على سجل التغييرات (changelog) الخاص بالتبعية المحدثة.
+- طلبات Dependabot التي تحتوي على تحديث **Major** قد تؤثر على عملية البناء (Build Process) أو على وظائف p5.js نفسها. في هذه الحالة، يُفضَّل أن يقوم المراجع بقراءة سجل التغييرات (changelog) من الإصدار الحالي إلى الإصدار المستهدف إن أمكن، بالإضافة إلى اختبار التغييرات محليًا للتأكد من أن كل شيء يعمل بشكل سليم وإجراء أي تعديلات مطلوبة في حالة وجود تغييرات جوهرية (Breaking Changes) في التبعية.
+- العديد من التبعيات تقوم بزيادة رقم الإصدار الرئيسي (Major Version) فقط لأنها توقفت عن دعم الإصدارات القديمة جدًا من Node.js. في كثير من الحالات، تحديث النسخ الرئيسية (Major) لا يعني بالضرورة وجود تغييرات جوهرية (Breaking Changes) في واجهة برمجة التطبيقات (API) الخاصة بالتبعية.
+
+---
+
+
+## عملية البناء
+
+هذا القسم لن يغطي إعدادات البناء العامة أو الأوامر، بل سيتناول التفاصيل الخاصة بما يحدث خلف الكواليس. يُرجى الاطلاع على [إرشادات المساهمة](contributor_guidelines.md#working-on-p5js-codebase) للحصول على معلومات أكثر تفصيلًا حول عملية البناء.
+
+الملف `Gruntfile.js` يحتوي على تعريفات البناء الرئيسية الخاصة بـp5.js. من بين الأدوات المختلفة المستخدمة لبناء المكتبة والتوثيق: Grunt وBrowserify وYUIDoc وESLint وBabel وUglify وMocha، وغيرها. قد يكون من المفيد أن نبدأ بمهمة `default` ثم نعود للخلف لفهم باقي المهام. في هذه المرحلة، قد يكون من المفيد فتح ملف `Gruntfile.js` أثناء قراءة الشرح أدناه.
+
+
+### مهمة البناء الأساسية
+
+```
+grunt.registerTask('default', ['lint', 'test']);
+```
+
+عند تشغيل الأمر `grunt` أو السكربت `npm test`، يتم تنفيذ المهمة الافتراضية التي تتكون من `lint` ثم `test`.
+
+#### مهمة `lint`
+
+```
+grunt.registerTask('lint', ['lint:source', 'lint:samples']);
+```
+
+مهمة `lint` تتكون من مهمتين فرعيتين: `lint:source` و`lint:samples`. المهمة `lint:source` تنقسم أيضًا إلى ثلاث مهام فرعية أخرى: `eslint:build` و`eslint:source` و`eslint:test`، والتي تستخدم ESLint لفحص سكربتات البناء والكود المصدري وكود الاختبارات.
+
+مهمة `lint:samples` تقوم أولًا بتشغيل المهمة `yui`، والتي تتكون من `yuidoc:prod` و`clean:reference` و`minjson`، حيث تقوم باستخراج التوثيق من الكود المصدري إلى مستند JSON، ثم حذف الملفات غير المستخدمة من الخطوة السابقة، وأخيرًا ضغط ملف JSON الناتج إلى `data.min.json`.
+
+بعد ذلك في `lint:samples` يتم تشغيل `eslint-samples:source`، وهي مهمة مخصصة مكتوبة داخل [../tasks/build/eslint-samples.js](../tasks/build/eslint-samples.js)؛ تقوم هذه المهمة بتشغيل ESLint لفحص أكواد الأمثلة التوثيقية للتأكد من اتباعها لنفس معايير كتابة الكود الخاصة بـp5.js (تُشغّل `yui` أولًا لأننا نحتاج إلى ملف JSON ليتم بناؤه قبل التحقق من الأمثلة).
+
+#### مهمة `test`
+
+```js
+grunt.registerTask('test', [
+  'build',
+  'connect:server',
+  'mochaChrome',
+  'mochaTest',
+  'nyc:report'
+]);
+```
+
+أولًا، لنلقِ نظرة على مهمة `build` ضمن `test`.
+
+```js
+grunt.registerTask('build', [
+  'browserify',
+  'browserify:min',
+  'uglify',
+  'browserify:test'
+]);
+```
+
+المهام التي تبدأ بـ`browserify` مُعرفة في الملف [../tasks/build/browserify.js](../tasks/build/browserify.js). جميعها تتبع خطوات متشابهة مع بعض الاختلافات البسيطة. هذه هي الخطوات الأساسية لبناء مكتبة p5.js كاملة من ملفات الكود المصدري المتعددة في ملف واحد:
+
+- `browserify` يبني p5.js، بينما `browserify:min` يبني ملفًا وسيطًا ليتم ضغطه في الخطوة التالية. الفرق بين `browserify` و`browserify:min` هو أن الأخير لا يحتوي على البيانات اللازمة لعمل FES.
+- `uglify` يأخذ الملف الناتج عن `browserify:min` ويضغطه إلى الملف النهائي `p5.min.js` (إعدادات هذه الخطوة موجودة في `Gruntfile.js` الرئيسي).
+- `browserify:test` يبني نسخة مطابقة لـp5.js الكاملة مع إضافة كود مخصص لتغطية الاختبارات (باستخدام [Istanbul](https://istanbul.js.org/)).
+
+أولًا، يتم استبدال أكواد `fs.readFileSync()` الخاصة بـnode.js بمحتوى الملف الفعلي باستخدام `brfs-babel`. تُستخدم هذه الخطوة بشكل رئيسي في كود WebGL لإدراج أكواد الـshader المخزنة في ملفات منفصلة.
+
+بعد ذلك، يتم تحويل الكود المصدري وجميع التبعيات من `node_modules` باستخدام Babel ليتوافق مع متطلبات [Browserslist](https://browsersl.ist/) المحددة في `package.json`، وكذلك لتحويل أوامر الاستيراد `import` من ES6 إلى `require()` التي يفهمها `browserify`. هذا يُتيح لنا استخدام الصياغات الأحدث في ES6 وما بعدها بدون القلق من توافق المتصفحات.
+
+بعد التجميع، وقبل كتابة الكود المجمع إلى الملف، يتم تمريره عبر `pretty-fast` لتنظيف التنسيق وجعل المخرجات النهائية أكثر اتساقًا (نتوقع أن يكون كود p5.js قابلاً للقراءة والتفحص عند الحاجة).
+
+بعض التفاصيل الصغيرة الأخرى لم تُذكر هنا؛ يمكنك مراجعة ملف تعريف بناء `browserify` للحصول على تفاصيل أدق.
+
+```
+connect:server
+```
+
+هذه الخطوة تقوم بتشغيل خادم محلي يستضيف ملفات الاختبار والملفات المصدرية المبنية حتى يتم تشغيل الاختبارات الآلية في Chrome.
+
+```
+mochaChrome
+```
+
+هذه الخطوة مُعرفة في [../tasks/test/mocha-chrome.js](../tasks/test/mocha-chrome.js). تقوم بتشغيل نسخة رأسية (headless) من Chrome باستخدام Puppeteer وتنفذ الاختبارات المرتبطة بملفات HTML داخل مجلد `./test`، والتي تشمل اختبار النسخة غير المضغوطة والمضغوطة من المكتبة مقابل مجموعات اختبارات الوحدة، وكذلك اختبار جميع أمثلة التوثيق.
+
+```
+mochaTest
+```
+
+تختلف هذه الخطوة عن `mochaChrome` لأنها تعمل داخل بيئة node.js بدلاً من Chrome وتختبر مجموعة صغيرة فقط من الميزات في المكتبة. معظم ميزات p5.js تتطلب بيئة متصفح، لذلك يُفضل توسيع هذه الاختبارات فقط للميزات التي لا تحتاج متصفح.
+
+```
+nyc:report
+```
+
+أخيرًا، بعد اكتمال جميع عمليات البناء والاختبار، تقوم هذه الخطوة بجمع تقرير تغطية الاختبارات أثناء تنفيذ `mochaChrome` وتطبع بيانات التغطية إلى الطرفية. الغرض الأساسي من تغطية الاختبارات في p5.js هو المتابعة والحصول على بيانات إضافية؛ الوصول إلى 100% تغطية ليس هدفًا.
+
+وهكذا نكون قد غطينا المهمة الافتراضية في إعدادات `Gruntfile.js`!
+
+
+### المهام المتنوعة
+
+يمكن تشغيل أي خطوة مباشرة باستخدام:
+
+```
+npx grunt [الخطوة]
+```
+
+هناك أيضًا بعض المهام الإضافية التي لم يتم ذكرها أعلاه لكنها قد تكون مفيدة في بعض الحالات.
+
+```
+grunt yui:dev
+```
+
+هذه المهمة تقوم بتشغيل عمليات بناء التوثيق والمكتبة التي ذُكرت سابقًا، ثم تقوم بتشغيل خادم ويب محلي يعرض نسخة مشابهة وظيفيًا لصفحة التوثيق المرجعي التي تجدها على الموقع، على الرابط:  
+[http://localhost:9001/docs/reference/](http://localhost:9001/docs/reference/).  
+بعد ذلك، تراقب الكود المصدري لاكتشاف أي تغييرات، وتقوم بإعادة بناء التوثيق والمكتبة بشكل تلقائي.
+
+تعتبر `grunt yui:dev` مفيدة جدًا عند العمل على التوثيق الداخلي (inline documentation) لأنه لن يكون عليك نسخ الملفات المبنية من ريبو p5.js إلى ريبو p5.js-website المحلي وإعادة بناء الموقع في كل مرة تقوم فيها بتغيير. بدلًا من ذلك، يمكنك معاينة تغييراتك مباشرة عبر هذه النسخة المبسطة من صفحة التوثيق المرجعي في المتصفح. بهذه الطريقة، يمكنك أيضًا التأكد من أن التغييرات التي قمت بها ستظهر بشكل صحيح على الموقع لاحقًا.
+
+تنبيه: هذه الطريقة مخصصة فقط للتعديلات على التوثيق الداخلي (inline documentation)، أما التغييرات على صفحة التوثيق المرجعي نفسها (بما في ذلك التنسيقات والتخطيط)، فيجب تنفيذها واختبارها في ريبو الموقع (p5.js-website repository).
+
+---
+
+```
+grunt watch
+grunt watch:main
+grunt watch:quick
+```
+
+مهام `watch` تقوم بمراقبة مجموعة من الملفات لاكتشاف التغييرات، ثم تقوم بتشغيل المهام المرتبطة بها لبناء التوثيق أو المكتبة بناءً على الملفات التي تم تغييرها.  
+كل هذه المهام تؤدي نفس الفكرة، مع اختلاف نطاق العمل فقط.
+
+- المهمة `watch` تقوم بتشغيل جميع عمليات البناء والاختبار، بشكل مشابه للمهمة الافتراضية `default`، عند اكتشاف تغييرات في الكود المصدري.
+- المهمة `watch:main` تقوم ببناء المكتبة وتشغيل الاختبارات، لكنها **لا تقوم بإعادة بناء التوثيق** عند اكتشاف تغييرات.
+- المهمة `watch:quick` تقوم فقط ببناء المكتبة عند اكتشاف تغييرات، بدون تشغيل أي اختبارات أو إعادة بناء التوثيق.
+
+اعتمادًا على طبيعة العمل الذي تقوم به، اختيار المهمة الأنسب (الأقل شمولًا) يمكن أن يوفر عليك الوقت، بدلاً من تشغيل عملية البناء يدويًا بعد كل تعديل.
+
+---
+
+## عملية الـRelease
+
+يرجى الاطلاع على الملف [release_process.md](release_process.md).
+
+---
+
+
+## نصائح وحيل
+
+أحيانًا، قد يصبح عدد الـIssues والـPull Requests التي تحتاج إلى مراجعة أمرًا مرهقًا بعض الشيء. وبينما نحاول وضع عمليات تجعل الأمور أسهل، إليك بعض النصائح والحيل التي يمكنك الاستفادة منها عند مراجعة الـIssues والـPull Requests.
+
+
+### قوالب الردود
+
+ميزة مفيدة في GitHub يمكنك استخدامها هي ميزة [الردود المحفوظة (Saved Replies)](https://docs.github.com/en/get-started/writing-on-github/working-with-saved-replies/about-saved-replies)، والتي تكون متاحة عند كتابة رد على أحد الـIssues أو الـPull Requests. بعض الإجراءات التي تم ذكرها في العمليات السابقة تتطلب الرد على الـIssues أو الـPull Requests بردود متشابهة جدًا (مثل توجيه الأسئلة إلى المنتدى، أو الموافقة على Issue للإصلاح، وغيرها)، واستخدام الردود المحفوظة يجعل هذه المهام أسرع وأكثر كفاءة.
+
+فيما يلي بعض الردود المحفوظة التي يستخدمها مسؤولو p5.js. يمكنك استخدامها بنفسك أو إنشاء ردودك الخاصة!
+
+
+##### إغلاق: لا يمكن إعادة الإنتاج
+
+> لم نتمكن من إعادة إنتاج هذه المشكلة، لكن لا تتردد في إعادة فتحها إذا تمكنت من توفير نموذج كود يوضح المشكلة. شكرًا!
+
+
+##### إغلاق: بحاجة إلى كود
+
+> سأقوم بإغلاق هذا للتنظيم. يرجى إعادة فتحه إذا تمكنت من تقديم نموذج كود يوضح المشكلة. شكرًا!
+
+
+##### إغلاق: استخدم المنتدى
+
+> الـIssues على GitHub هنا مخصصة للأخطاء والمشاكل المتعلقة بمكتبة p5.js نفسها. بالنسبة للأسئلة حول كتابة الأكواد الخاصة بك أو الاختبارات أو اتباع الشروحات التعليمية، فإن [المنتدى](https://discourse.processing.org/) هو المكان الأفضل للنشر. شكرًا!
+
+
+##### إغلاق: GSOC
+
+> شكرًا! أفضل مكان لمناقشة مقترحات GSOC هو [المنتدى](https://discourse.processing.org/c/summer-of-code).
+
+
+##### إغلاق: الإتاحة
+
+> لا نرى اهتمامًا كبيرًا بهذه الميزة، كما أنه ليس لدينا تفسير واضح لكيفية [توسيع الإتاحة](./access.md)، لذا سأغلق هذا في الوقت الحالي. إذا كان من الممكن إضافة بيان حول الوصول إلى الطلب، فلا تتردد في إعادة فتحه.
+
+> لم نرَ تفسيرًا إضافيًا حول كيفية [توسيع الإتاحة](./access.md)، لذا سأغلق هذا الطلب حاليًا. إذا تمت إضافة بيان وصول أكثر تفصيلًا إلى طلب الميزة، فلا تتردد في إعادة فتحه. شكرًا!
+
+
+##### إغلاق: مكتبة إضافية
+
+> نعتقد أن هذه الوظيفة تتجاوز نطاق واجهة p5.js (نحاول الحفاظ عليها بأقل حد ممكن)، لكنها قد تكون نقطة انطلاق رائعة لمكتبة إضافية. يمكنك الاطلاع على الوثائق هنا لمعرفة كيفية إنشاء مكتبة إضافية: [إنشاء مكتبة إضافية](./creating_libraries.md)
+
+
+##### إغلاق PR: يجب فتح Issue أولًا
+
+> شكرًا لك. للتذكير، يجب فتح Issue قبل فتح Pull Request وربط الـPR بهذه الـIssue. هذا ضروري لتتبع التطوير والحفاظ على وضوح النقاش. شكرًا!
+
+
+##### الموافقة على Issue للإصلاح
+
+> يمكنك المضي قدمًا في إصلاحها. شكرًا.
+
+
+##### دمج PR
+
+> يبدو جيدًا. شكرًا!
+
+
+### GitHub CLI
+
+مراجعة الـPull Requests المعقدة يمكن أن تكون صعبة، خصوصًا عند الحاجة لاستخدام أوامر Git معقدة للحصول على نسخة الكود الخاصة بالـPR محليًا لاختبارها. لحسن الحظ، أداة [GitHub CLI](https://cli.github.com/) توفر حلًا بسيطًا وفعالًا لهذه المشكلة، بالإضافة إلى توفير العديد من الميزات الأخرى.
+
+#### الخطوات الأساسية
+
+1. **تثبيت الأداة وتسجيل الدخول**  
+   بعد تثبيت GitHub CLI وتسجيل الدخول إلى حسابك على GitHub.
+
+2. **جلب الـPR محليًا**  
+   يمكنك مراجعة أي Pull Request محليًا عبر الأمر التالي:
+   ```
+   gh pr checkout [pull_request_id]
+   ```
+   هذا الأمر يقوم تلقائيًا بـ:
+   - جلب (fetch) الفرع من الريبو البعيد (remote fork).
+   - إنشاء فرع محلي بنفس اسم الفرع في الـPR.
+   - التبديل إلى الفرع الجديد.
+
+3. **العودة إلى الفرع الرئيسي**  
+   بعد الانتهاء من المراجعة، يمكنك العودة إلى الفرع الرئيسي عبر:
+   ```
+   git checkout main
+   ```
+
+#### إضافة تعليقات من خلال الـCLI
+
+يمكنك حتى **إضافة تعليقات على الـPR** مباشرة من خلال الـCLI دون الحاجة لفتح صفحة الـPR في المتصفح، مما يوفر وقتك ويسهل عملية المراجعة.
+
+#### أوامر إضافية
+
+أداة GitHub CLI تحتوي على **مجموعة كبيرة من الأوامر** المفيدة لإدارة الريبو والـIssues والـPull Requests، وقد تجد بعضها مناسبًا حسب طريقة عملك.
+
+#### الخلاصة
+
+بغض النظر عن أسلوبك في العمل، فإن GitHub CLI أداة قوية يُنصح بوجودها في بيئة العمل الخاصة بك لتسهيل التعامل مع الـRepositories بشكل أكثر كفاءة.
+
+
+أكيد، إليك الترجمة مع **تنسيق أوضح** وتحسين في العرض:
+
+---
+
+### إدارة الإشعارات
+
+بدلًا من مراقبة تبويب "الـIssues" أو "الـPull Requests" يدويًا في الريبو بحثًا عن أي جديد، يمكنك **"متابعة" (Watch)** الريبو بسهولة عبر الضغط على زر **"Watch"** الذي يحتوي على أيقونة العين في أعلى صفحة الريبو، بجانب اسم الريبو.
+
+![صورة مقصوصة لزاوية صفحة ريبو على GitHub، تعرض أزرارًا في الأعلى من اليسار لليمين: Sponsor، Watch، Fork، Starred.](images/github-repo-metrics.png)
+
+### ماذا يحدث عند المتابعة (Watch)
+
+عند متابعة الريبو، ستصلك إشعارات بكل الأحداث التي اشتركت فيها، مثل:
+
+- **فتح Issues جديدة.**
+- **فتح Pull Requests جديدة.**
+- **الإشارة إليك (mentions) باسم المستخدم الخاص بك.**
+- **وغيرها من الأنشطة المرتبطة بالريبو.**
+
+كل هذه الإشعارات ستظهر في **[صفحة الإشعارات](https://github.com/notifications)** الخاصة بك على GitHub، والتي يمكنك من خلالها:
+
+- **وضع علامة "مقروء" على الإشعارات.**
+- **أو تجاهل الإشعارات مثل البريد الوارد.**
+
+### إشعارات البريد الإلكتروني
+
+في بعض الحالات، قد يصلك أيضًا **إشعارات عبر البريد الإلكتروني** حول أنشطة الريبو الذي تتابعه.  
+يمكنك تخصيص هذه الإشعارات (أو حتى إيقافها بالكامل) من خلال [صفحة إعدادات الإشعارات](https://github.com/settings/notifications).
+
+### نصيحة للإعداد الأولي
+
+لضمان توازن جيد بين متابعة النشاط وعدم التشتت بسبب كثرة الإشعارات، يُفضل أن يقوم المسؤولون (stewards) بمتابعة هذا الريبو بهذه الإعدادات:
+
+- متابعة (Watch) **الـIssues والـPull Requests فقط**.
+- ضبط إشعارات البريد الإلكتروني إلى:  
+  **"المشاركة (Participating)" و"الإشارات (@mentions)" و"مخصصة (custom)"**.