下記に示した例のように、そこでの使用法があります。
「いいね！」 3
それが良い考えかどうかはわかりません。結局のところ、私たちユーザーはバグを修正することはできません。それはDiscourseのコードを変更することによってのみ可能であり、それにはチームメンバーの関与が必要です。それが不要な場合、バグはおそらく適切なカテゴリではありません。
ユーザーが回避策を解決策としてマークすることを心配しています。しかし、その場合でもバグは修正されません。したがって、それは役立つよりも混乱を招くでしょう。あなたの例では、すでにバグレポートがあるので、問題は解決されていません。この場合、トピックをマージするのが最善だと思います。そうすれば、ユーザーは最初にフォローしていたトピックに関係なく、修正があったときに通知されます。場合によっては、一方のトピックをもう一方への参照で閉じるのが理にかなっていますが、その場合、閉じられたトピックをサポートしていた「いいね」が失われます。これは、影響を受けるユーザーが「いいね」によって決定される場合には残念です。
「いいね！」 3
Contribute > Bug カテゴリでは、代わりに fixed タグだけを使用しています。ある投稿が重複であるというだけの投稿は実用的ではあっても、特に解決策にはならないため、あそこにそれを置くのも適切ではなかったと思います。
なぜいくつかのカテゴリでは fixed を使い、他のカテゴリでは solved-plugin を使っているのかについては、モインがすでに言及した通りだと考えています。タグの使用は少し厳格なので、何かが修正されたかどうかを決定できるのはチームだけです。
「いいね！」 5
ご提案ありがとうございます！カテゴリの設定方法を常に確認することは良いことです。ご検討いただき、このトピックを開始していただき感謝いたします。
MoinさんとCharlieさんが指摘されたように、私たちのチームは、バグが修正されたことをコミュニティに伝えるために、#fixedとトピックのクローズ（私たちにしかできない操作）に依存しています。これはかなりうまく機能しており、修正が必要なバグの明白なバックログを維持する方法となっています。
バグカテゴリでは、解決済みのプラグインが有効になっているカテゴリのように、解決策を提供できる人がそれに対してクレジットを得られないのは残念なことです。バグカテゴリでは、バグを報告した人は、Discourseチームのメンバーによって好かれた場合にバッジを獲得できます。しかし、再現手順の提供、重複の指摘、解決策の提案などで協力した他の人はクレジットを得られません。これは検討すべき点です。
この場合、Moinさんがレポートが重複していることを指摘したことに対してクレジットを付与できればよかったのですが、トピックを維持することは、チームがすべてのオープンなバグレポートを解析するのを少し難しくする余分なノイズも生み出します。そのため、削除のタイマーを設定しましたので、ご容赦ください。
「いいね！」 1
@tobiaseigen、ロック機能はそのためにあるのではないでしょうか？削除すると、それにリンクしている外部URIの一部が404エラーになり、理想的ではありません。
すべてを保存しているわけではありません！ 
404についてはあまり心配しないでください。
しかし、これは余分な作業なので、全く一貫して実践していません。修正してクローズする際に自動タグ付けするメリットがあると思いますが、修正しない例外的なケースでは特別なタグで編集できます。
ただし、新しい自動化が必要になります。
「いいね！」 4
情報を見つけようと何度も試みたのに、興味深いリンクをクリックしたら404エラーになり、非常に不快な思いをしたことがあります。
この場合、投稿をフラグ付けし、モデレーターが編集または削除します。
これを防ぐには、トピックを削除する前に、最初の投稿のリンクセクションを確認します。
そして、それらのリンク参照を削除することで予防的に対応するのが最善ですが、それにはより多くの作業が必要になります。
「いいね！」 2
私は@tobiaseigenに逆に提案しました。fixedタグを追加する際に、解決済みと同様に自動的にクローズするようにします。
答えは「はい」で、どうでしょうか？ 解決済み（fixed）タグを即座に付与してクローズしたり、#fixedタグがついている場合にトピックをクローズ（またはクローズをスケジュール）する自動化です。#contribute:uxでも#fixedと#completedタグを使って同じことをできます。
#contribute:bugのトピックをクローズする際に、#fixedタグを付与したくないケースはありますか？ クローズされているがタグがないバグ関連のトピックが多数あるようです。今日は少し調査してみます。
解決済みプラグインの動作で気に入ったのは、解決策が選択されると、最後の返信から30日後にトピックが自動的にクローズされるスケジュール設定がなされる点です。これは abrupt（突然）な処理ではなく、必要に応じて引き続きフォローアップできるため便利です。また、人がトピックを再オープンしてほしいとフラグを立てなくなるため、私たちの作業負担も軽減されると思われます。
「いいね！」 1
クローズされたら自動的にタグを追加するという方法が好ましくない理由は、修正されなかった場合や、今後も修正されない（wont-ever-fix）というユースケースがあるためです。タグを追加するという1つのアクションを実行し、その後30日後にトピックが自動的にクローズされるように設定するのが最適だと考えます。
「いいね！」 2
これについて少し時間をかけて検討した結果、@chapoi さんの考え方が正しいと思います。ここで目指すべきは、修正されたアイテムに fixed タグを付ける習慣を身につけ、その後、solved プラグインのように自動的にクローズするタイマーを設定する自動化を作成することだと考えます。必要であれば即座にトピックを閉じることも可能ですが、場合によっては、問題がまだ続いているかどうかを確認し、報告する機会を人々に与えるために、少し長めに開けておくことも重要だと思います。
Rendering 'TypeError' with theme components after update のようなトピックは、OP で報告されたバグが修正されていないため、fixed タグを付けるべきではないと思います。この例では、修正を試みたエンジニアから再現例が得られませんでした。
また、After deleting a topic, the delete button shows up instead of the restore button は重複としてクローズされました。Deleting a topic cannot be undone が修正された時点で、両方に fixed タグを付けてクローズできるでしょうか？しかし、それが確実に実行されるようにするにはどうすればよいのでしょうか？
Contribute > Bug には、クローズされているものの fixed タグが付いていないトピックが 多数あります。これらについて遡って確認していく必要があります。
「いいね！」 3
ここのユーザビリティが問題です。エンジニアにはワンクリックで解決できる方法を提供したいです。
- トピックアクションまたは管理トピックアクションで「修正済み」をクリックします。
- マジックが発生します：
- 1営業日後に閉じるトピックタイマーが作成されます。
- 「修正済み」タグが付けられます。
「トピックにタグを付ける」だけのUXは、非常に手間がかかるため、あまり好きではありません。
- トピックの先頭に移動します。
- タイトルをクリックします。
- タグボックスをクリックします。
- 「修正済み」を検索します。
- 「修正済み」を追加します。
- チェックボックスをクリックします。
これは非常に手間がかかります。
このフローを追加できるのは嬉しいですが、テーマコンポーネントまたはこのUI（これも便利です）を導入する何らかの自動化が必要になります。
「いいね！」 4
私も賛成です！先ほど「Yes, and」と提案した際にも、使いやすさについて考えていました。現在、Contribute > Bug のトピックが解決されたら、単に閉じるという操作に筋肉記憶ができています。これも社内での Todo の扱い方と一致しています。
ワンクリックで「解決済み」にできるボタンというアイデアは気に入りました。
「いいね！」 1
そしてコミュニティがそれを実現しました 
「いいね！」 6
素晴らしい！個人のサイトでNateさんのテーマコンポーネントを試してみましたが、期待通りの動作をしました。非常に良い出来で、実装も早かったです！
ここで使用するには、カテゴリに制限できる必要があります。このアプローチがうまくいくと判断した場合、複数のボタンを作成できるようにしたいとも考えています。
FYI、Samも自動化を使用した、異なる、より柔軟な実験的な実装に取り組んでいます。
「いいね！」 2
メタではこの変更がかなり役立つと思います。サムの実験的な実装を自動化で使用するか、ネイトのテーマコンポーネントをフォークしてここで使用するかどうか、内部でフォローアップしました。
ネイトのコンポーネントは実質的に同じことを行っており、非常に優れていますが、メタにはサードパーティのコンポーネントやプラグインをインストールしないため、フォークする必要があります。
「いいね！」 1
もしそうするのであれば、HackerOne経由で特定されたサイバーセキュリティリスクに対して行うように、Nateに感謝の金銭的報酬を提供することが、誠実な対応となるでしょう。
「いいね！」 2
このトピックは、コミュニティがNateのテーマコンポーネントのようなものを使用することから恩恵を受けるかどうか、に焦点を当てましょう。もしそうであれば、Nateと協力して仕組みを整理します。
もしよろしければ、オープンソースの貢献者が一般的にどのようにその仕事に対して報酬を得るかについて、別のトピックを立ち上げることもできます。
「いいね！」 2