سؤال سريع حول ما سبق. ماذا عن المواضيع المغلقة تلقائيًا مع وجود حل؟ منطقيًا، يريد المرء أن تظهر تلك المواضيع لأن لديها حل، ولكن إذا فهمت بشكل صحيح، فإنها حاليًا أقل بروزًا تلقائيًا.
15 إعجابًا
هل هذا شيء يمكننا تبديله بإعداد موقع؟ في بعض الحالات، قد يكون الموضوع مغلقًا ومحلولًا. وعلى العكس من ذلك، قد يتوقع بعض المستخدمين أن يكون ذلك أعلى في النتائج.
أنا سعيد جدًا لرؤية البحث يحظى ببعض الاهتمام. القدرة على البحث تحديدًا حسب الفئة هي بالفعل ميزة كبيرة لحالة استخدامنا.
الشيء الوحيد الذي أود رؤية بعض التحسين عليه هو الأخطاء الإملائية الشائعة. لقد أفسدتني بعض محركات البحث لدرجة أنني سأضرب المفاتيح بكسل حتى يظهر مزيج من الأحرف لا يشبه الكلمة الأصلية إلا بشكل غامض في شريط البحث 
. لا أتوقع أن تتم مطابقة ذلك، ولكن التحسينات في هذا المجال ستكون خطوة كبيرة إلى الأمام.
9 إعجابات
رأي جريء! أعتقد أنه سيكون من الأفضل الحفاظ على الاتساق (أي، عدم وجود خيار لكل موقع)، و:
- زيادة أولوية المشاركات المغلقة التي تم حلها (لتكون أكبر من المشاركات المفتوحة).
- إضافة خيار مؤقت (من الناحية المثالية، لكل فئة و/أو لكل علامة) لـ أرشفة المشاركات المغلقة تلقائيًا.
- ضمن المشاركات المؤرشفة، إعطاء الأولوية لتلك التي تحتوي على حلول - ولكن ليس لدرجة أن تظهر فوق المشاركات غير المؤرشفة.
إخلاء مسؤولية: نعم، أريد ميزة الأرشفة التلقائية هذه لموقعي الخاص! ولكني أعتقد أنها منطقية بشكل عام. يجب التخلص من أي شيء تم الرد عليه ولكنه غير ذي صلة على الأرجح. وإذا كنت لا تريد ذلك (أسئلتك المحلولة دائمة الخضرة)، فلا تقم بتمكين الأرشيف.
8 إعجابات
لماذا، لأنه يجعل جانب المطور أسهل؟ أم لأنه يسهل حياة المستخدمين عند تنقلهم بين المنتديات؟ شيء آخر؟
السبب الأول ليس سببًا على الإطلاق - طالما أن عبء العمل معقول والمهمة ممكنة في هذا الواقع. الثاني سبب وجيه لـ MS أو Apple، الذين لا يريدون الكفاح كثيرًا مع العملاء، ولكن بخلاف ذلك - كمسؤول ومنشئ محتوى، أريد خدمة مستخدمي، وليس الحفاظ على الأشياء متشابهة هنا أو هناك أو في أي مكان آخر 
لذا - الخيار الثالث هو الخيار المثير للاهتمام.
4 إعجابات
كلاهما. ولأنه يقلل من تعقيد المسؤول. بدلاً من المزيد من الخيارات (وفرصة عدم إدراك وجود إعداد للقيام بما تريده)، تراجع وابحث عن نمط عام بحيث يعمل النمط المطلوب ببساطة في معظم الحالات.
7 إعجابات
هذه بالتأكيد نقطة قوية.
ولكن. هل يمكننا استخدام حل آخر ومألوف: الإعدادات المخفية؟
أرى هنا استراتيجيتين مختلفتين الآن:
- هل يجب أن يتمتع المسؤولون بحرية تامة في ضبط الأجزاء المهمة، مثل نتائج البحث، لأن احتياجات المجتمع مختلفة ولا تعتمد على المنصة (هذا سؤال برمجة/تطوير)
- هل يجب معاملة المسؤولين كمستخدمين آخرين والحفاظ على الأمور منظمة وواجهة مستخدم نظيفة، والسماح لـ CDCK بتحديد ماذا وأين ولماذا
بالنظر إلى #support، كلا الطريقين لهما إيجابيات وسلبيات ولكن لا يزال - الاتجاه الأول هو نوع من أجزاء عالم المصادر المفتوحة، في حين أن الأخير هو طريقة آبل.
المزيد من الخيارات يولد المزيد من الأسئلة والمشكلات التي يطرحها المسؤولون غير المهرة مثلي. المزيد من الخيارات يمكن أن يعطي نتائج أفضل للمستخدمين والزوار. إذن؟
بالنسبة لي السؤال سهل جداً: أريد الحصول على أقوى بحث ممكن، وإذا كان إغلاق موضوع ما سيؤدي إلى انخفاض ترتيبه في نتائج البحث، فلن أغلق المواضيع بعد الآن أو نادراً جداً. خيار سهل، ولكن بعد ذلك يجب أن أتصرف بسبب قيود البرنامج، وليس بسبب احتياجات المجتمع.
إذن - الاستراتيجيات شيء مختلف عن التكتيكات
4 إعجابات
لدينا سوابق كثيرة للمقابض هنا، لدينا أولوية البحث لكل فئة يمكن لأي مسؤول تكوينها.
أنا بالتأكيد لست ضد بعض المقابض الإضافية حول كيفية زيادة (أو تقليل) مكافأة “المؤرشف/المغلق/المحلول” في نتائج البحث.
إنها مهمة جانبية بعض الشيء، نوصي بفصلها إلى موضوع آخر مع اقتراح واضح حول الإعدادات التي قد تكون منطقية؟
8 إعجابات
أود أن أعمل على تحديد الخطوات التالية المحتملة لإجراء تغيير هنا نظرًا للاهتمام الذي تم التعبير عنه حتى الآن.
حاليًا، هذا هو المنطق:
حسب @sam:
لاحظ الحالة الاستثنائية هنا!
في meta… نظرًا للضوضاء في Support نميل إلى إعطاء الأولوية المنخفضة لها… بمجرد إعطاء الأولوية المنخفضة لها، فإن مكافأة ترتيب الإغلاق لم تعد سارية…
لذا، هناك شيء آخر يجب مراعاته وهو كيفية تفاعل هذا مع أوزان الفئات.
أشعر أن نهجًا تكراريًا هنا يمكن أن يكون كالتالي:
- فقط أضف حالة للحل
WHEN topics.solved then 1.1 - غيّر أوزان الأرشيف والإغلاق والحل لتكون مضاعفات لوزن الفئة وبعضها البعض.
- اجعل مضاعفات أوزان الأرشيف والإغلاق والحل قابلة للتكوين عبر إعدادات الموقع.
ربما يكون من المنطقي القيام بكل هذه الأمور دفعة واحدة. أو ربما نقوم بـ (1) و (2) أولاً وننتظر قبل جعلها قابلة للتكوين. ما رأيك @sam؟
3 إعجابات
يبدو أن استخدام المضاعفات هو نهج جيد بشكل عام، لكنني أعتقد أنه من الصعب التعبير عما كنت أقترحه أعلاه.
مغلق غير محلول < مفتوح غير محلول < مفتوح محلول < مغلق محلول
يجب أن يؤدي الإغلاق إلى زيادة الأولوية للمنشورات المحلولة ولكن تقليل للمنشورات غير المحلولة.
المنشورات المغلقة التي لا تحتوي على حل لا قيمة لها تقريبًا - واجه شخص آخر هذه المشكلة، ولكن لا يوجد حل لها هنا، ولا يمكنك تقديم حل. المنشورات المغلقة مع الحلول، من ناحية أخرى، هي ذهب. فهي ليست محلولة فحسب، بل محلولة بشكل قاطع.
4 إعجابات
حسنًا، علاوة على ذلك، ذكرت المواضيع المؤرشفة سابقًا أيضًا:
إذن، إذا فهمت بشكل صحيح، هل تفضل ترتيب الأشياء بهذه الطريقة؟
(من الأعلى إلى الأدنى)
- مغلق محلول
- مفتوح محلول
- مفتوح غير محلول
- مغلق غير محلول
- مؤرشف محلول
- مؤرشف غير محلول
(ثم إضافة التعقيد الطبقي لتصنيفات الفئات بطريقة ما أيضًا)
إعجابَين (2)
نعم، بشكل أساسي، على الرغم من أن ترتيب المشاركات المؤرشفة قد لا يهم:
المشاركات المؤرشفة التي تحتوي على حلول من المحتمل أن تكون غير ذات صلة ولكنها قد تكون مثيرة للاهتمام تاريخيًا. المشاركات المؤرشفة بدون حلول هي نفسها بشكل أساسي - إذا كنت تبحث في الأرشيف، فمن المحتمل أن يكون ذلك للتاريخ، لذا فإن الحالة المحلولة هي معلومة ولكن إذا كان الأمر مهمًا أي منها يجب تضمينه بشكل صريح في استعلامك.
إعجابَين (2)
هل تستخدم أوزان الفئات بنفسك؟ إذا كان الأمر كذلك، فهل لديك آراء حول ما إذا كان يجب أن تتجاوز هذه الأوزان المستندة إلى الحالة كما هي الآن أم أن تكون مضاعفة؟
إعجاب واحد (1)
أعتقد أن التبديل للبحث في فئة معينة كافٍ ويمكن أن يكون جيدًا للتخلص من هذا الوزن عند البحث (لأن الناس يبحثون عن حلول، وليس فئات أو مواضيع/فئات مقترحة).
رأيي، أتفق تمامًا مع ما تفعله هنا 
إعجابَين (2)
نعم، بالتأكيد أستخدمها. لدينا بعض الفئات “لسير العمل” التي لا ينبغي أن تظهر أبدًا إلا إذا طُلب منها، وفئات أخرى هي إعلانات وأخبار أكثر أهمية.
أنا أبتكر هذا الآن لذا أحتفظ بحقي في التراجع عن رأيي في المستقبل، ولكن شعوري هو أنني أريد أن تتجاوز أوزان الفئات جميع أوزان حالة الموضوع، باستثناء الأرشيف. أفكر في حالة الأخبار هنا. يجب أن تظهر هذه في النتائج العالية عندما تكون جديدة، ولكن ليس على الإطلاق بعد فترة زمنية معينة. ويمكن أن يكون أرشفة المشاركات طريقة كل موقع لتحديد ما تعنيه “فترة زمنية معينة” هناك.[1]
بدلاً من ذلك، وربما أبسط: اجعل أوزان الفئات تتجاوز، ثم قدم خيارًا لكل فئة لتفضيل المشاركات الجديدة، وإذا تم تحديد ذلك، فستكون هناك مضاعف يتناقص بمرور الوقت (من 2x إلى 0.5x، على سبيل المثال).
ثم لا يزال هناك طلب الميزة الخاص بالأرشفة التلقائية في وقت محدد، ولكن التفاصيل، التفاصيل! ↩︎
إعجابَين (2)
حسنًا، ما أفهمه هو أن أوزان الفئات يجب أن تكون لها الأسبقية.
أعتقد أنه يجب أن تنطبق أوزان “تم الحل” / “مغلق” / “مؤرشف” ضمن الفئة.
أسمعك أيضًا بشأن مؤقت الأرشفة التلقائي… إنه مكمل، لكنني أعتقد أنه يمكننا تحقيق بعض التقدم هنا أولاً بدونه.
إعجاب واحد (1)
أختلف هنا. قد يكون للموضوع إجابة جيدة، لكن صاحب الموضوع لم يكلف نفسه عناء تمييزها كحل / لم تكن الحلول متاحة إذا كان الموضوع قديمًا، وما إلى ذلك.
الموضوع المفتوح له ميزة أنه يمكنك دفعه، لكنني لن أضع الكثير من الوزن على ذلك. أفضل رؤية المحتوى الأكثر صلة بناءً على الكلمات المفتاحية.
فيما يتعلق بالأرشفة، أتفق - بالنسبة لي هذا محتوى لم يعد ذا صلة ويمكن أن يكون له وزن أقل.
إعجابَين (2)
لماذا يتم إغلاق مثل هذا الموضوع؟ (و، استباقيًا: “لأن الموقع مُعد لإغلاق المواضيع بعد N يومًا” هو إجابة عن كيف تم إغلاق الموضوع، وليس لماذا.)
3 إعجابات
أعتقد أنه للحفاظ على هذه التغييرات قابلة للإدارة، فإن المرحلة صفر هي المهمة التافهة:
- أضف إعداد الموقع
prioritize_solved_topicsالافتراضيtrue - عند تعيينه على
true، امنح الموضوع المحلول 1.1 دون قيد أو شرط.
لا يحل هذا جميع المشكلات هنا، ولكنه سيمنحنا قدرًا معقولًا من التقدم بسرعة.
المشكلة من منظور قابلية التوسع ليست تغييرًا سهلاً على الإطلاق.
لا يوجد عمود “محلول” في جدول المواضيع، وما نضطر إلى القيام به هنا هو حقن نوع من الربط من “المحلول” في الحقول المخصصة للموضوع… هذا يعني أنه يجب تحويل استعلام SQL هذا بطريقة مفصلة للغاية:
إما
-
نحتاج إلى حقن
LEFT JOINفي المكون الإضافي “المحلول”LEFT JOIN topic_custom_fields ts where name = 'accepted_answer_id' and value IS NOT NULL AND and topic_id = topics.id -
نحتاج إلى تحويل عبارة
CASEهذه، مما يعني على الأرجح جعل عبارة CASE بأكملها قابلة للتركيب باستخدام مكون إضافي.
بدلاً من ذلك، قد نتمكن من القيام بشيء مثل CASE EXISTS(...) THEN 1.1 مما يلغي الحاجة إلى ربط يساري ولكنه يأتي بمخاطره الخاصة.
سأفكر في هذه المشكلة، التحدي الكبير هنا هو معرفة كيفية عدم إنشاء فوضى كبيرة عن طريق إضافة هذا الدعم نظرًا لأن “النواة” لا تعرف شيئًا عن المواضيع المحلولة.
8 إعجابات
@mcwumbly إنها من تلك التي يكون فيها القيام بالعمل أسهل بالفعل من تحديد العمل…
لقد حاولت:
7 إعجابات
هذا يحدث تقريبًا في كل مرة بالنسبة لي! لا يمكنني أبدًا فهم المواصفات حتى أكتب الكود الذي أنا متأكد من أنه يعمل. هذا (جزئيًا) لأنني عادةً ما أكتب الكود لمواصفات لا أفهمها. في مناسبتين تمكنت من كتابة المواصفات أولاً مثل شخص بالغ، لكن هذا نادر جدًا.
من الجيد سماع أن هذا يحدث لك أحيانًا أيضًا. 
5 إعجابات