التطوير والمساهمة
قواعد عملية قبل أي تعديل
- افهم ترتيب الأنظمة قبل التعديل، خصوصًا في التخطيط والرندر والتفاعل.
- لا تكسر
Reflectionللأنواع العامة بلا سبب واضح. - اختبر التعديل على الحزمة الحية الحالية أو على فحوص مصدرية مكافئة، وليس على اختبارات الوحدة فقط.
- عند إضافة وحدة جاهزة جديدة، وفّر:
- واجهة مكوّن واضحة
- إضافة مستقلة
- رسائل أحداث عند الحاجة
- عرضًا قابلًا للتشغيل عندما يحمل الفرع أمثلة تشغيلية فعلية
- توثيقًا في README وهذا الكتاب
مكان التوثيق والأمثلة
- أضف أي صفحة شرح جديدة في
docs/src/enوdocs/src/arمعًا. - ضع مثال التشغيل الجديد داخل الـ crate التي تملك الميزة.
- اترك الجذر
examples/فقط للعروض المجمعة المتكاملة عندما تكون موجودة فعلًا في الفرع. - اتبع القواعد المذكورة في قواعد تحرير التوثيق.
- اتبع اصطلاحات التسمية عند تقسيم الوحدات الداخلية أو إعادة تسميتها.
- راجع خريطة الصيانة وقواعد المعمارية قبل نقل حدود الملكية أو التبعيات.
- راجع اتفاقيات بنية الوحدات الجاهزة وحدود محرك التخطيط قبل تقسيم subsystem كبيرة.
- راجع مسار تأليف التوثيق للخطوات الدقيقة المتعلقة باللغتين و
rustdoc. - استخدم قائمة مراجعة التوثيق قبل الدمج.
أسلوب الكود داخل المشروع
- فضّل المكونات الصغيرة والأنظمة الواضحة
- اجعل السلوك البصري مدفوعًا عبر
UNodeوUBorderوUInteractionColors - تجنب الآثار الجانبية المفاجئة خارج الجدولة المقصودة
فروع العمل المقترحة
feat/<name>للميزاتfix/<name>للإصلاحاتdocs/<name>للتوثيق