「誰が修正する可能性が最も高いか」に基づいてカテゴリを選択するのは少し奇妙に感じます。デザイナーが修正するからといって、グローバルなdisplay: noneのために空白のフォーラムもバグではないと言いますか？
もちろん、「問題ない、とにかく1つ選択すれば移動できる」と言うこともできますが、これは投稿の場合にのみ役立ちます。過去のレポートを見つけようとするときは、これらの問題の両方を#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カテゴリのパターンに従います - 機能カテゴリについて
タグ付け
- 中間的な場所というテーマに沿って、トピックの性質に応じて、このカテゴリのトピックに#completed::tagまたは#fixed::tagを適用できます。
うーん、これはバグとして分類するべきでしょう…純粋に実用的な観点からですが、UXはより曖昧なものを引き寄せるため、私自身がトリアージすることが多いです。
この場合、そのバッジの問題は私には翻訳バグのように見えます。
実際、これもバグのように感じます。ここでは解釈の余地はなく、私たちのテキストは明らかに間違っており、更新が必要です。
これは、私にとってはUXのテーマに非常に近いものです。具体的な推奨事項はまだありませんが、ペインポイントに関するオープンな議論です。これは、将来的に特定のバグ/機能トピックを抽出するためのストーリーと場所を提供してくれます。
おそらく、ここで必要なのは、ルールをより明確にすること、UXをオープンで構造化されていない議論やユーザーストーリーのために残し、「明確な欠陥」をバグに、「明確な要望リスト」を機能に維持することでしょう。
この世界ではすべてが非常に曖昧であることは理解していますが、魔法の杖を振ってすべてを修正するのは困難です。
しかし、期待をより明確にすることは確かに役立つでしょう。
「いいね！」 7
皆さんは今、ユーザーを迂回しています。企業が物事をどのように割り当てたり分類したりするかを知ることはできませんし、これからもできません。それは完全に内部的なことです。私たちができることは、それがバグなのか、UXの問題なのか、それとも全く別のものなのかを推測することだけです。そして、モデレーターやスタッフは、Discourseの非常にコアな部分で計画されているように、その後、魔法をかけます。
では、このトピックは実際にスタッフとパワーユーザーのためのもので、私たちのような凡人はこれ以上追うのをやめてもいいのでしょうか、それとも、例えば、ファイルレベルなのかコンテナレベルなのかによって画像と画像の違いがわからない私が、CDCKのどこが問題に対処するのかを推測する能力を持っていると本当に考えている人がいるのでしょうか？
より一般的なレベルでは、少なくとも2つの側面があります（誰もが知っているように）：
- カテゴリーは厳密な境界線を持つ論理的な箱ではない
- カテゴリーは、パブリックかインターナルか、どちらのユーザーのために作られたのか
わかりません…私はポリシーに従ってきました。
- 問題が自分にあるのかわからない場合はサポートを使用する
- 何かが計画通りに機能していると感じた場合はUXを使用する
- 何かが停止したり、場所を完全に壊したりした場合はバグを使用する
しかし、誰がどのポジションで対処しようとするかに応じてカテゴリーを選択することはありません。それは純粋に管理上の問題です。
「いいね！」 2
UX をタグにするというアイデアは良いと思います（開発もタグにできるかもしれません？）。しかし、別のカテゴリに属しているとは感じられない UX のケースもあるだろうという点には同意します。
また、技術的には機能であっても、例えば以下のような、投票するための機能カテゴリには不釣り合いに思えるほど小さなトピックもあります。Clickable components instead of just the Edit button
しかし、気にするべきではないのでしょうか？何かを変更することを求める問題は、どんなに小さくても機能カテゴリに属するべきでしょうか？
あるいは、「提案」というカテゴリを設けるべきでしょうか？これは、壊れておらず、本格的な機能リクエストではなく、やり方についての質問でもないものです。そして、内部で開発または UX タグを付けることができます。
編集：すでに UX タグがあることに気づきました。現時点ではあまり活用されていません。
「いいね！」 4
「提案」カテゴリは重要だと思われます。私のコミュニティ2つにはそれがあります。
タグが見過ごされることもありますが、「提案」カテゴリはそれが何のためのものかが非常に明確です。
「いいね！」 1
ここでのカテゴリについて、それほど変更が必要だとは思いません。しばらくの間うまく機能していましたし、誤った分類は発生しますが、私の見る限りでは負担になるような頻度ではありません。メンション、タグ、アサインが内部トリアージの役に立たないのであれば、何か問題が起きているように感じます…なぜなら、それらのオプションはたくさんあるからです。
「いいね！」 2
深く掘り下げてみると、@moin、よくわかりません 
ここでの問題の核心は次のことだと思います。
- Samは、#uxから#bugへ何かを再分類します。
- Samは、誰かの投稿に触れることが、相手を気分を悪くさせたり、間違いを犯したと感じさせたりする可能性があることを知っています。
- Samは謝罪します。
- その後、ユーザーは混乱し、自己修正を望み、痛みを伴うサイクルが発生します。
ここでの根本的な問題は、おそらく次のことでしょうか？
Samは、ビジネスニーズによりよく対応するために、必要に応じて自由に再分類できるべきであり、毎回そのことについて謝罪する必要はないのではないでしょうか？
「いいね！」 2
ここ数週間、ディスカッションに参加したり、UX Bug Feature カテゴリのトピックに取り組んだり、自分でトピックを作成したりする中で、このトピックについて考えてきました。
これは間違いなく当てはまると思います。Sam とチームメンバーは、トピックに対応し、解決策を見つけるために、必要に応じて自由にトピックをカテゴリ分けしたりタグ付けしたりできます。これらの決定について混乱しているメンバーは、@moderators に連絡することができます。
これは、UX に属するトピックの素晴らしい例です。小さく、インターフェースの改善に特化しています。また、コミュニティメンバーとチーム間の協力が、非常に質の高い生活改善につながるという、私たちが望む協力の素晴らしい例でもあります。
Charlie が挙げた例を続けると、私たちのチームが取り組む必要がある分野は、これらのトピックを最後まで追求してクローズすることです。この非常に優れた協力関係でさえ、いくつかの未解決の点がありました。これは、ここでの議論と協力の流れの中で自然なことであり、私たちのエンジニアとデザイナーは忙しいです。その結果、提案がいかに優れていても、リクエストがいかに小さく感じられても、UX の強化は時々見落とされてしまいます。しばらくすると、@moderators がこれらを特定し、対応を支援することができます。
UX カテゴリの説明を更新し、内部的なアプローチを公開しました。これにより、UX と他のカテゴリ Feature および Bug のどちらに何が入るのか、より理解しやすくなることを願っています。
Discourse のユーザーインターフェースにおける軽微な表示の問題や小さな変更、および機能の表示方法（言語や UI 要素を含む）に関する議論。何か大きなことよりも、「生活の質」に関するトピックです。
これが十分に明確でない場合や、さらに改善できる点があれば教えてください。Bug と Feature も同様の扱いをしたいと考えていますが、今は控えます。
「ux」タグももっと使うべきだと思います。トリアージに役立つと思います。サポートやバグのトピックでも、UXに関係するものはあります。これにより、「これはバグだが、視覚的なものだ。#bugに入れるべきか、#uxに入れるべきか」という疑問も解決されます。
=> バグにするが、「ux」タグを付ける
「ux」カテゴリは、主に改善提案や不明瞭な点に使うべきだと思います。壊れているものは除くべきです。
少なくとも、その区別は私には理にかなっています。
「いいね！」 3
ux タグをもっと活用することに賛成です。3つのカテゴリすべてで！UXを重視する人は、そのタグをフォローできます。
まだ完全に一致していないようです。私の考えでは、UX はバグと機能リクエストの両方を含めることができますが、それらは「生活の質」の小さな改善でなければならず、大きなものであってはなりません。UIに本当に問題がある場合は、Bug になります。それが主要なプロジェクト（例：タグのメタ説明の編集を許可する）の場合は、Feature になります。
あなたの考えに合わせて、UX カテゴリの説明をどのように改善しますか？
良い質問ですね。例えば、次のように言えるでしょう…
UXトピックは、製品が技術的には意図したとおりに動作するものの、デザイン、インタラクション、またはフローがユーザーに不必要な摩擦、混乱、または非効率性を引き起こす場合に使用されます。
また、次のような内容も適切だと思います。
しかし、実際に壊れているものは、たとえ小さくても、UXタグ付きのバグとして扱うべきだと思います。
「いいね！」 3
新しい UX の説明についてどう思いますか？ 少しぎこちない感じがしますが、より簡潔になりました。これで良いと思いますか？（私も、タグがカテゴリバナーに正しく表示されないという UX の トピック を自分で投稿しました）
原文：
Discourse のユーザーインターフェースと、機能（言語や UI 要素を含む）がどのように提示されるかについての議論。
現在の説明：
Discourse のユーザーインターフェースにおける軽微な表示の問題や既存機能の小さな変更、および機能（言語や UI 要素を含む）がどのように提示されるかについての議論。何か大きなことよりも「生活の質」に関するトピックが中心です。
提案された新しい説明：
UX のトピックは、Discourse が技術的には意図したとおりに機能するものの、デザイン、インタラクション、またはフローがユーザーに不必要な摩擦、混乱、または非効率性を引き起こす場合に使用されます。また、「生活の質」の小さな改善のためにも使用されます。トピックの性質に応じて completed または fixed が適用されます。
「いいね！」 1
ありがとうございます。それで結構です🙏
クール！変更しました。
（ちなみに、説明の変更がカテゴリバナーに表示されるまで数分かかるのは奇妙です。ハードリフレッシュでも表示されません。）
「いいね！」 2