تتبع حالة RFCs باستخدام Discourse

اسم الميزة

حالة الخطاب

هدف الميزة

اجعل الخطاب منتدى شبيهًا بـ RFC

وصف الميزة

  1. طلب تعليقات ( RFC ) هو منشور في سلسلة، من هيئات التطوير الفني ووضع المعايير الرئيسية لـ الإنترنت، وأبرزها مؤتمر هندسة الإنترنت (IETF). يتم تأليف RFC بواسطة أفراد أو مجموعات من المهندسين وعلماء الكمبيوتر في شكل مذكرة تصف الأساليب أو السلوكيات أو الأبحاث أو الابتكارات المطبقة على عمل الإنترنت والأنظمة المتصلة بالإنترنت. يتم تقديمه إما لـ مراجعة الأقران أو لنقل مفاهيم أو معلومات جديدة، أو في بعض الأحيان، روح الدعابة الهندسية. [1]
  2. حالة الخطاب مشابهة لما ستكون عليه الحالات في مستندات من نوع RFC. تُستخدم حالة الخطاب للتحكم بشكل أفضل في منشورات المستخدم. مستندات RFC لها هذه الحالات:
  • معلوماتي (Informational)
  • تجريبي (Experimental)
  • أفضل ممارسة حالية (Best Current Practice)
  • مسار المعايير (Standards Track)
  • مقترح (Proposed Standard)
  • مسودة (Draft Standard)
  • معيار الإنترنت (Internet Standard)
  • تاريخي (Historic)
  • غير معروف (Unknown)

في حالتي، في مواردي ستكون هذه الحالات وفقًا لنوع المنشور:

حالة الخطاب / الرموز

  1. مسودة (Draft Standard) | 1 - مسودة (Draft Standard)
  2. تجريبي | 2 - تجريبي (Experimental)
  3. معيار مقترح | 3 - مقترح (Proposed Standard)
  4. مسار المعايير | 4 - مسار المعايير (Standards Track)
  5. أفضل ممارسة حالية | 5 - أفضل ممارسة حالية (Best Current Practice)
  6. تاريخي (Historic) | 6 - تاريخي (Historic)
  7. معلوماتي | 7 - معلوماتي (Informational)
  8. معيار | 8 - معيار (Standard)
  9. غير معروف | 9 - غير معروف (Unknown)

حالة الخطاب / الحالات

  1. عندما ينشئ المستخدم منشورًا ولا يوجد رد على هذا المنشور. هذا المنشور له حالة خطاب كمسودة (Draft Standard). وعندما ينشئ المستخدم منشورًا ولم يتم نشره. هذا المنشور له حالة خطاب كمسودة (Draft Standard) أيضًا.
  2. عندما ينشئ المستخدم منشورًا وله رد. هذا المنشور له حالة خطاب تجريبي (Experimental Discourse). إذا كان هناك المزيد من الردود، فإن هذا المنشور له حالة خطاب تجريبي (Experimental).
  3. إذا أعجب العديد من المستخدمين بالمنشور واعتقدوا حقًا أن هذا المنشور جيد، فسيتم وضع علامة على هذا المنشور كمسار للمعايير (Standards Track). إذا كان هناك المزيد من المنشورات نفسها أو المشابهة، يتم الإعلان عن الحالة الافتراضية كحالة أفضل ممارسة حالية للخطاب (Best Current Practice Discourse).
  4. يُنظر إلى أي تعديل على المنشور على أنه حالة يتم الإعلان عنها كخطاب تاريخي (History (Historic)).
  5. سواء تم قبول المنشور من قبل جميع أعضاء المجتمع، فإن حالة الخطاب تكون معلوماتية (Informational).
  6. إذا كان المنشور يحتاج إلى أي تصحيح أو تحسين، يتم الإعلان عن الحالة كخطاب معلوماتي (Informational). إذا تم تصحيح المنشور وتحسينه، يتم الإعلان عن الحالة كخطاب مقترح (Proposed Standard).
  7. إذا لم يكن للمنشور رد لمدة أسبوع أو يوم أو شهر أو سنة - يتم الإعلان عن الحالة كخطاب غير معروف (Unknown).

