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