أردت الاطمئنان عليكم جميعًا بشأن تجربة أجربها. من المحتمل أن يتمتع البعض منكم بذاكرة مجتمعية أفضل مني، لذا يرجى تثقيفي!
لقد قمت بتعيين فئة Support بحيث يتم إغلاق المواضيع تلقائيًا بعد 30 يومًا من آخر رد. يبدو هذا مناسبًا بالنظر إلى تجربتي الأخيرة في الفئة. بحلول ذلك الوقت، تكون المواضيع قد تم حلها أو انتقل الشخص الذي طرح السؤال. يمكن للآخرين الذين لديهم أسئلة مماثلة بدء مواضيع جديدة خاصة بمواقفهم.
خلال الأشهر العديدة الماضية، كنت أقوم بفرز مواضيع Support القديمة التي لم يتم حلها، باستخدام هذا الفلتر في الشريط الجانبي الخاص بي. في كثير من الحالات، يتم حل المواضيع بسرعة بفضل الأعضاء اليقظين والمفيدين الذين يجيبون على الأسئلة. في بعض الأحيان تحتاج المواضيع إلى دفعة بعد أسبوع أو أسبوعين للاطمئنان على الشخص الذي يطلب المساعدة لمعرفة ما إذا كانت مشكلته قد تم حلها، وطرح أسئلة توضيحية قد تساعدهم (ما هي خطوات إعادة الإنتاج؟ هل استخدمت تعليمات التثبيت الرسمية؟ هل تعمل في الوضع الآمن؟ إلخ). عندما أفعل ذلك، عادةً ما أضيف مؤقتًا للموضوع ليتم إغلاقه تلقائيًا بعد 30 يومًا من آخر رد. إذا لم يستجب الشخص أو عضو آخر في المجتمع في غضون 30 يومًا، فأعتقد أنه من المناسب تمامًا السماح للموضوع بالإغلاق تلقائيًا.
ومع ذلك، هناك أيضًا حالات يكون فيها من المنطقي نقل المواضيع من Support إلى فئة أخرى، وقد كنت أفعل ذلك أيضًا. على سبيل المثال:
→ Community = أسئلة بناء مجتمع مفتوحة
→ Dev = تخصيص، إنشاء إضافات جديدة، إلخ
→ Feature أو UX = طلبات الميزات أو تحسينات/إصلاحات واجهة المستخدم
→ Bug = تقارير الأخطاء
من خلال تعيين المواضيع في Support ليتم إغلاقها تلقائيًا بعد شهر بدلاً من القيام بذلك يدويًا، فإنني أوفر على نفسي بعض الوقت لأنه حاليًا استخدام مفتاح المسؤول للقيام بذلك أمر مرهق بعض الشيء. إنه يبعد عدة نقرات!
هل فكرت في كيفية العثور على المواضيع التي تم نشرها في #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 تنتمي إلى فئات أخرى، على سبيل المثال، لأنها في الواقع طلب #feature، يمكننا نقلها. أو إذا كان شخص ما يبحث عن مساعدة في إنشاء إضافة، فنحن ننقلها إلى Dev.
لذلك، بطريقة أو بأخرى، يجب متابعة مواضيع Support التي لم تتم الإجابة عليها أو حيث يتلاشى النقاش حتى يمكن التوصل إلى حل في النهاية. أعتقد أن إضافة رد بعد بضعة أسابيع ثم ضبطها للإغلاق بعد 30 يومًا من آخر رد يبدو طريقة معقولة للتأكد من حدوث ذلك.
ما أسمعه هنا هو أن الإغلاق التلقائي لجميع مواضيع Support بعد 30 يومًا ربما ليس النهج الصحيح بعد كل شيء، نظرًا لأننا غالبًا ما ننقلها مما يعني أننا بحاجة إلى إزالة المؤقت. لكنني ما زلت أعتقد أنه يجب أن نهدف إلى إغلاق جميع مواضيع Support في النهاية.
لذلك سأقوم بإيقاف الإعداد التلقائي في الوقت الحالي ولكن سأستمر في إضافة المؤقت في الحالات التي أعتقد أنها منطقية. إذا لاحظت أنني قمت بتعيين مؤقت لموضوع تعتقد أنه لا ينبغي عليّ ذلك، فأخبرني والسبب.
لقد جربت استعلام مستكشف البيانات ورأيت أنه في الأسابيع الأربعة الماضية قمنا بنقل 53 موضوعًا بشكل جماعي من Support إلى فئات أخرى. هذا يكفي لدرجة أنه سيكون بالتأكيد غير مريح أن نطلب من المشرف إزالة المؤقت التلقائي.
لذا نعود إلى لوحة الرسم لمعرفة كيفية ضمان حصول كل من ينشر في Support على رد في الوقت المناسب!
يبدو أن إضافة المؤقت قد أزالت إعداد الفئة عند إغلاق الموضوعات التي تم تمييزها على أنها محلولة تلقائيًا. لقد قمت بتعيين ذلك على 72 ساعة الآن لأنني لا أتذكر بالضبط ما تم تعيينه عليه من قبل.
كمستخدم، أشعر بالإحباط دائمًا عندما أواجه مشكلة لدي، وأجد موضوعًا ذا صلة أرغب في النشر فيه، وألاحظ أنه مغلق (لا أتحدث عن المواضيع التي تم حلها ).
ثم يتعين علي إما الاتصال بالموظفين وطلب منهم فتح الموضوع أو إنشاء موضوع جديد عندما يكون الموضوع الأصلي هو المكان المناسب للرد.
أنا لا أتحدث تحديدًا عن ميتا، ولكن فيما يتعلق بتجربتي كمستخدم في منتديات أخرى حيث مررت بذلك.
شكرًا لك! لقد قمت بإصلاحه. تم تحديده بالساعات وليس الأيام أو الأشهر، لذلك اضطررت إلى استخدام الآلة الحاسبة. 720 ساعة!
تعديل: أيضًا، تذكرت للتو أنه يمكنني التحقق من سجل إجراءات الموظفين. لقد سجل أنني قمت بإزالة الـ 720 عند إضافة مؤقت الإغلاق التلقائي. ولكن عدم تحذيري في واجهة المستخدم عند حفظ التغييرات أمر غريب بعض الشيء. لقد أشرت إلى هذه المشكلة في موضوع UX.
لقد حدث هذا لي أيضًا. عادةً ما أبدأ موضوعًا جديدًا بـ “متابعة المحادثة من [الموضوع المغلق]…”
في بعض الأحيان يكون لدي مجرد فكرة أو اقتراح لإضافته، بدلاً من المزيد من الأسئلة - ولكن أتخيل أن الأولوية لموظفي الدعم يجب أن تكون رؤية الأسئلة الجديدة. يبدو أنه قد يكون من الصعب ضمان ذلك إذا تُركت الموضوعات التي تم حلها مفتوحة باستمرار لإضافة مشاركات إضافية.
لإنهاء هذه المحادثة.. شكراً على كل المدخلات والمساعدة في التفكير في هذا الأمر.
بالنسبة لمواضيع #الدعم، ما زلت مقتنعاً بأن الهدف هو إغلاقها في غضون بضعة أسابيع في جميع الحالات تقريباً. إنها الطريقة الوحيدة للتأكد من أن كل من يطلب المساعدة يتم الرد عليه في الوقت المناسب. بدون ذلك، سيبدأ الناس في فقدان الثقة وسيبحثون عن إجابات في مكان آخر.
لقد لاحظت أنه إذا كان هناك سبب لترك موضوع مفتوحاً، فعادة ما يكون مناسباً أيضاً لنقله إلى فئة أخرى.
لكنني أتفق على أن فكرة الإغلاق التلقائي لمواضيع #الدعم بعد 30 يوماً من آخر رد لن تنجح معنا. نريد التأكد من أنها تم حلها بالفعل، وتجنب موقف تكون فيه الفئة مليئة بالأسئلة التي لم تتم الإجابة عليها أو تمت الإجابة عليها جزئياً فقط.
).