أود أن أتواصل معكم جميعًا بشأن تجربة أقوم بها. بعضكم ربما يمتلك ذاكرة مجتمعية أفضل مني، لذا أرجو تثقيفي!
لقد قمت بضبط فئة Support بحيث تُغلق المواضيع تلقائيًا بعد 30 يومًا من آخر رد. وهذا يبدو مناسبًا نظرًا لتجربتي الأخيرة في هذه الفئة. بحلول ذلك الوقت، إما أن تكون المواضيع قد حُلت أو أن الشخص الذي طرح السؤال قد انتقل إلى أمر آخر. ويمكن للآخرين الذين لديهم أسئلة مماثلة بدء مواضيع جديدة تتناسب مع وضعهم الخاص.
خلال الأشهر القليلة الماضية، كنت أقوم بفرز المواضيع القديمة في Support التي لم تُحل بعد، باستخدام هذا الفلتر في شريطي الجانبي. في كثير من الحالات، تُحل المواضيع بسرعة نسبيّة بفضل أعضاء منتبهين ومُعينين يجيبون على الأسئلة. وفي أحيان أخرى، تحتاج المواضيع إلى تذكير بعد أسبوع أو أسبوعين للتحقق من الشخص الذي طلب المساعدة لمعرفة ما إذا كانت مشكلته قد حُلّت، وطرح أسئلة توضيحية قد تساعده (ما هي خطوات إعادة إنتاج المشكلة؟ هل استخدمت تعليمات التثبيت الرسمية؟ هل تعمل في الوضع الآمن؟ إلخ). وعندما أقوم بذلك، أضف عادةً مؤقتًا للموضوع ليُغلق تلقائيًا بعد 30 يومًا من آخر رد. إذا لم يستجب الشخص أو أي عضو آخر في المجتمع خلال 30 يومًا، فأعتقد أنه من المقبول تمامًا السماح للموضوع بالإغلاق تلقائيًا.
من خلال ضبط المواضيع في Support للإغلاق التلقائي بعد شهر بدلًا من القيام بذلك يدويًا، أوفر بعض الوقت لأن استخدام مفتاح wrench للإدارة للقيام بذلك حاليًا أمر مرهق بعض الشيء. فهو يتطلب عدة نقرات!
سأعود للتحقق مرة أخرى بعد شهر تقريبًا لتحديد ما إذا كنا نريد الاحتفاظ بهذا الإعداد مفعّلًا أو ما إذا كان نهج آخر قد يكون أفضل.
هل فكرت في كيفية العثور على المواضيع التي تم نشرها في #support، لأنها محددة مسبقًا ثم يتم نقلها إلى فئة أخرى بواسطة أعضاء المجتمع؟ يمكنني نقل المواضيع، لكن لا يمكنني إزالة المؤقت. لذلك يحتاج شخص آخر إلى إزالة المؤقت بعد أن أنقل موضوعًا.
شكراً لطرح هذه النقطة. قد يكون كافياً لك الإبلاغ عنها للمشرفين لإجراء التغيير، إلا إذا كنت تعتقد أنك ستقوم بذلك طوال الوقت. كم مرة تنقل المواضيع بين الفئات الآن؟
أو يمكنك أن تطلب من مستكشف البيانات معرفة عدد المواضيع التي تم نقلها في فترة زمنية
استعلام مثال
-- [params]
-- date :start_date
-- date :end_date
SELECT
pr.user_id,
(regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[1]::int AS old_category_id,
(regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[2]::int AS new_category_id,
COUNT(*) AS change_count
FROM post_revisions pr
WHERE pr.modifications LIKE '%category_id:%'
AND pr.modifications ~ 'category_id:\s*-\s*[0-9]+\s*-\s*[0-9]+'
AND pr.updated_at::date BETWEEN :start_date::date AND :end_date::date
GROUP BY pr.user_id, old_category_id, new_category_id
ORDER BY pr.user_id, change_count DESC
توفر هذه الإضافة أداة اختيار فئة بداية، وتسرد المواضيع الفردية التي تم نقلها من تلك الفئة حسب التاريخ:
-- قائمة المواضيع المنقولة
-- [params]
-- date :start_date
-- date :end_date
-- category_id :cat_id
SELECT
pr.user_id, pr.post_id, pr.updated_at,
(regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[1]::int AS old_category_id,
(regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[2]::int AS new_category_id
FROM post_revisions pr
WHERE (regexp_match(pr.modifications, 'category_id:\s*-\s*([0-9]+)\s*-\s*([0-9]+)'))[1]::int = :cat_id::int
AND pr.updated_at::date BETWEEN :start_date::date AND :end_date::date
ORDER BY pr.updated_at DESC
لست شخصًا يمتلك “ذاكرة مجتمعية أفضل” منك، ولكن على أي حال، يبدو نهجك معقولًا. يسعدني أن شخصًا ما يراجع المواضيع غير المحلولة - وإذا كنت أفهمك بشكل صحيح، فإن المواضيع التي لا تحتوي على أي رد لن يتم إغلاقها تلقائيًا دون تنشيط (لديّ عدد قليل منها معلقة هناك بنفسي…)
@tobiaseigen أشعر أن المواضيع عادةً (والأكثر شيوعًا) تُنقل في غضون 1-3 أيام منذ إنشائها. ربما يجب إضافة مؤقت الموضوع بدءًا من اليوم الثالث فصاعدًا لتسهيل وقت احتياطي أثناء نقل المواضيع؟ على الرغم من أنني أشك في إمكانية ذلك بدون إضافة.
ما هي الفائدة من إغلاق جميع المواضيع؟ لماذا توجد مشكلة لدى الأشخاص الذين يواجهون نفس المشكلات التي يواجهها صاحب الموضوع الأصلي، في إضافة رد إلى موضوع موجود بالفعل، حتى لو كان هذا الموضوع قديماً؟
يجعل Discourse الأمر سلساً للغاية لتقسيم الردود الخارجة عن الموضوع إلى موضوع جديد ببضع نقرات، وبفضل مساعد الذكاء الاصطناعي، لا تعاني حتى من شلل التحليل في تحديد العنوان والفئة والعلامات، مما يجعلني أعتقد أن قاعدة صارمة لإغلاق جميع مواضيع الدعم تبدو قديمة الطراز وشيئاً قد يكون ضرورياً في برامج المنتديات القديمة.
رائع! شكرًا على جميع الردود هنا. أنا سعيد لأنني بدأت هذا الموضوع لأعرف كيف يشعر الناس حياله.
ربما أكون مخطئًا بشأن هذا، لكن شعوري الشخصي من تجربتي في الأشهر الأخيرة هو أن فئة Support تختلف عن الفئات الأخرى التي نملكها حاليًا. يأتي الناس رغبةً في حل مشكلة في الحال، وغالبًا ما تكون المشكلة محددة جدًا بظروفهم الخاصة. إذا لم يتم حل الموضوع بسرعة معقولة، فإنهم يفقدون الاهتمام ويبتعدون، أو يصبحون مستعجلين ويطلبون مرة أخرى في مواضيع أخرى. وفي الوقت نفسه، يمكن أن تصبح فئة الدعم مليئة بالأسئلة غير المجابة. ثم يقوم مسافرون آخرون لاحقًا بإعادة رفع هذه الأسئلة لطرح أسئلتهم الخاصة المختلفة قليلاً، وهو ما سيكون من الأفضل طرحها في موضوع جديد.
هذا يختلف عن الفئات الأخرى حيث نسمح ونشجع على وجود مواضيع مفتوحة النهاية. عندما ينشر الأشخاص مواضيع في Support تنتمي إلى فئات أخرى، مثل كونها في الواقع طلب ميزة (Contribute > Feature request)، يمكننا نقلها. أو إذا كان شخص ما يبحث عن مساعدة في إنشاء إضافة، نقوم بنقلها إلى Development.
لذلك، بطريقة أو بأخرى، يجب متابعة مواضيع Support التي لم تُجب أو التي انتهت النقاش فيها، بحيث يمكن التوصل إلى حل لها في النهاية. أعتقد أن إضافة رد بعد أسبوع أو أسبوعين، ثم تعيينها للإغلاق بعد 30 يومًا من آخر رد، تبدو طريقة معقولة لضمان حدوث ذلك.
ما أسمع هنا هو أن الإغلاق التلقائي لجميع مواضيع Support بعد 30 يومًا قد لا يكون النهج الصحيح في الواقع، بالنظر إلى أننا غالبًا ما ننقلها، مما يعني أنه يتعين علينا إزالة المؤقت. لكنني ما زلت أعتقد أننا يجب أن نسعى إلى إغلاق جميع مواضيع Support في النهاية.
لذا سأعطل الإعداد التلقائي الآن، لكنني سأستمر في إضافة المؤقت في الحالات التي أعتقد أنها مناسبة. إذا لاحظت أنني قمت بتعيين مؤقت على موضوع تعتقد أنني لم يكن ينبغي أن أفعل ذلك، فأخبرني والسبب.
لقد جربت استعلام مستكشف البيانات ورأيت أنه في الأسابيع الأربعة الماضية قمنا بنقل 53 موضوعًا بشكل جماعي من Support إلى فئات أخرى. هذا يكفي لدرجة أنه سيكون بالتأكيد غير مريح أن نطلب من المشرف إزالة المؤقت التلقائي.
لذا نعود إلى لوحة الرسم لمعرفة كيفية ضمان حصول كل من ينشر في Support على رد في الوقت المناسب!
يبدو أن إضافة المؤقت قد أزالت إعداد الفئة عند إغلاق الموضوعات التي تم تمييزها على أنها محلولة تلقائيًا. لقد قمت بتعيين ذلك على 72 ساعة الآن لأنني لا أتذكر بالضبط ما تم تعيينه عليه من قبل.
كمستخدم، أشعر بالإحباط دائمًا عندما أواجه مشكلة لدي، وأجد موضوعًا ذا صلة أرغب في النشر فيه، وألاحظ أنه مغلق (لا أتحدث عن المواضيع التي تم حلها ).
ثم يتعين علي إما الاتصال بالموظفين وطلب منهم فتح الموضوع أو إنشاء موضوع جديد عندما يكون الموضوع الأصلي هو المكان المناسب للرد.
أنا لا أتحدث تحديدًا عن ميتا، ولكن فيما يتعلق بتجربتي كمستخدم في منتديات أخرى حيث مررت بذلك.
شكرًا لك! تم الإصلاح. تم التحديد بالساعات وليس بالأيام أو الأشهر، لذا اضطررت لاستخدام الآلة الحاسبة. 720 ساعة!
تعديل: أيضًا، تذكرت للتو أنني يمكنني التحقق من سجل إجراءات الموظفين. لقد سجل أنه تم إزالة 720 عندما أضفت مؤقت الإغلاق التلقائي. لكن أن النظام لم يحذّرني في واجهة المستخدم عند حفظ التغييرات أمر غريب بعض الشيء. لقد أشرت إلى هذه المشكلة في موضوع Contribute > UX.
لقد حدث هذا لي أيضًا. عادةً ما أبدأ موضوعًا جديدًا بـ “متابعة المحادثة من [الموضوع المغلق]…”
في بعض الأحيان يكون لدي مجرد فكرة أو اقتراح لإضافته، بدلاً من المزيد من الأسئلة - ولكن أتخيل أن الأولوية لموظفي الدعم يجب أن تكون رؤية الأسئلة الجديدة. يبدو أنه قد يكون من الصعب ضمان ذلك إذا تُركت الموضوعات التي تم حلها مفتوحة باستمرار لإضافة مشاركات إضافية.
لإنهاء هذه المحادثة.. شكراً على كل المدخلات والمساعدة في التفكير في هذا الأمر.
بالنسبة لمواضيع #الدعم، ما زلت مقتنعاً بأن الهدف هو إغلاقها في غضون بضعة أسابيع في جميع الحالات تقريباً. إنها الطريقة الوحيدة للتأكد من أن كل من يطلب المساعدة يتم الرد عليه في الوقت المناسب. بدون ذلك، سيبدأ الناس في فقدان الثقة وسيبحثون عن إجابات في مكان آخر.
لقد لاحظت أنه إذا كان هناك سبب لترك موضوع مفتوحاً، فعادة ما يكون مناسباً أيضاً لنقله إلى فئة أخرى.
لكنني أتفق على أن فكرة الإغلاق التلقائي لمواضيع #الدعم بعد 30 يوماً من آخر رد لن تنجح معنا. نريد التأكد من أنها تم حلها بالفعل، وتجنب موقف تكون فيه الفئة مليئة بالأسئلة التي لم تتم الإجابة عليها أو تمت الإجابة عليها جزئياً فقط.
).