يبدو الأمر غريباً بعض الشيء اختيار فئة بناءً على “من هو الأكثر احتمالاً لإصلاح المشكلة”. هل ستقول أيضاً أن منتدى فارغ بسبب استخدام display: none عالمياً ليس خطأً لأن مصمماً هو من سيصلحه؟
وبطبيعة الحال، يمكنك القول “إنه لا يهم، ببساطة اختر واحدة، يمكننا نقلها”، لكن هذا يساعد فقط عند النشر. عندما أحاول العثور على تقارير سابقة، سأبحث عن كلتا المشكلتين في Contribute > UX. هل من الممكن تتبع مسؤولية الإصلاح بشكل مستقل عن الفئات؟
10 إعجابات
أنا معك، هذا مربك للغاية، ومن الصعب جدًا على المشغلين معرفة ما يجب فعله هنا.
@tobiaseigen / @jordan.vidrine هل لديكم أي أفكار حول هذه المشكلة؟
@Moin هل لديك أي اقتراحات حول كيفية عمل هذا بشكل أفضل؟
أعتقد أن أحد البدائل هو ببساطة أن تعيش الأشياء في ميزة/خطأ بشكل غير مشروط واستخدام العلامات للإشارة إلى تجربة المستخدم.
إنها مشكلة صعبة بالتأكيد.
4 إعجابات
يبدو لي هذا حلاً جيداً. من الواضح إلى أي فئة يجب النشر، ويمكن لأولئك المهتمين بـ UX متابعة هذا الوسم. وميزة إضافية أخرى هي أننا نستطيع حذف فئة!
لا أعرف كيف يمكنني تحليل المواضيع الموجودة حالياً في Contribute > UX والتي من المرجح أن ترغب في الانتقال إلى Contribute > Bug أو Contribute > Feature. قد يكون تمريناً جيداً لمراجعة وتنظيف ذلك.
4 إعجابات
بعض الأفكار من جانبي:
- أعتقد أن تقسيم أكثر من 3000 موضوع إلى فئتين فقط هو الكثير من العمل، وأتساءل من سيكون لديه الوقت لتولي هذه المهمة.
- علاوة على ذلك، لا أعتقد أنه يمكن تقسيم جميع الموضوعات في تجربة المستخدم (UX) بسهولة إلى ميزة (Feature) وخطأ (Bug). بالنسبة لي، فإن تقريرًا عن نص لا يمكن ترجمته ليس تقريرًا عن خطأ حقًا[1]. وبالمثل، فإن الإشارة إلى نص غير مفهوم أو قديم ليست طلب ميزة ولا تقرير خطأ[2]. وبالمثل، فإن أوصاف تجارب المستخدم التي لا تحتوي على خطأ ولا اقتراح تحسين ملموس لا تتناسب مع فئتي الميزة أو الخطأ[3].
- لا أعرف كيف تعاملتم مع هذا الأمر حتى الآن، ولكن كان لدي انطباع بأن المطورين، عند الضرورة، عملوا أيضًا على موضوعات تجربة المستخدم (UX)، والعكس صحيح. أتساءل عما إذا كان من الممكن الحفاظ على الأمور كما كانت، مع قيام المجموعة التي تراقب الفئة ببساطة بإبلاغ المجموعة الأخرى عند الحاجة، دون نقل المنشور. ومع ذلك، لا يمكنني تقييم هذا بالكامل، لأنني لا أعرف العمليات السابقة أو الحالية.
5 إعجابات
شكرًا يا موين! تطرحين نقاطًا جيدة. كنت أنظر أيضًا إلى العدد الإجمالي لمواضيع Contribute > UX وهو كثير جدًا! 
ربما تكمن المشكلة التي نواجهها في أن فئة Contribute > UX غير موصوفة بشكل كافٍ، ولذلك ينشر الناس فيها أشياء يجب أن تكون في Contribute > Bug أو Contribute > Feature. إليك كيفية وصفنا لها في وثائقنا الداخلية.
تُعد فئة #ux::category نوعًا من الجسر الوسيط بين فئة #feature::category وفئة #bug::category. بشكل عام، تذهب مشكلات العرض الطفيفة هنا بدلاً من فئة #bug::category، وهي المكان المخصص للتغييرات الصغيرة على الميزات الموجودة. مواضيع أكثر تتعلق بـ «جودة الحياة» منها إلى أي شيء كبير.
بشكل عام، يجب أن يتبع التعامل مع هذه المواضيع نمط فئة #feature::category - حول فئة الميزات
الوسم
هممم، هذا سأصنفه كخطأ… من وجهة نظر عملية بحتة، ولكنه يُصنف بشكل متكرر أكثر من قبل نفسي لأن تجربة المستخدم تجذب أشياء أكثر غموضًا.
في هذه الحالة، تبدو مشكلة الشارة هذه خطأ في الترجمة بالنسبة لي.
في الواقع، يبدو هذا أيضًا خطأ بالنسبة لي، لا يوجد شيء مفتوح للتفسير هنا، نصنا خاطئ تمامًا ويحتاج إلى تحديث.
هذا، مع ذلك، يقع ضمن نطاق تجربة المستخدم بالنسبة لي، إنه نقاش مفتوح حول نقطة ألم دون أي توصيات ملموسة حتى الآن. إنه يعطينا قصة، ومكانًا لاستخلاص مواضيع أخطاء/ميزات معينة منها في المستقبل.
ربما كل ما نحتاجه هنا هو توضيح القواعد بشكل أفضل، وترك تجربة المستخدم للنقاش المفتوح غير المنظم وقصص المستخدمين والاحتفاظ بـ “العيوب الواضحة” في قسم الأخطاء… و “قوائم الرغبات الواضحة” في قسم الميزات.
أتفهم أن كل شيء رمادي جدًا في هذا العالم، ومن الصعب إلقاء عصا سحرية وإصلاح كل شيء.
ومع ذلك، فإن الوضوح بشأن توقعاتنا سيساعد بالتأكيد.
7 إعجابات
أنتم تتجاوزون المستخدمين الآن. لا يمكننا (ولن) معرفة كيف تقوم الشركة بتعيين أو تصنيف الأشياء. إنه أمر داخلي تمامًا. كل ما يمكننا فعله هو تخمين ما إذا كان شيء ما خطأً، أو مشكلة في تجربة المستخدم، أو شيئًا مختلفًا تمامًا. ويقوم المشرفون والموظفون بعملهم السحري بعد ذلك، كما هو مخطط له في جوهر Discourse.
إذًا، هل هذا الموضوع مخصص بالفعل للموظفين والمستخدمين المتميزين، ويمكننا نحن الفانين الآخرين التوقف عن متابعته، أم أن شخصًا ما يعتقد حقًا أنني، على سبيل المثال، أنا، الذي لا يمكنني معرفة الفرق بين صورة وصورة اعتمادًا على ما يحدث على مستوى الملف أو الحاوية، لدي القدرة على التساؤل عن أي منصب داخل CDCK سيهتم بقضية ما؟
على مستوى أعم، هناك جانبان، على الأقل (كما يعلم الجميع):
- الفئات ليست صناديق منطقية حيث توجد حدود صارمة
- للمستخدمين الذين تم إنشاء الفئات لهم، عامة أو داخلية
لا أعرف… لقد اتبعت سياسة حيث أستخدم
- الدعم إذا كنت لا أعرف ما إذا كانت المشكلة مني،
- تجربة المستخدم إذا كان لدي شعور بأن شيئًا ما مخطط له ليعمل بهذه الطريقة
- خطأ إذا توقف شيء ما عن العمل أو كسر الأماكن تمامًا
لكنني لن أختار فئة أبدًا اعتمادًا على من في أي منصب سيحاول الاهتمام بها. إنه سؤال إداري بحت.
إعجابَين (2)
أعجبني فكرة تجربة المستخدم كعلامة (وربما وجود علامة للتطوير أيضًا؟)، لكنني أتفق على أنه قد تكون هناك حالات لتجربة المستخدم تبدو وكأنها لا تنتمي حقًا إلى فئة مختلفة أيضًا.
وبعض المواضيع قد تكون ميزة تقنية، لكنها صغيرة جدًا، بحيث تبدو في غير مكانها في فئة الميزات للتصويت عليها، على سبيل المثال: Clickable components instead of just the Edit button
ولكن ربما لا ينبغي أن نهتم؟ وأي مشكلة تطلب تغيير شيء ما تنتمي إلى فئة الميزات، بغض النظر عن مدى صغرها؟
أو ربما يجب أن يكون لدينا فئة “اقتراحات” - للأشياء التي ليست معطلة، وليست طلب ميزة كامل، وليست حول كيفية القيام بالأشياء. وبعد ذلك يمكننا وضع علامة عليها للتطوير أو تجربة المستخدم داخليًا.
تعديل: أدركت أن لدينا بالفعل علامة لتجربة المستخدم، ولكنها حاليًا غير مستخدمة بشكل كافٍ.
4 إعجابات
يبدو أن فئة “الاقتراحات” مهمة. أنا أستخدمها في مجتمعي.
أحيانًا يمكن تجاهل وسم معين، أو قد لا تكون فئة Contribute > UX واضحة بما يكفي لبعض المستخدمين، لكن فئة “الاقتراحات” توضح الغرض منها بوضوح.
إعجاب واحد (1)
لا أعتقد حقًا أننا بحاجة إلى تغيير الكثير في الفئات هنا، فقد كانت تعمل بشكل جيد لفترة من الوقت ويحدث التصنيف الخاطئ، ولكن ليس بمعدل مرهق من وجهة نظري. إذا لم تكن الإشارات والعلامات والإسنادات كافية للفرز الداخلي، ف يبدو أن هناك خطأ ما… لأن لدينا الكثير من الخيارات هناك.
3 إعجابات
بالتعمق في الأمر، لست متأكداً يا @moin 
أعتقد أن جوهر المشكلة هنا هو:
- يقوم سام بإعادة تصنيف شيء ما من Contribute > UX إلى Contribute > Bug
- سام يدرك كيف يمكن أن يؤدي لمس أي شيء يتعلق بمنشور أي شخص إلى شعوره بالسوء، أو بالشعور بأنه ارتكب خطأً
- سام يعتذر
- ثم يصاب المستخدمون بالارتباك، ويسعون لتصحيح أوضاعهم ذاتياً، مما يخلق حلقة مؤلمة.
ربما تكون الجذر الحقيقي للمشكلة هنا هو:
يجب أن يشعر سام بالحرية في إعادة التصنيف كما يرى مناسباً لتلبية احتياجات أعمالنا بشكل أفضل، وألا يعتذر عن كل شيء يقوم به من ذلك؟
إعجابَين (2)
لقد فكّرتُ في هذا الموضوع خلال الأسابيع القليلة الماضية، بينما شاركتُ في النقاشات، وتناولتُ مواضيع في فئات Contribute > UX و Contribute > Bug و #contribute:feature، وأنشأتُ مواضيع خاصة بي.
أعتقد أن هذا صحيح بالتأكيد. إن سام وأعضاء الفريق أحرار في تصنيف المواضيع ووسمها كما يرون مناسبًا، وذلك في إطار الاستجابة للموضوع والوصول إلى حل. وإذا كان الأعضاء مرتبكين بشأن هذه القرارات، فيمكنهم التواصل مع @moderators.
هذا مثال رائع لموضوع ينتمي إلى Contribute > UX. إنه صغير ويتعلق تحديدًا بتحسين الواجهة. كما أنه مثال ممتاز على نوع التعاون بين أعضاء المجتمع والفريق الذي نرغب في رؤيته، والذي يؤدي إلى تحسينات لطيفة جدًا في جودة الحياة. 
مستمرين في المثال الذي ذكره تشارلي، فإن مجال يحتاج فريقنا إلى العمل عليه هو متابعة مواضيع مثل هذه حتى نهايتها ليتم إغلاقها. حتى هذا التعاون الممتاز ترك بعض الأطراف غير المكتملة. وهذا أمر طبيعي في تدفق النقاش والتعاون هنا، ومهندسونا ومصممونا مشغولون. ونتيجة لذلك، تسقط تحسينات تجربة المستخدم أحيانًا بين الفجوات، بغض النظر عن جودة الاقتراح أو صغر حجم الطلب. وبعد مرور بعض الوقت، يمكن لـ @moderators المساعدة في تحديد هذه الحالات وتوجيهها إلى نهايتها.
حدّثتُ وصف فئة Contribute > UX لنجعل النهج الداخلي الذي اتبعناه في هذه الفئة علنيًا. وآمل أن يساعد ذلك الجميع على فهم أفضل لما يدخل في Contribute > UX مقارنة بالفئات الأخرى Contribute > Feature و Contribute > Bug.
نقاش حول مشاكل العرض البسيطة والتغييرات الصغيرة في واجهة مستخدم Discourse، وكيفية عرض الميزات (بما في ذلك اللغة وعناصر واجهة المستخدم). مواضيع تركز أكثر على «جودة الحياة» بدلاً من أي شيء ضخم.
تُطبّق وسوم completed أو fixed على المواضيع في هذه الفئة حسب طبيعة الموضوع.
أخبروني إذا لم يكن هذا واضحًا بما يكفي أو إذا كان بإمكانكم التفكير في تحسينات إضافية. أود منح Contribute > Bug و Contribute > Feature نفس المعاملة، لكنني سأؤجل ذلك للحظة.
أعتقد أنه ينبغي علينا أيضًا استخدام وسم «ux» بشكل أكبر. سيكون ذلك مفيدًا في التصنيف، أرى ذلك شخصيًا، فقد يكون الموضوع متعلقًا بالدعم أو بالخطأ، لكنه يتعلق بتجربة المستخدم. كما سيحل هذا التردد حول «هذا خطأ، لكنه بصري، فهل يجب وضعه في Contribute > Bug أم في Contribute > UX».
⇒ اجعله خطأً، لكن ضع عليه وسم ux
أعتقد أن فئة Contribute > UX يجب أن تُخصص أساسًا لاقتراحات التحسينات أو الأمور غير الواضحة، وليس للأمور المعطلة.
على الأقل، هذا التمييز يبدو منطقيًا بالنسبة لي.
3 إعجابات
أتفق مع استخدام وسم ux بشكل أكبر، في جميع الفئات الثلاث! يمكن للأشخاص المهتمين جدًا بتجربة المستخدم (UX) متابعة هذا الوسم.
يبدو أننا لسنا متوافقين تمامًا بعد — بالنسبة لي، يمكن أن يحتوي Contribute > UX على كل من تقارير الأخطاء وطلبات الميزات، لكن يجب أن تكون هذه التحسينات صغيرة من نوع “تحسين جودة الحياة” ولا شيء كبير. إذا كان هناك شيء معطل حقًا في واجهة المستخدم، فيجب أن يذهب إلى Contribute > Bug. وإذا كان مشروعًا كبيرًا (مثل السماح بتعديل الوصف الوصفي للوسوم)، فيجب أن يذهب إلى Contribute > Feature.
كيف يمكنك تحسين وصف فئة Contribute > UX لتتوافق مع فهمك للأمور؟
سؤال جيد. أود أن أقول شيئًا مثل…
يُستخدم موضوع تجربة المستخدم (UX) عندما يعمل المنتج تقنيًا كما هو مقصود، ولكن التصميم أو التفاعل أو التدفق يخلق احتكاكًا أو ارتباكًا أو عدم كفاءة غير ضرورية للمستخدمين.
أنا أيضًا موافق على أن يتضمن:
ولكن أعتقد أن أي شيء معطل بالفعل، حتى لو كان صغيرًا، يجب أن يكون مجرد خطأ (bug) مع وسم تجربة المستخدم (UX).
3 إعجابات
ما رأيك في هذا الوصف الجديد لـ #contribute:ux؟ يبدو قليلاً متعثرًا لكنه أكثر إحكامًا. أعتقد أنه يعمل؟ (لقد نشرت موضوعًا خاصًا بي في Contribute > UX هنا للإبلاغ عن أن العلامات لا تظهر بشكل صحيح في لافتات الفئات)
النص الأصلي:
مناقشة حول واجهة المستخدم في Discourse وكيفية عرض الميزات (بما في ذلك اللغة وعناصر واجهة المستخدم).
النص الحالي:
مناقشة حول مشكلات العرض البسيطة والتغييرات الصغيرة في الميزات الموجودة في واجهة المستخدم لـ Discourse، وكيفية عرض الميزات (بما في ذلك اللغة وعناصر واجهة المستخدم). مواضيع أكثر تركيزًا على «تحسين جودة الحياة» من أي شيء كبير.
تُطبق علامات completed أو fixed على المواضيع في هذه الفئة اعتمادًا على طبيعة الموضوع.
المقترح الجديد:
تُستخدم مواضيع UX عندما تعمل Discourse تقنيًا كما هو مقصود، لكن التصميم أو التفاعل أو التدفق يخلق احتكاكًا غير ضروري، أو ارتباكًا، أو عدم كفاءة للمستخدمين. وكذلك للتحسينات الصغيرة في «جودة الحياة». تُطبق علامات completed أو fixed اعتمادًا على طبيعة الموضوع.
إعجاب واحد (1)
شكرا، يبدو جيدًا بالنسبة لي 
رائع! لقد أجريت التغيير.
(على الهامش: من الغريب أن التغييرات في الوصف تستغرق بضع دقائق لتظهر في لافتة الفئة. حتى التحديث القوي لا يفعل ذلك.)
إعجابَين (2)