上記について簡単な質問です。ソリューションがある自動クローズ済みトピックはどうなりますか？論理的には、ソリューションがあるので表示させたいと思いますが、もし私が正しく理解していれば、現在それらは自動的に目立たなくなっています。
「いいね！」 15
これはサイト設定で切り替えられるものですか？場合によっては、トピックがクローズされ、解決済みになることもあります。逆に、ユーザーによっては結果でそれを高く評価するかもしれません。
検索に注目が集まっているのを見て、とても嬉しく思います。カテゴリ別に具体的に検索できることは、私たちのユースケースにとってすでに大きなプラスです。
改善を望む点は、一般的なスペルミスです。検索エンジンによっては、私が怠惰にキーを叩き、元の単語にわずかに似ている文字の組み合わせが検索バーに入るまでになるほどです😅。そこまでのマッチングは期待していませんが、その分野の改善は大きな前進となるでしょう。
「いいね！」 9
過激な意見！一貫性を保つ（つまり、サイトごとのオプションなし）方が良いと思います。そして：
- 解決済みのクローズ済み投稿の優先度を（オープンな投稿よりも高く）上げる。
- クローズ済みの投稿を自動的にアーカイブするためのタイマーオプション（理想的には、カテゴリごとおよび/またはタグごと）を追加する。
- アーカイブされた投稿の中で、解決済みのものを優先する — ただし、アーカイブされていない投稿よりも表示されるほど高くはない。
免責事項：はい、私自身のサイトでその自動アーカイブ機能を望んでいます！しかし、一般的に理にかなっていると思います。回答されたが、おそらく無関係なものはすべて片付けるべきです。そして、もしあなたがそれを望まないなら（あなたの解決済みの質問は不朽のもの）、アーカイバーを有効にしないでください。
「いいね！」 8
それは、開発者側が楽になるからですか？ それとも、ユーザーが Discourse 間を移動する際に、ユーザーの生活が楽になるからですか？ それ以外ですか？
最初の理由は理由になりません。作業負荷が人間的で、現実世界でタスクが可能である限り。2番目の理由は、MSやAppleにとっては良い理由ですが、顧客とあまり争いたくないからです。しかし、それ以外の場合は、管理者およびコンテンツ作成者として、私はユーザーにサービスを提供したいのであって、ここ、そこ、または他の場所と同じようなものを維持したいわけではありません。 
したがって、3番目のオプションが興味深いものです。
「いいね！」 4
どちらもです。そして、管理の複雑さを軽減します。より多くのオプション（そして、望むことを行う設定があることに気づかない可能性）の代わりに、一歩下がって一般的なパターンを見つけることで、ほとんどの場合、望ましいパターンが機能するようになります。
「いいね！」 7
それは間違いなく強力な点です。
しかし、別の、しかしまだ馴染みのあるソリューション、つまり隠し設定を使用することはできますか？
現在、2つの異なる戦略が見られます。
- コミュニティのニーズは異なり、プラットフォームに依存しないため、管理者は検索結果のような重要な部分を自由に調整できるべきか（これはコーディング/開発の問題です）
- 管理者は他のユーザーとして扱われ、CDCKが何を、どこで、なぜ決定するかを決定させ、すっきりとクリーンなUXを維持すべきか
#supportを見ると、どちらの方法にも長所と短所があります しかし、それでも最初の方向性はオープンソースの世界の一部であり、後者はAppleの方法です。
より多くのオプションは、私のようなあまり熟練していない管理者によって、より多くの質問や問題を生み出します。より多くのオプションは、ユーザーや訪問者により良い結果をもたらす可能性があります。それで？
私にとって、質問は非常に簡単です。可能な限り強力な検索機能を取得したいのですが、トピックを閉じると検索結果でのランキングが低下する場合、トピックを閉じなくなったり、非常にまれにしか閉じなくなったりします。簡単な選択ですが、コミュニティのニーズではなく、ソフトウェアの制限のために行動しなければなりません。
したがって、戦略は戦術とは異なるものです
「いいね！」 4
ここでは十分な前例があります。管理者が設定できるカテゴリごとの検索優先度があります。
「アーカイブ済み/クローズ済み/解決済み」のボーナスが検索結果でどのように（上昇または下降）するかについて、さらに多くの設定を追加することに反対するものではありません。
これは少し横道にそれたクエストなので、どのような設定が適切かについての明確な提案とともに、別のトピックに分割することをお勧めします。
「いいね！」 8
現時点で表明されている関心事を考慮して、ここでの次のステップを検討したいと思います。
現在のロジックは次のとおりです。
@sam氏より：
ここでのエッジケースに注意してください！
metaでは… Support のノイズを考慮して、優先度を下げる傾向があります… 優先度が下がると、クローズされたランキングボーナスはもはや適用されなくなります…
したがって、カテゴリの重み付けとの関連性も考慮すべき点です。
ここでは反復的なアプローチが考えられます。
- 解決済みの場合を追加するだけです
WHEN topics.solved then 1.1 - アーカイブ済み、クローズ済み、解決済みの重みを、カテゴリの重みと互いに乗数に変更します。
- アーカイブ済み、クローズ済み、解決済みの重み乗数をサイト設定で設定可能にします。
これらすべてを一度に行うのが理にかなっているかもしれません。あるいは、(1) と (2) を最初に行い、設定可能にするまで待つという方法もあります。@samさん、どう思いますか？
「いいね！」 3
乗数を使用することは一般的に良いアプローチのように思えますが、上記で提案したことを表現するのは難しいと思います。
未解決のクローズ < 未解決のオープン < 解決済みのオープン < 解決済みのクローズ
クローズは解決済みの投稿の優先度を上げるべきですが、未解決の投稿の場合は「下げる」べきです。
解決策のないクローズされた投稿はほとんど価値がありません。他の誰かがこの問題を抱えていましたが、ここには答えがなく、あなたは提供できません。一方、解決策のあるクローズされた投稿は非常に価値があります。それらは単に解決されただけでなく、決定的に解決されています。
「いいね！」 4
OK、さらに、以前にアーカイブされたトピックについても言及されていました。
つまり、正しく理解していれば、次のようにランク付けしたいということですか？
（最も高いものから最も低いものへ）
- 解決済みのクローズ済み
- 解決済みのオープン
- 未解決のオープン
- 未解決のクローズ済み
- 解決済みのアーカイブ
- 未解決のアーカイブ
（そして、カテゴリのランク付けのレイヤー化された複雑さを何らかの方法で追加します）
「いいね！」 2
はい、基本的に、アーカイブされた投稿の順序はおそらく関係ありません。
解決策のあるアーカイブされた投稿は、おそらく関連性がありませんが、歴史的に興味深い可能性があります。解決策のないアーカイブされた投稿は基本的に同じです。アーカイブを検索している場合、それはおそらく歴史のためなので、解決された状態は情報ですが、それが重要であれば、クエリに明示的に含める必要があります。
「いいね！」 2
それ自体でカテゴリの重み付けを使用していますか？もしそうなら、その重み付けは現在のステートベースの重み付けをオーバーライドすべきか、それとも乗算的であるべきかについて、何かお考えはありますか？
「いいね！」 1
特定のカテゴリを検索するためのスイッチは十分であり、検索時にその重みを破棄できるのは良いことだと思います（人々はカテゴリや提案されたトピック/カテゴリではなく、ソリューションを検索しているため）。
私の意見ですが、ここで行っていることには完全に同意します 
「いいね！」 2
はい、間違いなく使用しています。「ワークフロー」カテゴリは、基本的に求められない限り表示されるべきではありません。また、アナウンスやニュースなど、より重要なカテゴリもあります。
これは 今まさに 思いついたことなので、将来的に意見が揺らぐ可能性はありますが、カテゴリの重み付けは、アーカイブされたものを 除く すべてのトピックステータスの重み付けを上書きしたいと考えています。ここでニュースのケースを考えています。新鮮なうちは結果の上位に表示されるべきですが、ある程度の時間が経ったら全く表示されないようにします。そして、投稿のアーカイブは、各サイトが「ある程度の時間」が何を意味するかを指定する方法になり得ます。[1]
あるいは、もっと単純に、カテゴリの重み付けを上書きし、その後、新鮮な投稿を優先するためのカテゴリごとのオプションを導入し、それがチェックされている場合は時間が経つにつれて（例えば2倍から0.5倍に）低下する乗数を導入するという方法もあります。
そして、タイマーによる自動アーカイブのRFEもありますが、細かいことはどうでもいい！ ↩︎
「いいね！」 2
承知いたしました。カテゴリの重み付けを優先すべきということですね。
解決済み/クローズ済み/アーカイブ済みの重み付けは、カテゴリ内で引き続き適用されるべきだと思います。
アーカイブの自動タイマーについても承知いたしました。補完的なものですが、まずはこれなしで進めることができると思います。
「いいね！」 1
ここでは同意しかねます。トピックには良い回答があるかもしれませんが、投稿者が解決策としてマークしなかったか、古いトピックの場合は解決策が利用できなかった可能性があります。
オープンなトピックには、それを「bump」できるという利点がありますが、それほど重要視しません。キーワードに基づいて、より関連性の高いコンテンツを見ることを好みます。
アーカイブについては同意します。私にとって、これはもはや関連性のないコンテンツであり、重要度が低くなる可能性があります。
「いいね！」 2
そのようなトピックはなぜ閉じられるのですか？（そして、先回りして言いますが、「サイトがN日後にトピックを閉じるように設定されているため」というのは、トピックがどのように閉じられたかに対する答えであって、なぜ閉じられたかの答えではありません。）
「いいね！」 3
この変更を管理可能にするためには、フェーズゼロは些細なものだと思います。
- サイト設定
prioritize_solved_topicsをデフォルトtrueで追加する trueに設定された場合、解決済みトピックに無条件で 1.1 を与える。
これはすべての奇妙な点を解決するわけではありませんが、迅速に合理的な進歩を遂げることができます。
問題は、拡張性の観点からは、これはまったく簡単な変更ではないということです。
トピックテーブルには「解決済み」の列がありません。ここで私たちがしなければならないのは、解決済みからトピックカスタムフィールドへの何らかの結合を注入することです。これは、このSQLを非常に手の込んだ方法で変換する必要があることを意味します。
どちらか
-
解決済みプラグインに
LEFT JOINを注入する必要があります。LEFT JOIN topic_custom_fields ts where name = 'accepted_answer_id' and value IS NOT NULL AND and topic_id = topics.id -
この条件
CASEステートメントを変換する必要があります。これはおそらく、プラグインを使用してCASEステートメント全体を構成可能にする必要があることを意味します。
あるいは、CASE EXISTS(...) THEN 1.1 のようなもので済ませることができるかもしれません。これにより、左結合の必要性がなくなりますが、それ自体のリスクが伴います。
この問題について考えてみます。ここでの大きな課題は、「コア」が解決済みトピックについて何も知らないことを考えると、このサポートを追加することによって巨大な混乱を作り出さない方法を見つけることです。
「いいね！」 8
@mcwumbly 作業する方が、作業を仕様化するよりも実際には簡単なタイプのものです…
試してみました：
「いいね！」 7
私にとっては、ほとんどすべてがそうです！コードを書いてから、それが機能していると確信できるまで、仕様を理解することはほとんどできません。これは（部分的に）私が通常理解していない仕様のためにコードを書いているからです。数回、大人らしく先に仕様を書くことができましたが、それは非常にまれです。
あなたにも時々起こることを聞いてよかったです。 
「いいね！」 5