هذا المستودع يحوي مقترحات التصميم الرسمية (RFCs) للغة ص — وهي العملية التي تمرّ بها أي تغييرات «جوهرية» في اللغة، أو المكتبة القياسية، أو الأدوات الرسمية، أو عملية التطوير نفسها، قبل اعتمادها.
هذه العملية مستوحاة من نظام RFC الخاص بلغة Rust ومُكيَّفة لطبيعة لغة ص (العربية أولاً، والمعمارية المدفوعة بالبيانات).
عمليّة الـ RFC تهدف إلى توفير مسار متّسق ومُتحكَّم به لإدخال ميزات جديدة إلى اللغة، بحيث يكون لجميع أصحاب المصلحة فرصةٌ للمشاركة في توجيه تطوّرها.
- متى تحتاج إلى RFC؟
- قبل كتابة RFC
- العملية خطوة بخطوة
- دورة حياة الـ RFC
- مراجعة المقترحات
- تنفيذ RFC مُعتمَد
- تأجيل المقترحات
- الرخصة
تحتاج إلى اتّباع هذه العملية إن كنت تنوي إجراء تغيير جوهري (substantial) على لغة ص أو منظومتها. ما معنى «جوهري»؟ يتطوّر التعريف مع الوقت، لكنه يشمل عموماً:
- أي كلمة مفتاحية / توجيه (
@) / نمط مطابقة جديد، أو تغيير في الصياغة. - أي تغيير في دلالات اللغة قد يكسر برامج
.صقائمة (التوافق الخلفي). - إضافة أو تعديل نوع مدمج أو سلوك نظام الأنواع (مثل التحوّل نحو الأنواع التدريجية).
- تغييرات في نظام الوحدات/الاستيراد أو نموذج التزامن أو نموذج الذاكرة.
- إضافة نظام داخلي جديد يؤثّر على واجهة المستخدم للّغة (لا مجرد إعادة هيكلة داخلية).
- تغييرات في المكتبة القياسية تُضيف واجهات عامّة جديدة واسعة الأثر.
أمّا ما لا يحتاج إلى RFC فيشمل: إصلاحات الأخطاء، تحسينات الأداء غير المرئية، إضافة دوال مضمنة صغيرة ضمن وحدة قائمة، تحسين رسائل الأخطاء، والتوثيق. هذه تُقدَّم عبر Pull Request عادي في المستودع المعني.
عند الشكّ: افتح نقاشاً (Discussion) أو Issue واسأل قبل أن تبدأ. توفيراً لجهدك، الأفضل أن تتأكّد أنّ الفكرة مرغوبة مبدئياً.
القبول الاجتماعي للفكرة أهمّ من جودة الصياغة. مقترح ممتاز الصياغة لكنه غير مرغوب سيُرفض، ومقترح بفكرة محبوبة لكن صياغته ركيكة يُمكن تحسينه.
قبل الاستثمار في كتابة RFC كامل:
- استكشف الفكرة في Discussions لقياس مدى الاهتمام واكتشاف الاعتراضات المبكّرة.
- ابحث في المقترحات السابقة (المفتوحة والمغلقة) تفادياً للتكرار.
- راجع المعمارية المدفوعة بالبيانات للغة ص — كثير من التغييرات تبدأ من
language-truth/(مصدر الحقيقة) ثم تُولَّد بقيّة الكود.
لكي تُدخِل ميزةً جوهرية إلى لغة ص:
-
انسخ (Fork) هذا المستودع:
sadlang/rfcs. -
انسخ القالب
0000-template.mdإلى المجلد المناسب لنطاق مقترحك (لا ترقّمه بعد — اترك0000؛ الرقم يُسنَد عند الدمج). استخدم اسماً عربياً وصفياً بـ kebab-case. اختر المجلد حسب النطاق:- اللغة:
text/0000-اسم-وصفي.md(مثلtext/0000-أنواع-تدريجية.md). - أداة رسمية (LSP، المنسّق، sadinfo…):
tools/<اسم-الأداة>/0000-اسم-وصفي.md. - إضافة VS Code:
extensions/<اسم-الإضافة>/0000-اسم-وصفي.md.
الأدوات والإضافات متعددة، لذا لكل أداة/إضافة مجلّد فرعيّ خاصّ بها. الترقيم عامّ وفريد على مستوى المستودع كلّه = رقم الـ PR في مستودع
sadlang-rfcsنفسه (لا في مستودع كود اللغة/الأداة/الإضافة). بما أنّ كل المقترحات تُدمَج في هذا المستودع الواحد، فمصدر الترقيم واحد ولا يقع أي تضارب. التفاصيل فيtools/README.mdوextensions/README.md. - اللغة:
-
املأ القالب. اعتنِ بالتفاصيل: المقترحات التي تتجاهل الدوافع الحقيقية أو تُغفل الأثر على الأنظمة المتشابكة (المفسّر، المترجم، الأخطاء، التوثيق) تُستقبَل بفتور. المطلوب جودة تكفي لتكون أساساً للتنفيذ لاحقاً.
-
افتح Pull Request. سيُمثّل الـ PR ساحة النقاش والمراجعة العامّة. عدِّل المقترح استجابةً للملاحظات — التعديلات الجوهرية بإضافة commits جديدة (لا فرض/force-push) لتُحفظ سلسلة النقاش.
-
ابنِ التوافق. المؤلّف مسؤول عن جمع الدعم والوصول إلى إجماع المجتمع وفريق اللغة.
-
فترة التعليق الأخير (FCP): حين ينضج النقاش، يُعلن فريق اللغة فترة تعليق أخيرة (عادةً ~10 أيام) قبل اتّخاذ القرار، لإتاحة فرصة أخيرة للاعتراض.
-
القرار: يُدمَج المقترح (مقبول)، أو يُغلَق (مرفوض)، أو يُؤجَّل (postponed).
فكرة → Discussion → Pull Request → نقاش ومراجعة → FCP → ┬→ مقبول (دمج) → تتبُّع التنفيذ
├→ مرفوض (إغلاق)
└→ مؤجَّل (postponed)
- مقبول (Accepted/Merged): يُسنَد للمقترح رقم (رقم الـ PR)، ويُدمَج في
text/. القبول لا يعني أنّ الميزة ستُنفَّذ فوراً، بل أنّ المبدأ تمّت الموافقة عليه ويُفتح Issue لتتبّع التنفيذ. - مرفوض (Rejected/Closed): يُغلَق الـ PR مع توثيق سبب الرفض في النقاش.
- مؤجَّل (Postponed): فكرة وجيهة لكنّ توقيتها غير مناسب؛ تُغلَق مع وسم
postponedلإعادة النظر لاحقاً.
- يراجع فريق لغة ص المقترحات دورياً، لكنّ المراجعة مفتوحة للجميع.
- قد يستغرق ردّ الفريق وقتاً؛ لا يعني الصمت الرفض. إن مرّ وقت طويل دون تفاعل، يُسمح بالتذكير اللطيف في الـ PR.
- المعايير: وضوح الدافع، التوافق الخلفي، الأثر على الأنظمة المتشابكة، جدوى التنفيذ، والاتّساق مع فلسفة اللغة (العربية أولاً، البساطة، المعمارية المدفوعة بالبيانات).
- قبول RFC ليس أولوية تنفيذ مضمونة ولا التزاماً من أي مساهم بالعمل عليه.
- يُفتح Issue تتبُّع في المستودع الرئيسي لربط المقترح بحالة تنفيذه.
- يُرحَّب بأن يتولّى مؤلّف المقترح تنفيذه، لكنّ ذلك ليس شرطاً.
- التنفيذ يتبع قواعد المشروع الرئيسي (الطبقات، مصدر الحقيقة، الاختبار في المفسّر والمترجم معاً، التوثيق ثنائي اللغة).
«مقبول» حالةُ المقترح، لا حالةُ التنفيذ. لتمييزهما، كل ملف RFC يحمل في
رأسه حقل الحالة يُحدَّث عبر PR صغير على الملف كلما تقدّم العمل:
| الحالة | المعنى | أين يُتابَع التقدّم |
|---|---|---|
| مقترَح | الـ PR في sadlang-rfcs ما زال مفتوحاً للنقاش |
الـ PR نفسه |
| مقبول | دُمج المقترح؛ المبدأ مُعتمَد، التنفيذ لم يبدأ | Issue التتبُّع |
| قيد التنفيذ | وكيل/مطوّر يعمل عليه الآن (= العمل مَحجوز/claimed) | Issue التتبُّع في مستودع الكود |
| مكتمل | نُفّذ ودُمج في مستودع الكود واجتاز اختباراته | — (مُغلَق) |
| مرفوض / مؤجَّل | لن يُنفَّذ (الآن) | — |
- حقل
الحالةفي رأس الملف هو مصدر الحقيقة السريع: نظرة واحدة تكشف أيّ مقترح ما زال مفتوحاً وأيّه اكتمل — دون فتح كل Issue. - Issue التتبُّع (في مستودع الكود المعنيّ، رابطه في رأس الملف) يحمل التفاصيل والحالة اللحظية للتنفيذ. إغلاقه = اكتمال، وعندها تُحدَّث الحالة إلى مكتمل.
- في نظام الوكلاء المتوازين: انتقال الحالة إلى قيد التنفيذ هو حَجْز العمل (claim) الذي يمنع وكيلاً آخر من البدء على المقترح نفسه.
تُؤجَّل بعض المقترحات الوجيهة لأسباب توقيت أو نضج المنظومة. تُغلَق هذه بوسم
postponed، وتبقى مرجعاً قابلاً لإعادة الفتح حين يحين وقتها.
هذا المستودع مرخّص بموجب رخصة MIT، مثل المشروع الأساسي للغة ص.
بمساهمتك، فإنّك توافق على ترخيص مساهمتك بموجب الشروط نفسها.