Кажется немного странным выбирать категорию на основе того, «кто с наибольшей вероятностью исправит проблему». Не считаете ли вы также, что пустой форум из-за глобального правила display: none не является багом, потому что его исправит дизайнер?
И, конечно, можно сказать: «Это не имеет значения, просто выберите любую категорию, мы сможем переместить тему позже», но это помогает только при публикации. Когда я пытаюсь найти предыдущие сообщения об этих проблемах, я ищу их в категории ux. Возможно ли отслеживать ответственность за исправление независимо от категорий?
10 лайков
Я с вами, это вызывает дополнительную путаницу, операторам очень сложно понять, что делать в этой ситуации.
@tobiaseigen / @jordan.vidrine, есть ли у вас какие-либо мысли по поводу этой проблемы?
@Moin, есть ли предложения, как это можно сделать лучше?
Думаю, один из вариантов — просто размещать всё в feature/bug без условий и использовать теги для обозначения ux.
Это действительно сложная задача.
4 лайка
Мне это кажется хорошим решением. Очевидно, в какую категорию публиковать, а те, кто интересуется UX, могут следить за этим тегом. Ещё один плюс — мы можем удалить категорию!
Не уверен, как разделить темы, которые сейчас находятся в ux и, вероятно, должны перейти в bug или #feature. Возможно, стоит пройтись и всё это навести в порядок.
4 лайка
Вот мои мысли по этому поводу:
- Я считаю, что разделение более 3000 тем всего на 2 категории — это огромная работа, и мне интересно, у кого найдётся время взяться за эту задачу.
- Кроме того, я не уверен, что все темы в области UX можно легко разделить на «Функция» и «Ошибка». Для меня сообщение о том, что текст невозможно перевести, не является настоящим отчётом об ошибке[1]. Аналогично, указание на непонятный или устаревший текст не является ни запросом на новую функцию, ни отчётом об ошибке[2]. Точно так же описания пользовательского опыта, которые не содержат ни ошибки, ни конкретного предложения по улучшению, не вписываются в категории «Функция» или «Ошибка»[3].
- Я не знаю, как вы справлялись с этим до сих пор, но у меня сложилось впечатление, что разработчики при необходимости также работали над темами UX, и наоборот. Мне интересно, возможно ли оставить всё как было: группа, отслеживающая категорию, просто информирует другую группу при необходимости, не перемещая пост. Однако я не могу полностью оценить этот вариант, так как не знаю процессов ни в прошлом, ни сейчас.
5 лайков
Спасибо, Мойн! Ты затронул несколько важных моментов. Я тоже посмотрел на общее количество тем в ux, и их действительно очень много! 
Возможно, проблема в том, что категория ux описана недостаточно чётко, поэтому люди размещают там посты, которые должны быть в bug или #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 лайка
Категория Предложения кажется важной. Я использую её на двух своих сообществах.
Иногда тег может быть упущен, или категория ux может быть не так понятна определённым пользователям, но категория Предложения довольно ясно указывает на её назначение.
1 лайк
Я действительно не думаю, что нам нужно много менять в категориях: они уже давно работают нормально. Ошибочная категоризация случается, но, насколько я вижу, не с какой-либо обременительной частотой. Если упоминания, теги и назначения не помогают во внутренней сортировке, значит, что-то идёт не так, ведь у нас есть множество вариантов для этого.
3 лайка
Вникая глубже, я не уверен, @moin 
Мне кажется, что суть проблемы здесь в следующем:
- Сэм меняет категорию чего-либо с ux на bug.
- Сэм знает, что любое изменение в чужом посте может заставить человека почувствовать себя плохо или так, будто он совершил ошибку.
- Сэм извиняется.
- Затем пользователи путаются, хотят исправить ситуацию сами, и возникает болезненный замкнутый круг.
Возможно, корень проблемы именно в этом?
Сэм должен иметь возможность менять категории по своему усмотрению, чтобы лучше соответствовать нашим бизнес-задачам, и не должен извиняться каждый раз, когда он это делает?
2 лайка
Я размышлял об этой теме в течение последних нескольких недель, участвуя в обсуждениях, затрагивая темы в категориях ux, bug и #feature, а также создавая собственные темы.
Я считаю, что это абсолютно верно. Сэм и члены команды свободны категоризировать и помечать темы так, как они считают нужным, в интересах ответа на тему и достижения решения. Если участники запутались в этих решениях, они могут обратиться к @moderators.
Это отличный пример темы, которая относится к категории ux. Она невелика и конкретно касается улучшения интерфейса. Это также прекрасный пример того типа сотрудничества между участниками сообщества и командой, которое нам нравится видеть и которое приводит к значительному улучшению качества жизни пользователей. 
Продолжая пример, приведённый Чарли, области, над которыми нашей команде нужно работать, — это доводить такие темы до конца, чтобы их можно было закрыть. Даже это отличное сотрудничество осталось с некоторыми незавершёнными деталями. Это естественно в потоке обсуждений и сотрудничества здесь, и наши инженеры и дизайнеры заняты. В результате улучшения UX иногда выпадают из поля зрения, независимо от того, насколько хороша идея или насколько малым кажется запрос. Со временем @moderators могут помочь выявить такие случаи и довести их до завершения.
Я обновил описание категории ux, чтобы публично изложить наш внутренний подход к этой категории. Надеюсь, это поможет всем лучше понять, что относится к ux, а что — к другим категориям: #feature и bug.
Обсуждение незначительных проблем отображения и маленьких изменений в пользовательском интерфейсе Discourse, а также того, как представлены функции (включая язык и элементы интерфейса). Больше тем о «качестве жизни», чем о чём-то крупном.
В зависимости от характера темы к темам в этой категории применяются теги completed или fixed.
Дайте знать, если это недостаточно ясно или если вы можете предложить дальнейшие уточнения. Я хотел бы применить такой же подход к категориям bug и #feature, но пока отложу это.
Я думаю, нам стоит чаще использовать тег «ux». Это, на мой взгляд, поможет в сортировке: тема может относиться к поддержке или багам, но при этом касаться UX. Это также решит вопрос «это баг, но он визуальный: стоит ли размещать его в bug или в ux».
=> делайте это багом, но помечайте тегом ux
Я считаю, что категория ux должна быть в основном для предложений по улучшению и для того, что непонятно, а не для того, что сломано.
По крайней мере, такое разделение кажется мне логичным.
3 лайка
Согласен с использованием тега ux чаще, во всех трёх категориях! Люди, которые много заботятся о UX, смогут следить за этим тегом.
Кажется, мы пока не совсем синхронизировались — на мой взгляд, ux может включать как баги, так и запросы на новые функции, но они должны быть небольшими улучшениями «качества жизни» и не быть крупными. Если в интерфейсе что-то действительно сломано, это идёт в bug. Если это крупный проект (например, возможность редактирования мета-описания тега), то это идёт в #feature.
Как бы вы улучшили описание категории ux, чтобы оно соответствовало вашему пониманию?
Хороший вопрос. Я бы сформулировал это примерно так…
Тема UX используется, когда продукт технически работает как задумано, но дизайн, взаимодействие или поток создают ненужные трудности, путаницу или неэффективность для пользователей.
Также я не против, если в него включены:
Но я считаю, что всё, что на самом деле сломано, даже если это мелочь, должно быть просто багом с тегом ux.
3 лайка
Как вам такой вариант нового описания для ux? Чувствуется немного неестественно, но более сжато. Думаю, это сработает? (Я создал тему в ux, чтобы сообщить о том, что теги некорректно отображаются на баннерах категорий)
Оригинал:
Обсуждение пользовательского интерфейса Discourse и того, как представлены функции (включая язык и элементы интерфейса).
Текущий вариант:
Обсуждение незначительных проблем отображения и небольших изменений в существующих функциях пользовательского интерфейса Discourse, а также того, как представлены функции (включая язык и элементы интерфейса). Темы больше о «качестве жизни», чем о крупных изменениях.
В зависимости от сути темы к обсуждениям в этой категории применяются теги completed или fixed.
Предлагаемый новый вариант:
Темы UX используются, когда Discourse технически работает как задумано, но дизайн, взаимодействие или поток создают ненужные трудности, путаницу или неэффективность для пользователей. Также для небольших улучшений «качества жизни». В зависимости от сути темы применяются теги completed или fixed.
1 лайк
Спасибо, мне всё подходит 
Круто! Я внес изменения.
(кстати, странно, что изменения в описании появляются в баннере категории с задержкой в пару минут. Даже полная перезагрузка страницы не помогает.)
2 лайка