それは、サイトの雰囲気として期待していたことのリストにすぎません。Reddit風のテーマやDiscourseには、そのほとんどが最初から組み込まれていました。
Topic List Previewsは、この機能の最初の実装でした。
それは誰の助けにもなりません。この投稿は、他のメンバーの助けを借りて、自分が何ができるか試そうとしているものだからです。できれば、他の人の助けにもなればと思っています 
「いいね！」 2
手を差し伸べようとしたが、あなたは拒絶するばかりだった。
幸運を祈る。
ごめんなさい、私は反論しているわけではありません。あなたの質問にはお答えしましたし、Starzenへのリンクを送ってもらいましたが、それは私が達成しようとしていることとは違うようです。その後、あなたがリンクを貼った彼らの投稿を見たことを伝えました。彼らは何かを「構築」について話していますが、私も何かを「構築」しようとしています。あなたが私が反論していると感じるのは残念ですが、そうではありません。正直に言って、あなたが何を言いたいのか、どこに話を着地させたいのか分かりません。
「いいね！」 3
OPには、そのインスピレーションをくれたことに感謝しています（数週間前、ナビバーで使われているプラグインについて私が質問した際、快く共有してくださいました）。
私の意図は、ソーシャルメディアのインターフェースを模倣することではなく、ユーザーにとってより快適なもの提供することです。現在、そのために取り組んでいます。時期が来れば、発見したことや最終的な成果物、そしてリポジトリも喜んで共有します 
ちなみに、返信や交流の際に一部のユーザーが忘れがちな、常に覚えておくと良いものを共有します：Core Rules of Netiquette
「いいね！」 2
その通りですね。だから私も、スレ主や皆の新しい試みを強く支持しています！
「いいね！」 2
この件について考えてみたところ、もう少し複雑な問題だと感じています。確かにすべては議論を中心に据えられていますが、読み物としての側面も非常に重要です。読者やコンテンツの消費者という大規模なユーザー層が存在していることは認識しており、その体験をシームレスにするというアイデアには賛成です。私は以前から、簡単にカスタマイズできるフィードを推進してきました。
「いいね！」 5
「フィードをカスタマイズ」機能の初期デザインが完了しました
次は、DBに新しいテーブルを挿入します。例えば、以下のような構成です。
| フィールド | 目的 |
|---|---|
user_id |
メンバー |
category_id |
計測対象のカテゴリ |
impressions |
意味のある表示回数 |
opens |
開かれたトピック数 |
likes |
「いいね」されたトピック数 |
replies |
投稿された返信数 |
dwell_seconds |
累積閲読時間 |
affinity_score |
計算された好み（アフィニティ） |
updated_at |
最終再計算日時 |
第1版では、興味テーブルのみが必要です。行動テーブルは、どのアプローチを取るかが決まった後に追加します。
「いいね！」 2
今日、Nodelocフォーラムで関連するものを見かけました：NodeLoc
このアプローチには詳しくありませんが、どこまで発展していくのか見てみたいと思います！
「いいね！」 1
本当にすごいと思います。/r ルートのことはかなり考えましたが、カテゴリの制限があるため、その方向性は採用しませんでした。どのように実装されたのか気になります。
「いいね！」 1
初期のフィード選択機能が追加され、動作しています。上記と同様に、最終段階までスタイリングは未実装です。
ユーザーがフィードに初めてアクセスした際に選択画面が表示され、3つの興味カテゴリを選択するまで閉じることができません。「すべて選択」のオプションも追加されています。
また、「興味を編集」タブも追加されています。
「いいね！」 1
初期のパーソナライズフィードは完成し、正常に動作しています。CPUのスパイクはまだ見られず、高速で意図した通りに動作しています。
現在、以下のような動作を行います：
- 興味55%、新しさ25%、人気10%、ランダム性10% を用いてトピックにスコアを付けます。
- 可能な場合、6番目の位置に発見トピックを優先して配置します。
- 代替案がある場合、同じカテゴリのトピックが3つ連続して表示されるのを避けます。
- ページネーションを、削除済みまたは消費済みの項目から独立させます。
- 興味が変わった後、フィードを再読み込みし、並び順を再調整します。
- 動作するポップアップと すべて選択 を含みます。
そして、フィードを変更した後は：
「いいね！」 5
続ける前に、まずスタイルを整え終わろうと思いました。
「いいね！」 3
次にやることは、
行動追跡機能を追加する前に、これまで構築したものを最適化することです：
- ユーザーあたりのキャッシュされたフィードセッションを制限し、繰り返し更新しても6時間分のキャッシュされたリストが蓄積しないようにする。
- カテゴリのミックスを改善し、大きなキューにおけるCPU負荷を軽減する。
- フィードの読み込み時間とキャッシュ使用量を測定する。
その後は、行動追跡です：実際のインプレッション、トピックのオープン、閲覧時間を記録します。プリフェッチは閲覧としてカウントしないようにする必要があります。
当初は、順序を変更せずにこれらのシグナルを収集します。追跡が信頼できるレベルに達したら、ユーザーが30〜50件の投稿を見るにつれて、段階的に15%の行動重み付けを導入できます。
「いいね！」 1
この取り組み、いいですね！
「読み込みは根本的なものだ」とすら言えるでしょう。私がコミュニティマネージャーとして始めた頃、まさにそのタイトルだった基礎的なブログ記事です：
@Damian_Boon トピックに画像が添付されていない場合、このシステムはどう動作するのですか？
デモではAI生成のヘッダー画像が使われていますが、これがデフォルトになることはないと願っています。たまにある程度なら構いませんが、偽の画像が次々と並ぶと、かなり不快になりますよ
Safariデスクトップ版では、関連トピックのリンクが開かないというバグも少しあります：
「いいね！」 3
まったく同じです。使用するのはトピックのビューポートだけなので、現在見えているものと変わりなく、画像がない状態になります。
これはデモサイトであり、このテストケースのためにすべてのコンテンツがAIによって生成されています。
ご指摘ありがとうございます。これはホームページからのキャッシュを使用しているため、後で調査します。
「いいね！」 2
これまでに作成した内容について、サーバー負荷のテストを行う必要があります。OpenRouterのアカウントを持っており、10体のボットが同時に投稿する状況をテストしたいと考えています。例えば、次のようなボットを設定した場合、テストに最適なアプローチは何でしょうか。
ボット設定例：
-
ユーザー名: wtf_gaming
カテゴリ: ゲーム
個性: ゲームニュース
1時間あたりの投稿数: 30
1時間あたりの返信数: 15 -
ユーザー名: wtf_tech
カテゴリ: テクノロジー
個性: テクノロジーニュース
1時間あたりの投稿数: 30
1時間あたりの返信数: 15
さらに、ログイン済みの10体のボットが、例えば30秒ごとに /feed ページを更新する、といったシナリオです。
あるいは、DiscourseのRailsプロセス内にAIリクエストを直接組み込むのではなく、DiscourseとOpenRouterとを連携させる小さなスタンドアロンのPythonサービスを作成するという方法もあります。
テストを行う最善の方法は何でしょうか。
「いいね！」 1
とても素晴らしいですね。最終的に新しいテーマとして実現できるでしょうか？
「いいね！」 2
カテゴリセレクターのフィードを持つテーマコンポーネントがあれば最高ですね！
「いいね！」 1