ملاحظات

  • يتم إجراء هذه الحالة تلقائيًا
  • تظهر حالات المنشور دائمًا على الصفحة الرئيسية
  • الشيء الرائع في امتلاكك لحالات منشورات هو أنك تتابع هذا المنشور
  • مراقبة الجودة لمنشورات المستخدم لتجنب الإساءة، وتجنب البريد العشوائي، وتجنب المنشورات غير المرتبة
  • الخطاب هو برنامج مجتمعي جذاب وحتى أكثر، لا شيء أفضل من زيادة جودة البرنامج، وجودة تجربة المستخدم

فكرة

صورة وصفية

كما نرى في الصورة، يمكن أن تكون هناك حالات مختلفة في نفس المنشور. وفقًا لتفاعل المستخدم، تتغير الحالة. يمكن أن تكون الحالة 1، 2، 3، 4، 5، 6، 7، 8 أو 9. يمكننا أن نرى في الصورة أن شيئًا ما حدث، تلقى المنشور الكثير من التعليقات، وانتقل من كونه مسودة إلى كونه حالة المعيار، الرمز 8.

مراجع

إعجاب واحد (1)

إحدى الطرق للقيام بذلك دون أي إضافات هي إنشاء فئات فرعية (أو فئات رئيسية فقط؟) لكل مستوى، ونقل المشاركات بينها أثناء “تخرجها”.

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

3 إعجابات

إذًا، هذا يتعلق بإضافة ميزات خاصة بـ RFC إلى Discourse؟ ألا ينبغي أن يكون هذا هو عنوان هذا الموضوع؟

إعجابَين (2)

أنا بالتأكيد أفسر بناءً على بعض التخمينات، لكن أعتقد أن الأمر يتعلق بإضافة ميزات “تتبع الحالة” إلى Discourse، مع تتبع RFC كمثال؟ لست متأكدًا بصراحة مما إذا كان “حالة Discourse” يُقصد به نوع من المزاح أم لا.. ولكن على أي حال، فهو مربك للغاية ويجب أن يكون شيئًا آخر.

على أي حال…

نقوم حاليًا بشيء أقل تعقيدًا بكثير لمشاكل Common Issues في Fedora Linux والتي أعتقد أنها قد تكون مشابهة، مع فئة رئيسية (مقبولة) مشاكل Common Issues مع فئات مشاكل Common Issues المقترحة و مشاكل Common Issues المؤرشفة. أستخدم برنامجًا نصيًا خارجيًا (في هذه المرحلة بدائية للغاية - أنا لست مبرمجًا بالفعل) لمعالجة ونقل المشاركات بين الفئات، كما اقترحت أعلاه.

إعجابَين (2)

أنا بالتأكيد أفسر بناءً على بعض التخمينات، لكن أعتقد أن الأمر يتعلق بإضافة ميزات “تتبع الحالة” إلى Discourse، مع تتبع RFC كمثال؟

  • نعم. بالضبط، هذا ما كنت أفكر فيه. حالات Discourse تستند إلى RFC.
  1. تحدثت عن RFC لأن جزءًا من المستندات الفنية التي أطورها يقوم بها جزء من الفريق بشيء مماثل.
  2. المشكلة هي أن هذه العملية بيروقراطية ويدوية للغاية وتخضع للخطأ البشري في بعض الأحيان.
  3. لأنه في بعض الأحيان أكتب شيئًا تقنيًا يجب مراجعته من قبل الفريق، إذا لم يكن الشخص في الفريق حذرًا جدًا أو كان شخصًا يرى الكثير من التفاصيل، فقد تكون المستندات المرسلة في المكان الخطأ. ستكون فكرتي هي تنفيذ Discourse في فريقنا الصغير.
  4. ستكون فكرتي هي كيف أعمل مع المستندات الفنية، ستكون فكرتي هي متابعة المنشورات التي ينشرها الأشخاص. تتبع المنشورات بناءً على RFC. نظرًا لأن هذا شيء نعمل عليه كثيرًا.
  5. لكنني لم أجد أي إضافات أو موارد مماثلة على Discourse أو أي برنامج من نوع المنتدى متاح.
  6. الميزة، في رأيي، مبتكرة، إذا فكرت في فرق التوثيق الفني التي تستخدم البرامج القديمة. أعتقد أنه يمكن استبدال هذه البرامج القديمة والعتيقة بـ Discourse. Discourse برنامج مثير للاهتمام للغاية وأنا أحبه كثيرًا. كلما استطعت، أوصي به للأصدقاء والمعارف. مشكلتي هي أنني لم أجد أي إضافات أو ميزات مماثلة وصفتها للتو، مثل الحالة المستندة إلى RFC للمنشور.

