When having new messages in the New, Unread… category, there is a dismiss button that dismiss all the messages in them but it would be great if there where a way to dismiss single message (without needing to opening them)
「いいね！」 8
We have no plans to do this at the moment. Why not read the ones you want then Dismiss on the rest that remain?
「いいね！」 1
Agreed.
Maybe if there are too many / more messages to be dismissed, there’s actually a need to review your tracked items.
Because, for example in my case, I haven’t got the time to see all the new topics I want to see at once, so I remain them as “new” but I see them when I have time. There are others that I know I don’t want to see because of any reason, I just want to dismiss them (actually I open them to simulate de dismiss) without dismiss all of the unread topics (to read them any time soon).
「いいね！」 1
So you’re wanting something like the Admin Bulk wrench where you can select checkboxes?
「いいね！」 3
We already have keyboard shortcuts for bookmark / unbookmark (j + b) … I would be fine to add another shortcut for “r” or something if someone wants to do a PR, its pretty simple.
「いいね！」 3
私はこのフォーラムの初心者で、正直なところこの特定の問題があるからこそここにいます。私は管理者ではなく、ユーザーです。しかし、これは単純なインターフェースの問題のようですが、いくつかのスレッドを読み進めてみると、誰かがこの話題を取り上げるたびに、「読みたいメッセージをすべて読み、読みたくないものを却下する」ことが、このシステムをユーザーが使う唯一適切な方法であるという前提が置かれているようです。それどころか、その考えが設計に組み込まれています。この要望が議論の中で繰り返し取り上げられているのに、トピックを読まずに単一の新しいトピックを却下する機能の実装に対して大きな抵抗があるのは興味深いことです。
私が参加しているコンソーシアムでDiscourseを利用していますが、読みたいものだけを除外するためにすべての新しいトピックをレビューする時間的余裕はありません。しかし同時に、サイト上で設計されたほぼすべてのカテゴリに作成されるすべての新しいトピックを見ないという余裕もありません。ほぼすべてのトピックには、協働作業に対する認識を維持するために必要な情報が含まれている可能性が高いです。つまり、コンソーシアムが開発したDiscourseにアクセスするたびに、確認すべき投稿された情報からますます遅れをとってしまいます。
「新しいトピック」リストを「未読」リストとして使い、読む必要がない、あるいは読みたいと望まない個別のトピックを却下して絞り込むことができれば、「すべて却下」オプションを利用できる可能性が高まります。現在、新しいトピックは250件以上あります。その数の新しいトピックを1回のセッション、あるいは数回のセッションで手作業で確認するのは退屈な作業です。ましてや、少しサイトを離れるとさらに多くの新しいトピックが表示されることを考えるとなおさらです。
もしサイト側にとってこれが難しいことではないのであれば、これは多くの人にとって非常に有用な追加機能になると思います。それは、多くの人がリストを管理する非常に一般的な方法に合致しているからです。多くの人は、リストのいくつかの項目にチェックを入れてから、残りをすべてやらないと決めたときにリスト全体を消去するような管理はしません。サイトの「新しいトピック」セクションもこれと非常に似ています。これはレビューすべきもののリストです。
正直に言って、これまで続いている対応についてかなり混乱しています。なぜ、読める時間があるものだけを数件読むのではなく、すべての新しいトピックの件名を読んだ上で、すべての新しいレスポンスを削除することが、長年にわたり多くの人々が指摘している問題に対する解決策とされるのでしょうか？
また、このオプションをキーボードショートカットではなく、インターフェースの一部として実装していただければ幸いです。
「いいね！」 2
ご懸念いただき、またそのように率直に伝えてくださったことに感謝します。ただ、私の経験では、それほど頻繁に話題にはならないようです。例えば、このトピックは2015年のもので、現在でも返信は7件だけです。
確かにこれは少しジレンマですね。一つの方法として、興味のないカテゴリ（またはタグ）をミュート設定するというのはいかがでしょうか？
多くの人は、「トピック一覧をスキャンして、興味のある特定のトピックに入り、あとは閉じる」というアプローチにそれなりに適応していると思います：
なお、意図的な利便性として、新しいトピックまたは未読トピックのリストに十分な件数がある場合、Dismiss…ボタンはリストの上部と下部の両方に表示されます。
「いいね！」 1
Dismiss ボタンが表示されるまでのアイテム数を定義することはできますか？
「閉じる」ボタンは常に表示されますが、トピックのリストが十分に小さい場合のみ、リストの下部に表示されます。トピックのリストが大きい場合は、リストの上部と下部の両方に表示されます。
なるほど。Dismiss は /Unread には表示されますが、ランディングページやカテゴリ内からは表示されません。
「いいね！」 1
ああ、すいません、その点を明確にするべきでしたね。/new ページでも表示されます。そのカテゴリ内の /new または /unread ビューにいる場合、カテゴリ内でも「閉じる」ボタンは表示されます。
申し訳ありません。この会話が5年前のものだと気づいておりませんでした。一見すると最近のもの（2020年6月15日頃）のように見えました。私の確認不足です。
また、この問題がどの程度頻繁に提起されているかという私の認識は、あなたが受け取るリクエストを踏まえて「頻繁」と捉えるあなたの視点とバランスを取る必要があると理解しています。ここで問題を検索すると、私には変更を要するほど頻繁に起こっているように思われましたが、私の「頻繁」の基準があなたの視点では十分でない場合もあると理解できます。この点については、あなたが専門家の立場にあります。
残念ながら、この特定のケースでは、まさにそれができないオプションなのです。そのため、「Dismiss（無視）」オプションは私にとってほとんど役に立ちません。実際には、私が業務上必要としている動作とは逆の直感的な仕組みになっています。
私が定期的に活動しているDiscourseコミュニティでは、各トピックにタグ付けが積極的に行われておらず、タグによるミュートでは見たくないものを排除しつつ、認識しておくべきものを残すことができていません。この場合のトピックは、カテゴリに投稿されているとはいえ、どちらかといえばメールスレッドに近いものです。トピックに対する私の役割は、カテゴリの境界を横断するため、ほとんどのカテゴリをミュートすることは不可能です。可能な範囲でミュートは行いましたが、それでも新しいトピックが多すぎます。
インターフェースにこのような変更を加えることを検討するには、どのような要件が必要でしょうか？つまり、New（新規）またはUnread（未読）リストから個別のトピックをDismiss（無視）できるようにする機能です。この機能強化の開発スケジュールに載せるために必要なリクエストの閾値はあるのでしょうか、それともこれはDiscourseというソリューションの根本的な哲学や運用方法論に反するものなのでしょうか？
「いいね！」 2
これはサイト管理者と話し合うべき課題かもしれません。その Discourse インスタンス内で「サイトフィードバック」としてトピックを作成するのも一案です。タグや追加のカテゴリ分類を導入すれば、多くのユーザーが関心のあるトピックと関心のないトピックを区別できるようになり、メリットがあるのではないでしょうか？
「いいね！」 1
このようなケースに対して、多くの人々がまず取る有効なアプローチは、その機能を Discourse の 拡張機能（例えば、プラグイン や テーマコンポーネント）として開発することです。
あなた自身、あるいはコミュニティ内の誰かがやる気であれば、独立してこれを実現することも可能です。そうでない場合は、仕様を明確にして Marketplace で助けを求めることができます。その拡張機能が人気を得たり、製品全体にとって好適なものであると証明されたりすれば、コア製品に統合される可能性もあります。
ここであなたが行っているように、機能の推奨を行うことが最初のステップとして有効でないと言っているわけではありません。しかし、初期段階でコアチームからの合意や賛同を得ることが難しい場合、拡張機能としての開発という選択肢も効果的な代替案となり得ます。
「いいね！」 3