Мне кажется немного странным выбирать категорию на основе того, «кто с большей вероятностью это исправит». Вы бы также сказали, что пустой форум из-за глобального display: none — это не баг, потому что дизайнер это исправит?
Конечно, можно сказать: «это не имеет значения, просто выберите одну, мы можем переместить», но это помогает только при публикации. Когда я пытаюсь найти предыдущие отчеты, я бы искал обе эти проблемы в Contribute > UX. Возможно ли отслеживать ответственность за исправление независимо от категорий?
10 лайков
Я с вами, это вызывает дополнительную путаницу, операторам очень сложно понять, что делать в этой ситуации.
@tobiaseigen / @jordan.vidrine, есть ли у вас какие-либо мысли по поводу этой проблемы?
@Moin, есть ли предложения, как это можно сделать лучше?
Думаю, один из вариантов — просто размещать всё в feature/bug без условий и использовать теги для обозначения ux.
Это действительно сложная задача.
4 лайка
Мне это кажется хорошим решением. Очевидно, в какую категорию отправлять тему, а те, кому важен UX, могут подписаться на этот тег. Ещё один плюс — мы сможем убрать одну категорию!
Не уверен, как лучше разобрать темы, которые сейчас находятся в Contribute > UX и которые, вероятно, стоит перенести в Contribute > Bug или Contribute > Feature. Возможно, это будет хорошим упражнением — пройтись по ним и всё привести в порядок.
4 лайка
Вот мои мысли по этому поводу:
- Я считаю, что разделение более 3000 тем всего на 2 категории — это огромная работа, и мне интересно, у кого найдётся время взяться за эту задачу.
- Кроме того, я не уверен, что все темы в области UX можно легко разделить на «Функция» и «Ошибка». Для меня сообщение о том, что текст невозможно перевести, не является настоящим отчётом об ошибке[1]. Аналогично, указание на непонятный или устаревший текст не является ни запросом на новую функцию, ни отчётом об ошибке[2]. Точно так же описания пользовательского опыта, которые не содержат ни ошибки, ни конкретного предложения по улучшению, не вписываются в категории «Функция» или «Ошибка»[3].
- Я не знаю, как вы справлялись с этим до сих пор, но у меня сложилось впечатление, что разработчики при необходимости также работали над темами UX, и наоборот. Мне интересно, возможно ли оставить всё как было: группа, отслеживающая категорию, просто информирует другую группу при необходимости, не перемещая пост. Однако я не могу полностью оценить этот вариант, так как не знаю процессов ни в прошлом, ни сейчас.
5 лайков
Спасибо, Мин! Ты выдвигаешь вполне обоснованные аргументы. Я также подсчитал общее количество тем в категории Contribute > UX, и их действительно очень много! 
Возможно, проблема заключается в том, что категория Contribute > UX описана недостаточно чётко, из-за чего пользователи публикуют в ней вопросы, которые следовало бы размещать в категориях Contribute > Bug или Contribute > Feature. Вот как мы формулируем её описание во внутренней документации.
Категория #ux::category представляет собой своеобразный промежуточный этап между #feature::category и #bug::category. Как правило, незначительные проблемы с отображением следует относить сюда, а не в #bug::category, а в этой категории должны собираться небольшие изменения в существующих функциях. Это скорее темы, связанные с повышением удобства использования, чем с крупными нововведениями.
В целом, работа с такими темами должна следовать модели категории #feature::category — О категории функций
Метки
Хм, этот случай я бы классифицировал как ошибку… с чисто практической точки зрения, но я чаще всего его перенаправляю, так как в UX-направлении чаще встречаются размытые формулировки.
В данном случае проблема с бейджем выглядит как ошибка перевода.
На самом деле это тоже ощущается как ошибка: здесь нет места для интерпретаций, наш текст явно неверен и требует обновления.
Однако это очень вписывается в тему UX: это открытое обсуждение проблемы без конкретных рекомендаций на данный момент. Это даёт нам историю и возможность в будущем выделить из неё конкретные темы для ошибок или новых функций.
Возможно, всё, что нам нужно здесь, — это лучше прояснить правила: оставить UX для открытых неструктурированных обсуждений и пользовательских историй, а «очевидные недостатки» относить к ошибкам, а «чёткие пожелания» — к функциям.
Я понимаю, что в этом мире всё очень размыто, и невозможно волшебной палочкой сразу всё исправить.
Тем не менее, более чёткое изложение наших ожиданий обязательно поможет.
7 лайков
Вы теперь обходите пользователей. Мы не можем (и не будем) знать, как компания присваивает или классифицирует вещи. Это чисто внутреннее дело. Всё, что мы можем сделать, — это гадать, является ли что-то багом, проблемой UX или чем-то совершенно другим. А после этого модераторы и сотрудники делают свою магию, как и задумано в самом ядре Discourse.
Так что этот топик действительно для сотрудников и продвинутых пользователей, а нам, остальным смертным, можно перестать следить за ним? Или кто-то действительно считает, что, например, я, который не может отличить изображение от изображения в зависимости от того, что происходит на уровне файла или контейнера, способен размышлять о том, кто именно в CDCK займётся решением проблемы?
На более общем уровне здесь есть, по крайней мере, два аспекта (как все знают):
- категории — это не логические ящики с чёткими границами
- для кого созданы категории: для публичного использования или для внутренних нужд
Не знаю… Я следую политике, согласно которой я использую:
- «support», если не знаю, связана ли проблема со мной,
- «UX», если у меня есть ощущение, что что-то должно работать именно так,
- «bug», если что-то перестало работать или полностью сломало функционал.
Но я никогда не буду выбирать категорию в зависимости от того, кто именно на какой позиции займётся решением проблемы. Это чисто управленческий вопрос.
2 лайка
Мне нравится идея использовать UX как тег (и, возможно, добавить тег «Разработка» тоже?), но я согласен, что могут быть случаи, связанные с UX, которые не совсем подходят ни к одной отдельной категории.
Кроме того, некоторые темы могут формально относиться к функциям, но быть настолько мелкими, что их было бы неуместно выносить в категорию «Функции» для голосования. Например: Clickable components instead of just the Edit button
Но, возможно, нам не стоит об этом беспокоиться? И любая задача, предлагающая что-то изменить, должна относиться к категории «Функции», независимо от её масштаба?
Или, может быть, стоит создать категорию «Предложения» — для вещей, которые не являются ошибками, не представляют собой полноценные запросы на новые функции и не касаются способов выполнения задач. А затем internally помечать их тегами «Разработка» или «UX».
Редакция: осознал, что у нас уже есть тег «UX», просто он пока используется недостаточно активно.
4 лайка
Категория Suggestions кажется важной. Я добавил её в свои два сообщества.
Иногда тег можно пропустить, а категория Contribute > UX может быть не совсем понятна некоторым пользователям, но категория Suggestions достаточно ясно указывает, для чего она предназначена.
1 лайк
Я действительно не думаю, что нам нужно много менять в категориях: они уже давно работают нормально. Ошибочная категоризация случается, но, насколько я вижу, не с какой-либо обременительной частотой. Если упоминания, теги и назначения не помогают во внутренней сортировке, значит, что-то идёт не так, ведь у нас есть множество вариантов для этого.
3 лайка
Если копнуть глубже, я не уверен, @moin 
Я думаю, что суть проблемы здесь в следующем:
- Сам перекатегоризирует что-то из Contribute > UX в Contribute > Bug
- Сам знает, что любое вмешательство в чужие посты может заставить людей чувствовать себя плохо или думать, что они допустили ошибку
- Сам извиняется
- Затем пользователи путаются, пытаются исправить всё сами, и возникает болезненный цикл.
Возможно, корень проблемы здесь в этом?
Сам должен иметь возможность перекатегоризировать всё по своему усмотрению, чтобы лучше соответствовать бизнес-потребностям, и не должен извиняться каждый раз, когда он это делает?
2 лайка
Я размышлял об этой теме в течение последних нескольких недель, участвуя в обсуждениях, затрагивая темы в категориях Contribute > UX, Contribute > Bug и Contribute > Feature, а также создавая собственные темы.
Я считаю, что это именно так. Сэм и члены команды свободны категоризировать и помечать темы так, как они считают нужным, в интересах ответа на тему и достижения её разрешения. Если участники запутались в этих решениях, они могут обратиться к @moderators.
Это отличный пример темы, которая относится к Contribute > UX. Она невелика и конкретно касается улучшения интерфейса. Это также прекрасный пример того вида сотрудничества между участниками сообщества и командой, которое нам нравится видеть и которое приводит к очень приятным улучшениям качества жизни. 
Продолжая пример, приведённый Чарли, область, над которой нашей команде нужно работать, — это доводить такие темы до конца, чтобы их можно было закрыть. Даже это весьма отличное сотрудничество осталось с некоторыми незавершёнными деталями. Это естественно в потоке обсуждений и сотрудничества здесь, и наши инженеры и дизайнеры заняты. В результате улучшения UX иногда остаются без внимания, независимо от того, насколько хороша идея или насколько малым кажется запрос. Со временем @moderators могут помочь выявить такие случаи и довести их до завершения.
Я обновил описание категории Contribute > UX, чтобы сделать публичным наш внутренний подход к этой категории. Надеюсь, это поможет всем лучше понять, что относится к Contribute > UX, а что к другим категориям: Contribute > Feature и Contribute > Bug.
Обсуждение незначительных проблем отображения и небольших изменений в пользовательском интерфейсе Discourse, а также того, как представляются функции (включая язык и элементы интерфейса). В основном темы, связанные с улучшением качества жизни, а не с крупными изменениями.
В зависимости от характера темы к темам в этой категории применяются теги completed или fixed.
Дайте знать, если это недостаточно ясно или если вы можете предложить дальнейшие уточнения. Я хотел бы применить такой же подход к Contribute > Bug и Contribute > Feature, но пока воздержусь от этого.
Я думаю, нам также стоит чаще использовать тег «ux». Это, на мой взгляд, поможет в сортировке: тема может быть связана с поддержкой или ошибкой, но при этом касаться UX. Это также решит вопрос: «Это ошибка, но она визуальная: стоит ли размещать её в Contribute > Bug или в Contribute > UX?».
⇒ сделать её ошибкой, но добавить тег ux
Я считаю, что категория Contribute > UX должна быть в основном для предложений по улучшению и для моментов, которые непонятны, а не для того, что сломано.
По крайней мере, такое разделение кажется мне логичным.
3 лайка
Согласен с тем, что стоит чаще использовать тег ux во всех трёх категориях! Тогда люди, которым действительно важен UX, смогут подписаться на этот тег.
Однако, похоже, мы пока не совсем согласны — по моему мнению, тег Contribute > UX может включать как баги, так и предложения по улучшению, но только если это небольшие «улучшения удобства использования» и ничего масштабного. Если что-то в интерфейсе действительно сломано, это попадает в Contribute > Bug. Если же это крупный проект (например, возможность редактирования мета-описания тега), то это относится к Contribute > Feature.
Как бы вы улучшили описание категории Contribute > UX, чтобы оно соответствовало вашему пониманию?
Хороший вопрос. Я бы сформулировал это примерно так…
Тема UX используется, когда продукт технически работает как задумано, но дизайн, взаимодействие или поток создают ненужные трудности, путаницу или неэффективность для пользователей.
Также я не против, если в него включены:
Но я считаю, что всё, что на самом деле сломано, даже если это мелочь, должно быть просто багом с тегом ux.
3 лайка
Как насчет такого описания для нового Contribute > UX? Звучит немного неестественно, но более лаконично. Думаю, оно подходит? (Я создал свою тему Contribute > UX topic, чтобы сообщить о том, что теги отображаются некорректно на баннерах категорий)
Оригинал:
Обсуждение пользовательского интерфейса Discourse и способов представления функций (включая языковые элементы и элементы интерфейса).
Текущий вариант:
Обсуждение незначительных проблем с отображением и небольших изменений в существующих функциях пользовательского интерфейса Discourse, а также способов представления функций (включая языковые элементы и элементы интерфейса). Здесь больше тем, касающихся «повышения удобства использования», чем глобальных изменений.
К темам в этой категории применяются теги completed или fixed в зависимости от их характера.
Предлагаемый новый вариант:
Темы с пометкой UX используются, когда Discourse технически работает как задумано, но дизайн, взаимодействие или поток действий создают лишнее трение, путаницу или неэффективность для пользователей. Также сюда относятся небольшие улучшения «повышения удобства использования». Теги completed или fixed применяются в зависимости от характера темы.
1 лайк
Спасибо, мне всё подходит 
Круто! Я внес изменения.
(кстати, странно, что изменения в описании появляются в баннере категории с задержкой в пару минут. Даже полная перезагрузка страницы не помогает.)
2 лайка