أدى تغيير حديث في ديسكورس (Discourse) إلى إزالة “الرفع” عند تعديل آخر مشاركة (أو أول مشاركة) في موضوع.
لقد أصبحنا نعتمد على هذه الميزة ولا توجد طريقة فعالة لمحاكاتها للأعضاء غير المصنفين كموظفين.
لقد استفدنا من هذه الوظيفة بشكل أساسي لرفع المشاركات التي كانت على شكل إعلانات أو المشاركات التي لم تتلق أي ردود / ردود قليلة عن قصد.
كانت هذه تحديثات حقيقية لموضوع حيث يؤدي التعديل إلى إزالة المعلومات التي عفا عليها الزمن الآن. كان من المرغوب فيه جدًا أن ترتفع المشاركة مرة أخرى إلى أعلى قائمة “الأحدث” لإبلاغ جميع الأعضاء بحدوث تغيير.
نعم، يمكن محاكاة هذا إلى حد ما من خلال سلسلة من الردود، ولكن بمرور الوقت، سيصبح هذا الأمر مرهقًا للمستخدم لجمع ما تم إبلاغ به (تخيل 10 ردود بتغييرات، على سبيل المثال). كان من الأفضل بكثير تعديل المشاركة الأصلية / أحدث مشاركة وجعل الموضوع يرتفع في قائمة “الأحدث”.
أنا أقدر أنه سيكون هناك أشخاص من كلا الجانبين، ولكن هذا كان سابقة قائمة منذ فترة طويلة في ديسكورس (Discourse) لسنوات عديدة، وإضافة خيار لاستعادة الوظيفة السابقة إلى ديسكورس (Discourse) سترضي الجميع. ربما يمكن توسيع الخيار بمرور الوقت للتحكم بدقة في النشاط الذي يجعل المشاركة ترتفع في قائمة “الأحدث”.
رابط إلى موضوع الخطأ حيث تمت مناقشة هذا التغيير أدناه:
كما ذكرت سابقًا، أفتقد أيضًا إمكانية رفع المواضيع عند إجراء تعديل ذي مغزى.
أستخدم #rss-polling للإخطار بالصيانة على منتدى من خلال موجز RSS الخاص بـ https://status.discourse.org/. يتم إنشاء الموضوع عند بدء الصيانة، وكان يتم رفعه عند التعديل الذي يعلن انتهائها. هذا الرفع مفقود الآن، ولا أريد أن تكون المواضيع “ويكيز” (wikis)، حيث لا ينبغي لأي مستخدم تعديلها، ولا أريدها أن تكون “مستندات” (docs). لذا، فإن الحلول البديلة الحالية لا تساعد.
في أحد المنتديات، لدينا موضوع معرض يعرض مشاريع المستخدمين بالإضافة إلى المواضيع الفردية التي يعرض فيها المستخدمون مشاريعهم. هذا الموضوع مفيد جدًا لجمع الإلهام. نضيف صورة من موضوع العرض ورابطًا إليه في موضوع المعرض هذا. أدت كثرة الصور في المشاركة إلى مشاكل في الأداء وتجعل التعديل أكثر صعوبة أيضًا. لذلك، ننشئ مشاركة جديدة لكل 10 مشاريع. كان الرفع عند التعديل عند إضافة المشروع الثاني أو التاسع مفيدًا. كان من المفيد للمستخدمين ملاحظة التحديث، وكان مفيدًا بشكل خاص لأولئك الذين يضيفون المشاريع يدويًا إلى الموضوع. بفضل تاريخ النشاط، كنت أستطيع أن أرى على الفور ما إذا كان شخص آخر قد أضاف المشروع بالفعل. الآن، يحتاج كل منا إلى فتح الموضوع للتحقق من ذلك.
هناك أيضًا مواضيع أخرى تعمل بطريقة مماثلة: مواضيع تعمل كملخص بأثر رجعي للتغييرات/النشاط خلال شهر ويتم تحديث آخر مشاركة حول الشهر الحالي عدة مرات. لقد نجح هذا بشكل جيد حقًا لأن التغييرات في المشاركة الأخيرة رفعت الموضوع. إن نشر كل تغيير على حدة سيؤدي إلى الإضرار بوضوح الإدخالات المجمعة شهريًا وسيظل يعني أنه من السهل تفويت التحديثات على الإدخالات الحالية. إن إنشاء موضوع جديد كل شهر لعدد قليل من الإدخالات يبدو وكأنه كثير جدًا، وسيعني أيضًا أن المستخدمين سيحتاجون إلى إعادة تعيين إشعاراتهم كل شهر، أو سنحتاج إلى فئة فرعية كاملة تسمح لهم بتعيين حالة الإشعار الافتراضية الخاصة بهم.
لقد استمتعت أيضًا بأن تغييرات الفئة والوسم على المواضيع التي لم تتم الإجابة عليها كانت ترفعها. في معظم الأحيان، أستخدم قائمة (مُصفاة) بأحدث المواضيع. وإذا كان للموضوع عنوان سيئ الاختيار أو كان في الفئة الخاطئة، فقد لا أنقر عليه. إذا قام شخص ما بتحسين هذه المعلومات، فقد أدرك أنه يمكنني المساعدة بعد كل شيء. لهذا السبب كان من المفيد عندما تسبب مثل هذا التغيير في عودة الموضوع إلى ما فوق خط القراءة الخاص بي.
كما كان من المفيد معرفة الفئات والوسوم. لقد تعلمت في كثير من الأحيان عن الوسوم الجديدة لأنها أُضيفت في موضوع جديد أو عن الفرق التفصيلي بين الفئات بناءً على المواضيع التي نقلها المشرف. أتساءل أحيانًا عن السبب، لأنني أعتقد أن القدرة على نقل المواضيع إلى فئات أخرى تأتي أيضًا مع مسؤولية معرفة الفرق بينها.
أنا أيضًا معجب بالنهج الذي تجبرك به إعدادات Discourse على إضافة معلومات بدلاً من كتابة مشاركة أخرى.
لنقتبس رسالة النافذة المنبثقة:
ومع ذلك، فإن هذا منطقي فقط عندما يلاحظ الآخرون أنك قمت بتحرير مشاركتك لإضافة مزيد من المعلومات. مثال صادفني عدة مرات بالفعل على Meta هو التحديثات على مشاركة بعد دمج طلب سحب (pull request). إضافة تلك المعلومات إلى المشاركة لا يخطر أولئك الذين قرأوا المشاركة بالفعل، وأولئك الذين لم يقرأوها يمكنهم معرفة ذلك بسهولة من الشارة في المعاينة المضمنة (onebox).
بالنسبة لي، ليس من المنطقي أن الإعداد الذي يمنع أكثر من ثلاث مشاركات متتالية من قبل المستخدم لا يزال نشطًا ويقترح التعديلات كحل، عندما تكون هذه التعديلات للأسف لم تعد لها التأثير الذي كانت عليه في السابق.
ليس لدي رأي قوي حول هذه الميزة، ولكن المشكلة ذات الصلة هي أنني أحب تحديث المنشورات تلقائيًا ثم إزالة الرسالة المتعلقة بتحديثها، ولكن هذا لم يعد ممكنًا. عندما أحذف رسالة التحديث، تعود الرسالة إلى مكانها السابق. إذا كان تعديل الرسالة سيؤدي إلى تحديثها دون إنشاء “آخر تحديث قبل يوم واحد”، فسيكون ذلك مفيدًا.
(أفضل أن أتمكن من تحديث المنشور، وحذف رسالة التحديث، ولا يزال المنشور يظهر في الصفحة الرئيسية ما لم أقم يدويًا بتنفيذ “إعادة تعيين تاريخ التحديث”.)
أخشى أنه ليس لدينا أي خطط حالية للتراجع عن التغيير / استعادة التحديثات على جميع التعديلات. أتفهم أن هذه ليست الإجابة التي تريد سماعها، ومع ذلك، سنستمر في مراقبة هذا الموضوع والنظر في كيفية دعم حالات الاستخدام الخاصة بك بشكل أفضل في المستقبل.
حقيقة أن شيئًا ما لا يحدث بعد الآن ليست كذلك أيضًا. هل هناك أي بيانات حول عدد المسؤولين الذين لاحظوا أن سلوك Discourse قد تغير؟ أتفهم حجتك بأنه كانت هناك طلبات متكررة حول كيفية منع الدفعات. من الواضح أن المسؤولين يلاحظون دفعة لا يريدونها. ولكن إذا لم يتم دفع موضوع ما، فلن تلاحظ حتى أنه لم يتم دفعه، على الرغم من أنك كنت ترغب في ذلك. لذلك يبدو أنه من غير المرجح أن يطلب الناس ذلك.
أيضًا، مؤخرًا، حقيقة أن البريد العشوائي يسهل ملاحظته إذا تم دفع الموضوع ظهرت مرة أخرى. أتساءل لماذا هذا مهم في الحالة المحدودة الآن إلى حد ما حيث يجب دفع منشور أثناء التحرير. لكنه لم يكن مهمًا عند تغيير الإعداد الافتراضي لمعظم المنشورات. لماذا يحتاج المنشور الأول الذي هو ويكي إلى حماية أكبر من البريد العشوائي مقارنة بالمنشور الأخير في موضوع هو ويكي؟
كما قلت مرارًا وتكرارًا، أفهم المزايا، ولكن لا يبدو أن هناك الكثير من الاهتمام بإيجاد حلول للمساوئ. لا فائدة من وجود بديل لسير العمل الحالية بعد عام أو نحو ذلك. سيتعين علي إيجاد حل جديد الآن لأنه لم يتبق الكثير من الوقت حيث يوجد إصدار مدعوم من Discourse حيث يؤدي تعديل آخر منشور إلى نقل الموضوع إلى الأعلى.
يتم رفع منشورات الويكي والوثائق بناءً على النظرية القائلة بأن التعديلات على تلك المنشورات تكون ذات أهمية بشكل عام.
أما بالنسبة للحماية من الرسائل المزعجة، فإن النظرية الآن هي أن هذه الرفع لم تقدم أبدًا الكثير من التغطية الإضافية. معظم المنشورات ليست المنشور الأخير، ولم يتم إبراز التعديلات عليها عن طريق الرفع على أي حال. لذا، إذا كانت الرسائل المزعجة عبر التعديلات مشكلة، فهي تحتاج إلى حل مختلف بغض النظر عن ذلك. لم يكن هذا حلاً فعالاً لتلك المشكلة أبدًا.
أعتقد أن هناك سوء فهم. لم تكن نقطتي تدور حول سبب رفع مشاركات الويكي في المنشور الأول. كنت أتحدث عن الأساس المنطقي وراء تقييد المعلمة no-bump لواجهة برمجة التطبيقات (API)، كما ورد في تعليق GitHub:
هل ينبغي تقييد هذا على مفاتيح واجهة برمجة التطبيقات الخاصة بالموظفين؟ لا أعتقد أننا نريد أن يتمكن المستخدمون العاديون من تجاوز عملية الرفع (فقد يسمح لهم ذلك بحقن البريد العشوائي في المواضيع دون لفت انتباه الناس إليها).
إذا كان البريد العشوائي هو الشاغل حقًا، فيجب أن ينطبق هذا التقييد باستمرار، وليس فقط في الحالات القليلة المتبقية التي يحدث فيها الرفع. هذا ما أثار دهشتي: يذكر السبب البريد العشوائي كمشكلة هنا، ولكن الرفع لا يُقصد به أن يكون آلية للحماية من البريد العشوائي في الويكيات، على سبيل المثال، التي هي آخر مشاركة في موضوع ما.
أنا أقدر أنه يتم رفع مشاركات الويكي عند تحديثها (على الرغم من أن تجربة المستخدم المتمثلة في الانتقال إلى أسفل الموضوع بينما يكون سبب الرفع هو المشاركة الأولى لا تزال مربكة).
نقطتي هي مجرد تسليط الضوء على هذا التناقض الظاهر فيما يتعلق بالبريد العشوائي.