نحن حاليًا نقوم بشيء أقل تعقيدًا بكثير للقضايا الشائعة في Fedora Linux والذي أعتقد أنه قد يكون مشابهًا، مع فئة رئيسية (القضايا المقبولة) الشائعة مع فئات القضايا الشائعة المقترحة و القضايا الشائعة المؤرشفة. أستخدم برنامجًا نصيًا خارجيًا (في هذه المرحلة بدائية جدًا - أنا لست مبرمجًا بالفعل) لمعالجة ونقل المنشورات بين الفئات، كما اقترحت أعلاه.

  • لا أريد الاستمرار في النظر إلى الفئة أو الفئة الفرعية، أريد شيئًا ديناميكيًا.
  • الطريقة التي يتفاعل بها المستخدم يمكن أن تنشئ حالة جديدة أم لا.
  • لأنه إذا لم يكن هناك تغيير في الحالة، فسيتعين علي القيام بشيء مثل ما تخطط له، مثل، سيتعين علي إنشاء برنامج نصي لنقل المنشورات من فئة إلى أخرى.
  • أنا لا أنتقدك، أعتقد أن هذه الفكرة جيدة، لدرجة أنني فكرت حتى في القيام بشيء كهذا، لكنني لم أعرف أي شخص يفكر بنفس الشيء. المشكلة الوحيدة التي أراها هي أنني لست مبرمجًا :frowning: ولم أجد أي برنامج نصي على الإنترنت يقوم بذلك.
إعجاب واحد (1)

أنا لا أفهم هذا. “الفئة” هي مجرد تسمية، نوع من البيانات الوصفية التي يتم تمثيلها في عرض هرمي. إذا جعلت كل هذه فئات فرعية ولكنك نظرت بعد ذلك إلى عرض “الكل” للفئة العليا، فسترى جميع المشاركات.
عليك تتبع هذه الحالة بأي شكل من الأشكال. خيارك الآخر - بدون إضافات تدخلية إلى حد ما - سيكون استخدام العلامات، لكنني أعتقد حقًا أن الفئات هي الأنسب. أمثلة: تسمح لك الفئات بالحصول على مستويات أذونات مختلفة، ويمكنك زيادة ترتيب البحث للمواضيع في الحالات “الأعلى” وتقليلها للحالات “الأدنى”، بحيث يتم إعطاء الأولوية للمستندات الرسمية.

إعجابَين (2)

يجب عليك تتبع هذه الحالة بطريقة ما. خيارك الآخر - بدون إضافات تدخلية بشكل عادل - سيكون استخدام العلامات، لكنني أعتقد حقًا أن الفئات تناسب بشكل أفضل. أمثلة: تسمح لك الفئات بالحصول على مستويات أذونات مختلفة، ويمكنك زيادة ترتيب البحث للمواضيع في الحالات “الأعلى” وتقليلها للحالات “الأدنى”، بحيث يتم إعطاء الأولوية للمستندات الرسمية.

  • أنت على حق، لقد أوضحت الكثير من الأشياء، شكرًا لك على ذلك. حقًا، الفئات أفضل بكثير
إعجاب واحد (1)