rfcs
1.0.0
يمكن تنفيذ ومراجعة العديد من التغييرات، بما في ذلك إصلاحات الأخطاء وتحسينات التوثيق، من خلال سير عمل طلب السحب العادي في GitHub.
على الرغم من ذلك، تعتبر بعض التغييرات "جوهرية"، ونحن نطلب أن يتم إخضاعها لبعض عملية التصميم والتوصل إلى إجماع بين فريق React الأساسي.
تهدف عملية "RFC" (طلب التعليقات) إلى توفير مسار ثابت ومتحكم فيه للميزات الجديدة لدخول المشروع.
قائمة RFC النشطة
من أجل قبول طلب السحب الخاص بك، نحتاج منك تقديم CLA. ما عليك سوى القيام بذلك مرة واحدة فقط، لذا إذا كنت قد فعلت ذلك لمشروع آخر مفتوح المصدر على فيسبوك، فأنت جاهز للبدء. إذا كنت ترسل طلب سحب للمرة الأولى، فما عليك سوى إخبارنا بأنك قد أكملت CLA ويمكننا التحقق من اسم مستخدم GitHub الخاص بك.
أكمل CLA الخاص بك هنا.
يجب أن تفكر في استخدام هذه العملية إذا كنت تنوي إجراء تغييرات "جوهرية" على React أو وثائقها. بعض الأمثلة التي قد تستفيد من RFC هي:
ميزة جديدة تنشئ مساحة سطحية جديدة لواجهة برمجة التطبيقات (API)، وستتطلب علامة ميزة في حالة تقديمها.
إزالة الميزات التي تم شحنها بالفعل كجزء من قناة الإصدار.
تقديم استخدامات أو اصطلاحات اصطلاحية جديدة، حتى لو لم تتضمن تغييرات في التعليمات البرمجية لـ React نفسها.
بعض التغييرات لا تتطلب RFC:
إعادة الصياغة أو إعادة التنظيم أو إعادة البناء
إضافة أو إزالة التحذيرات
الإضافات التي تعمل على تحسين معايير الجودة الموضوعية والعددية بشكل صارم (التسريع، دعم أفضل للمتصفح)
من المحتمل أن يتم ملاحظة الإضافات فقط بواسطة منفذي React الآخرين، وهي غير مرئية لمستخدمي React.
من الصعب كتابة RFC ليتم قبوله. ومع ذلك، لا ينبغي أن يثنيك هذا عن كتابة واحدة.
تتمتع React بمساحة سطحية محدودة للغاية لواجهة برمجة التطبيقات (API)، وتحتاج كل ميزة إلى العمل بسلاسة مع جميع الميزات الأخرى. حتى بين أعضاء الفريق الذين يعملون على React بدوام كامل كل يوم، فإن تكثيف واكتساب السياق الكافي لكتابة RFC جيد يستغرق أكثر من عام.
من الناحية العملية، تخدم طلبات React RFC غرضين:
يتم إرسال طلبات RFC لفريق React بواسطة أعضاء فريق React بعد تصميم ومناقشة وتجريب مكثف (أحيانًا لعدة أشهر أو عدة سنوات). ومن الناحية العملية، فإنها تشكل غالبية طلبات التعليقات RFC التي تم دمجها حتى الآن. الغرض من طلبات RFC هذه هو معاينة التصميم للمجتمع وتوفير فرصة للتعليقات. نحن نقرأ كل تعليق على طلبات التعليقات التي ننشرها، ونرد على الأسئلة، وأحيانًا ندمج التعليقات في الاقتراح. نظرًا لأن وقتنا محدود، فإننا لا نميل إلى كتابة RFC لميزة React إلا إذا كنا واثقين جدًا من أنها تناسب التصميم. على الرغم من أنه قد يبدو أن معظم طلبات RFC الخاصة بـ React Team يتم قبولها بسهولة، إلا أنه من الناحية العملية، يرجع ذلك إلى أن 98% من الأفكار قد تُركت في غرفة التقطيع. أما نسبة الـ 2% المتبقية التي نشعر بثقة كبيرة ولدينا إجماع حولها من قبل الفريق فهي تلك التي نعلن عنها باعتبارها RFCs للحصول على تعليقات المجتمع.
يمكن لأي شخص تقديم طلبات RFC الخاصة بالمجتمع . في الممارسة العملية، لا يتم دمج معظم طلبات RFC المجتمعية. الأسباب الأكثر شيوعًا لرفض RFC هي أنه يحتوي على فجوات أو عيوب كبيرة في التصميم، أو أنه لا يعمل بشكل متماسك مع جميع الميزات الأخرى، أو أنه لا يقع ضمن رؤيتنا لنطاق React. ومع ذلك، فإن الدمج ليس هو معيار النجاح الوحيد لـ RFC. حتى عندما لا يتوافق تصميم واجهة برمجة التطبيقات (API) مع الاتجاه الذي نرغب في اتباعه، فإننا نجد أن مناقشات RFC ذات قيمة كبيرة للبحث والإلهام. لا نقوم دائمًا بمراجعة طلبات RFC الخاصة بالمجتمع في الوقت المناسب، ولكن عندما نبدأ العمل في منطقة ذات صلة، فإننا نتحقق من طلبات RFC في تلك المنطقة، ونراجع حالات الاستخدام والمخاوف التي نشرها أعضاء المجتمع. عندما ترسل طلب RFC، لا ينبغي أن يكون هدفك الأساسي بالضرورة دمجه في React كما هو، بل إنشاء مناقشة ثرية مع أعضاء المجتمع. إذا تم قبول اقتراحك لاحقًا، فهذا رائع. ولكن حتى لو لم يحدث ذلك، فلن يذهب سدى. غالبًا ما تُعلم المناقشة الناتجة الاقتراح التالي في نفس مساحة المشكلة، سواء أتى من المجتمع أو من فريق React. يقرأ العديد من مؤلفي المكتبات المناقشات، لذا غالبًا ما تؤدي طلبات التعليقات RFC إلى تجربة المجتمع وحلول أرض المستخدم.
نحن نطبق نفس المستوى من الدقة على كل من React Team RFCs وCommunity RFCs. يكمن الاختلاف الأساسي بينهما في مرحلة التصميم: تميل طلبات RFC الخاصة بفريق React إلى تقديمها في نهاية عملية التصميم بينما تميل طلبات RFC الخاصة بالمجتمع إلى الإرسال في البداية كوسيلة لبدء العملية.
باختصار، لإضافة ميزة رئيسية إلى React، عادةً ما يتم دمج RFC أولاً في مستودع RFC كملف تخفيض السعر. عند هذه النقطة يكون RFC "نشطًا" ويمكن تنفيذه بهدف تضمينه في نهاية المطاف في React.
شوكة RFC الريبو http://github.com/reactjs/rfcs
انسخ 0000-template.md إلى text/0000-my-feature.md (حيث تكون كلمة "my-feature" وصفية. لا تقم بتعيين رقم RFC بعد).
املأ RFC. انتبه إلى التفاصيل: إن طلبات التعليقات (RFC) التي لا تقدم دافعًا مقنعًا، أو تظهر فهمًا لتأثير التصميم، أو تكون مخادعة بشأن العيوب أو البدائل، تميل إلى أن يتم استقبالها بشكل سيئ .
إرسال طلب سحب. كطلب سحب، سيتلقى RFC تعليقات التصميم من المجتمع الأكبر، ويجب أن يكون المؤلف مستعدًا لمراجعته ردًا على ذلك.
بناء الإجماع ودمج ردود الفعل. من المرجح أن تحقق طلبات التعليقات (RFCs) التي تتمتع بدعم واسع تقدمًا أكبر بكثير من تلك التي لا تتلقى أي تعليقات.
في النهاية، سيقرر الفريق ما إذا كان RFC مرشحًا لإدراجه في React. لاحظ أن مراجعة الفريق قد تستغرق وقتًا طويلاً، ونقترح عليك أن تطلب من أعضاء المجتمع مراجعتها أولاً.
ستدخل طلبات التعليقات RFC المرشحة للتضمين في React في "فترة تعليق نهائية" تستمر لمدة 3 أيام تقويمية. سيتم الإشارة إلى بداية هذه الفترة بتعليق وعلامة على طلب سحب RFCs.
يمكن تعديل RFC بناءً على تعليقات الفريق والمجتمع. قد تؤدي التعديلات المهمة إلى تفعيل فترة تعليق نهائية جديدة.
قد يتم رفض RFC من قبل الفريق بعد تسوية المناقشة العامة وإبداء التعليقات التي تلخص مبررات الرفض. يجب على أحد أعضاء الفريق بعد ذلك إغلاق طلب السحب المرتبط بـ RFCs.
قد يتم قبول RFC في نهاية فترة التعليق النهائية. سيقوم أحد أعضاء الفريق بدمج طلب السحب المرتبط بـ RFC، وعند هذه النقطة سيصبح RFC "نشطًا".
بمجرد أن يصبح RFC نشطًا، يمكن للمؤلفين تنفيذه وإرسال الميزة كطلب سحب إلى React repo. إن التحول إلى "نشط" ليس بمثابة ختم مطاطي، ولا يعني على وجه الخصوص أنه سيتم دمج الميزة في النهاية؛ بل يعني أن الفريق الأساسي وافق عليه من حيث المبدأ وقابل لدمجه.
علاوة على ذلك، فإن حقيقة قبول طلب RFC معين وكونه "نشطًا" لا تعني شيئًا عن الأولوية المعينة لتنفيذه، ولا ما إذا كان أي شخص يعمل عليه حاليًا.
يمكن إجراء التعديلات على طلبات RFC النشطة في طلبات المستفيدين الخاصة بالمتابعة. نحن نسعى جاهدين لكتابة كل طلب RFC بطريقة تعكس التصميم النهائي للميزة؛ لكن طبيعة العملية تعني أننا لا نستطيع أن نتوقع أن يعكس كل طلب RFC مدمج فعليًا النتيجة النهائية في وقت الإصدار الرئيسي التالي؛ ولذلك نحاول أن نجعل كل مستند RFC متزامنًا إلى حد ما مع ميزة اللغة كما هو مخطط له، وتتبع هذه التغييرات من خلال طلبات السحب اللاحقة للمستند.
مؤلف RFC غير ملزم بتنفيذه. بالطبع، نرحب بمؤلف RFC (مثل أي مطور آخر) لنشر تطبيق للمراجعة بعد قبول RFC.
إذا كنت مهتمًا بالعمل على تنفيذ طلب RFC "نشط"، ولكن لا يمكنك تحديد ما إذا كان شخص آخر يعمل عليه بالفعل، فلا تتردد في السؤال (على سبيل المثال، عن طريق ترك تعليق على المشكلة المرتبطة).
حاليًا، لا يستطيع فريق React الالتزام بمراجعة طلبات التعليقات (RFC) في الوقت المناسب. عند إرسال RFC، يجب أن يكون هدفك الأساسي هو التماس تعليقات المجتمع وإنشاء مناقشة غنية. يقوم فريق React بإعادة تقييم القائمة الحالية للمشاريع والأولويات كل عدة أشهر. حتى لو كان RFC مصممًا بشكل جيد، فإننا غالبًا لا نستطيع الالتزام بدمجه على الفور. ومع ذلك، فإننا نجد أنه من المفيد جدًا إعادة زيارة طلبات RFC المفتوحة كل بضعة أشهر، ومعرفة ما إذا كان هناك أي شيء يلفت انتباهنا. عندما نبدأ العمل على مساحة مشكلة جديدة، نتأكد أيضًا من التحقق من العمل السابق والمناقشة في أي طلبات RFC ذات صلة، والتفاعل معها.
نقرأ جميع طلبات التعليقات (RFC) في غضون أسابيع قليلة من تقديمها. إذا اعتقدنا أن التصميم يناسب React جيدًا، وإذا كنا مستعدين لتقييمه، فسنحاول مراجعته قريبًا. إذا كنا مترددين بشأن التصميم أو إذا لم تكن لدينا معلومات كافية لتقييمه، فسنتركه مفتوحًا حتى يتلقى تعليقات كافية من المجتمع. نحن ندرك أنه من المحبط عدم تلقي المراجعة في الوقت المناسب، ولكن يمكنك التأكد من أن أيًا من العمل الذي قمت به في RFC لم يذهب سدى.
تدين عملية RFC الخاصة بـ React بإلهامها لعملية Yarn RFC، وعملية Rust RFC، وعملية Ember RFC.
لقد قمنا بتغييرها في الماضي استجابةً للتعليقات، ونحن منفتحون على تغييرها مرة أخرى إذا لزم الأمر.
