شكرًا لك على تفاعلك معي في هذا الشأن، @Stephen.
أعتقد أن هذا الأمر محدد جدًا للمجتمع
أوافقك الرأي. ولهذا السبب أقترح أن يتم التحكم فيه عبر خانة اختيار في الإعدادات (سواء بإعادة استخدام واحدة من الخانات الموجودة المتعلقة بمنع العناوين المكررة، أو بإضافة خانة جديدة).
ما الفائدة من وجود عدد أقل من المواضيع الأطول بكثير؟
كخلفية، على موقعنا على Discourse، لدينا فئة “الإشعارات”، حيث تتلقى كل فئة فرعية منها رسائل بريدية تُرسل بواسطة سكريبتات عند حدوث أحداث معينة (مثل فشل الاختبارات، أو رفع مشكلات جديدة، أو طرح أسئلة جديدة على Stack Overflow، أو ذكر مشروعنا في مواقع النقاش، إلخ). صُممت هذه الفئات لتمكين أعضاء المجتمع من تتبع ومناقشة أنواع محددة من الأحداث التي قد تهمهم.
في بعض الحالات، تكون عناوين الرسائل المولدة بواسطة سكريبتاتنا متوقعة وحتمية بالتصميم، مثل “linux64 testing”. على سبيل المثال، إذا حدث فشل جديد في اختبارنا على linux64 في 15 أغسطس، فإن ذلك يولد رسالة بريدية. وإذا تسربت أخطاء إضافية في 16 أغسطس، فإن ذلك يولد رسالة ثانية بنفس العنوان. ثم إذا تم حل جميع الأخطاء في 17 أغسطس، يتم توليد رسالة ثالثة بنفس العنوان تشير إلى الحل. ثم إذا حدثت أخطاء جديدة في 31 أغسطس، نولد رسالة رابعة بنفس العنوان، وخامسة عند حل الفشل.
مع السلوك الحالي للموقع، تولد كل من هذه الرسائل موضوعًا جديدًا بالكامل باسم “linux64 testing” دون أي ارتباط أو علاقة بينها، مما يصعب على البشر ربط الأحداث أو تحديد أي من المواضيع الخمسة يجب استخدامه للمناقشة المتابعة حول الأخطاء. بينما نرغب في أن تظهر جميع الرسائل الخمس (وأي نقاش مستخدم يحدث بشأنها) كمنشورات ضمن موضوع واحد، بحيث يتمكن المطور من رؤية جميع فشل الاختبارات في تكوين معين ضمن موضوع واحد، مرتبة زمنيًا.
تأثير آخر للسلوك الحالي لـ Discourse هو أن الشخص الذي يتلقى إشعارات البريد الإلكتروني للفئة أو الموضوع المعني يرى خمس خيوط غير مرتبطة في صندوق الوارد باسم “linux64 testing”. بينما لو قام Discourse بدمج هذه الخيوط في موضوع واحد، لكان هذا الشخص قد رأى جميع منشورات “linux64 testing” المرتبطة كخيط واحد في قارئ البريد الإلكتروني الخاص به، مما يجعل التنقل أسهل بكثير ويشبه أي محادثة تقليدية.
ندير عدة عشرات من تكوينات الاختبار كل ليلة، وكل منها له عنوان فريد عند حدوث فشل، لذا فإن الوضع الحالي يؤدي إلى فوضى متشعبة يصعب التنقل فيها، مع وجود موضوع سطحي مميز لكل رسالة بريدية، كلها متداخلة زمنيًا. بينما مثاليّنا هو أن تظهر فئة “Notifications.Tests” موضوعًا واحدًا لكل تكوين، يخزن جميع المنشورات البشرية أو المولدة بواسطة سكريبتات حول ذلك التكوين بشكل زمني، وفقًا لذلك العنوان الفريد.
[هذه فئة الاختبار غير مرئية حاليًا للجمهور على موقعنا يا @Stephen، ولكن إذا أردت رؤية شكلها والشعور بالألم شخصيًا، فسأكون سعيدًا بمنحك مؤقتًا حق الوصول للقراءة إليها… فقط أخبرني.]
بالنسبة لمجتمعات مثل meta، فإن هذا يعني أن أي مستخدم يرسل بريداً إلكترونياً مع عبارة ‘مشاكل في تكوين Mailgun’ سيستمر في تلقي إشعارات بالتحديثات بعد أشهر أو سنوات من حل مشكلته.
أوافق على أن هذا الخيار قد لا يكون مناسبًا لمجتمع كبير وطويل العمر مثل meta الذي لا يحتاج إلى تجميع المنشورات المولدة عبر البريد الإلكتروني في موضوع واحد كما نفعل نحن. لذا، ربما لن ترغب في تفعيل مثل هذه الميزة إذا وُجدت. (وربما مع مرور الوقت، لن نرغب في ذلك أيضًا على موقع مثل موقعنا لنفس الأسباب، وفي هذه الحالة أعتقد أن المثالي هو تطبيق خانة الاختيار على أساس كل فئة على حدة، لكنني لم أكن أريد طلب الكثير عندما أعتقد أن إعداد واحد على مستوى الموقع سيكفي لنا في الوقت الحالي).
مع ذلك، حتى لو اختار موقع مثل موقعنا تفعيل مثل هذه الميزة، وكان منشئ الموضوع الأصلي لـ ‘مشاكل في تكوين Mailgun’ منزعجًا من المنشورات اللاحقة التي تشارك نفس العنوان، فمن المفترض أنه يمكنه إلغاء الاشتراك في الموضوع لتجنب استمرار تلقي التحديثات إذا استخدم شخص آخر نفس العنوان (أو ببساطة يضيف منشورًا آخر إلى الموضوع المعني عبر واجهة الويب)؟
[مع ذلك، أتوقع أن معظم المستخدمين البشر سيقومون بالنشر عبر الموقع، لذا تخيل أن يكون لهذه الميزة تأثير أكبر على المنشورات المولدة بواسطة السكريبتات مقارنة بتلك المولدة بواسطة البشر]