المساهمة في تطوير SPIP

التسجيل في ورشة git.spip.net

لاقراح اي تعديل على git.spip.net يجب:

-# قراءة بيان الترحيب من SPIP واذا وافقتم عليه:
-# التسجيل في منتدى الحوار
-# طلب إذن الدخول الى الورشة.

قواعد المساهة

1. إنشاء تذكرة في https://git.spip.net/spip/spip/issues قبل إرسال اقتراح (نسميه طلب تعديل او PR [1]).
2. إنشاء نسخة شخصة من المستودع (fork او تفرع بلغة git) وإنشاء فرع فيه اسمه issue_xxx حيث xxx هو رقم التذكرة المتاسبة للاقراح.
3. يجب على رسائل التسليم (commit بلغة git) العائدة للفرع issue_xxx ان تتوافق مع Écrire un message de commit. ويجب على نص الرسالة ان يكون واضحاً ومفصلاً: وصف المسألة قيد المعالجة والتحسينات او التصحيح الداخلة عليها.
4. يجب أيضاً إضافة سطر في ملف CHANGELOG العائد للمستودع وذلك بتسليم مختلف عن تسليم التصحيح في الفرع نفسه لتجنب التضارب لدى دمج المقترح. وأخيراً، يجب ان تكون مجموعة التسليمات خطية اي دون تسليم دمج (merge بلغة git).
5. عند الانتهاء من العمل على الفرع، يتم طلب الدمج في واجهة الورشة بالنقر على زر Create merge request وذلك من داخل الفرع الذي تم فيه التعديل. ويجب التأكد من ان طلب الدمج لا يحتوي على اي تضارب. واذا وجد تضارب ما يجب تصحيح بأمري git rebase وgit force push. ثم يتم دراسة الطلب واختباره من قبل فريق التطوير. ولا يتم دمج التسليم الا لدى موافقة عضوين من الفريق على الأقل.
6. بعد الدمج، يمكن حذف الفرع issue_xxx.

وتطبق هذه القواعد على اعضاء فريق التطوير أيضاً الذين يجب دائماً ان يقدمون طلب تعديل قبل إدخال برمجيات على الفرع الرئيسي (master بلغة git). الا انه اذا كان التعديل طفيف وكان الشخص الذي اقترحه متأكد من انه ليس لهذا التعديل تأثير ضار يمكن ارساله مباشرة الى الفرع الرئيسي بشرط متابعة صيانته. يمكن لهلاء الأعضاء انشاء الفرع مباشرة في المستودع دون الحاجة الى انشاء تفرع.

بخصوص التسليمات التقليدية وملفات CHANGELOG

يرجى قراءة المقالين التاليين:
– Écrire un message de commit
– Tenir un CHANGELOG

بخصوص دمج الفرع

نحن في مجتمع SPIP لا تستخدم تسليمات دمج الفروع. نفضل استخدام التحويل (rebase بلغة git) ثم التقدم السريع وذلك للحفاظ على تأريخ خطي.

# داخل الفرع المطلوب دمجه
$ git rebase master
# الانتقال الى الفرع الرئيسي
$ git switch master
$ git merge branch _to_merge

في واجهة GitLab، النقر على «Rebase and fast forward».

والأمر نفسه لطلب التعديل.

لذلك ستكون إعدادات git العامة هي التالية:

$ git config --global pull.ff only
$ git config --global pull.rebase = true
$ git config --global merge.ff = true

قاعدة الانتقاء (cherry-pick)

عموماً، لدى اختيار الانتقاء (git cherry-pick) يجب استخدام العامل -x.

قواعد العرض والكتابة

الرجوع الى قواعد التطوير

قواعد البرمجة

التفكير

قبل برمجة اي وظيفة يجب التفكير ملياً...

– في الطريقة والخوارزمي المستخدم لتنفيذها: برمجة خفيفة واداء ومتانة (عدم التردد في تنفيذ حسابات مباشرة للتأكد من البرمجة)
– في التوافق مع المشروع: هل يمكن نقلها، هل هي آمنة، هل هي مرنة
– في التأثير على الوظائف الاخرى: التعديلات والاضافات المطلوب ادخالها على الوظائف الموجودة
– في الموقع «الطبيعي» لهذه الوظيفة ضمن المشروع: في ما يتعلق بواجهة الاستخدام والملفات الضرورية الخ.

عدم تجاهل التحليل وتوحيد الاوامر البرمجية (بواسطة دالات لا سيما في الملفات التي يجب ادراجها). في المقابل تجنب الملفات المدرجة التي تحتوي على رموز برمجية خارج الدالات (الا اذا كان «طبيعياً» ومقصوداً).

التسمية

بشكل عام، يجب ان لا تكون الأسماء قصيرة جداً ولا طويلة جداً وان تدل على معناها بوضوح. هذه القاعدة مهمة جداً خاصة للمتغيرات الشاملة (global) التي يتم استخدامها في اكثر من ملف واحد ودالة واحدة. أما في ما يتعلق بالمتغيرات المحلية (local) المستخدمة في دالة واحدة، فالقاعدة اكثر مرونة. فيمكن مثلاً استخدام أسماء مكونة من حرف واحد للحصول على تركيبات متراصة. لاحظ انه في كل لغات البرمجة، تقليدياً، هناك عدد من الحروف المرتبطة بأنواع من الاستخدامات (مثلاً: i$ وj$ لعدادات الحلقات وn$ للتعداد وt$ للدلالة على لحظة او فترة بالثواني...). فاتباع هذه التقاليد يجنب القارئ الشعور بالغربة.

الاختبار

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