نعم، هذه نقطة مؤلمة. يجب أن يكون الافتراضي هو رسائل البريد الإلكتروني للمطورين كما هو محدد في app.yml لأن المطور/مسؤول النظام أكثر اهتمامًا بتطبيق التحديث بدلاً من دعم موقع الويب (والذي يمكن أن يكون فريقًا غير تقني تمامًا).
3 إعجابات
ربما يكون الحل هنا هو تغيير إعداد المسؤول رسائل البريد الإلكتروني للإصدار الجديد من تبديل إلى قائمة مفصولة بفواصل من عناوين البريد الإلكتروني، مع تعيين القيمة الافتراضية لأول مسؤول موقع يقوم بإعداد الموقع في المقام الأول.
ومع ذلك، هل لدينا قاعدة الثلاثة؟ لم أسمع هذا الطلب من أي شخص آخر. من المفترض أن يتصل جهة الاتصال الرسمية بشخص ما بشأن القضايا الهامة المتعلقة بالمنتدى، ويمكنه إعادة توجيه البريد الإلكتروني إلى الشخص المسؤول عن إجراء التحديثات.
3 إعجابات
هناك احتمال كبير بأن الناس قد لا يكونون على علم بوجود هذه الميزة.
إعجابَين (2)
دعنا نرى.. بشكل افتراضي، يتحقق Discourse من تحديثات الإصدار. وأيضًا بشكل افتراضي، إذا كان هناك إصدار جديد متاح، يتم إرسال بريد إلكتروني إلى عنوان contact_email.
في معالج الإعداد، يُطلب منهم ملء حقل contact_email.
أعتقد أنه من الصحيح أن الناس قد لا يصلون إلى هذه المرحلة في الإعداد الأولي وقد لا يعودون أبدًا لإكمال هذا الإعداد الإداري. يمكننا بذل المزيد من الجهد للتأكد من أن Discourse ينبه الأشخاص حتى يكملوه، للتأكد من إمكانية الوصول إليهم للإشعارات الهامة وعلى صفحتهم “حول” للأمور العاجلة.
من الصحيح أيضًا أنه بالنسبة للمستضيفين الذاتيين، يتم توفير عنوان بريد إلكتروني للشخص الذي يقوم بإعداد الموقع أثناء الإعداد في app.yml، وبالتالي قد تكون تجربة أكثر سلاسة هي إرسال البريد الإلكتروني إلى عنوان البريد الإلكتروني في app.yml، كما هو مقترح أعلاه.
أو فكرة أخرى قد تكون تغيير الإعداد الإداري لتحديد مجموعة لإعلامها، المسؤول الافتراضي؟ قد يكون ذلك مزعجًا أو قد يتداخل الأشخاص مع بعضهم البعض في المواقع التي تضم العديد من المسؤولين، ولكن يمكننا إضافة ملاحظة إلى دليل البدء السريع للمسؤول لتغيير المجموعة في هذه الحالة.
إعجابَين (2)
أتفق على أنه سيكون من المفيد لو تم إرسال رسائل البريد الإلكتروني المتعلقة بالتحديثات إلى بريد إلكتروني للمطور بدلاً من البريد الإلكتروني لجهة الاتصال.
(السياق)
السبب الرئيسي هو أن البريد الإلكتروني لجهة الاتصال مدرج علنًا كبريد إلكتروني للدعم ليتمكن أي شخص من الاتصال به للاستفسارات العامة أو الدعم.
أعتقد أنه سيكون من المنطقي ربط بريد إلكتروني كهذا بنظام تذاكر دعم يديره موظفون غير تقنيين. بينما يجب إرسال الإشعارات الهامة المتعلقة بأمان مثيل Discourse (مثل تحديثات الأمان المتاحة) مباشرة إلى بريد إلكتروني لمسؤول الخادم (يفضل أن يكون ذلك دون الحاجة إلى إنشاء حساب مستخدم لهذا البريد الإلكتروني).
ستكون خطافات الويب (webhooks) رائعة أيضًا، مما يجعل من الممكن إرسال هذه التنبيهات الهامة إلى Slack أو Discord وما إلى ذلك.
3 إعجابات
أعتقد أننا نريد فعل شيء هنا.
قد يكون هذا هو أسهل شيء يمكن تحقيقه وأيسره تطبيقًا. يتم دعم قائمة مفصولة بفواصل من عناوين البريد الإلكتروني، ولا يلزم بالضرورة أن يكون لديها حسابات على الموقع.
يمكننا شرح كيفية استخدامه في أداة الإعداد ودليل المسؤول.
فكرة لطيفة أيضًا! ربما يمكن إضافتها كمكون إضافي. هل يمكنك بدء موضوع منفصل لاقتراحها؟
فكرة رائعة! يبدو هذا أيضًا كطلب ميزة منفصل - هل يمكنك بدء موضوع آخر لاقتراحه وشرح فكرتك بمزيد من التفصيل؟
إعجابَين (2)