Discourseへのカスタム機能移行（執筆批評）

コミュニティ
1

Discourse の機能をどの程度カスタマイズできるか、またその作業規模がどれほどになるかについての質問です。

私は専門的な SF 作家の組織の技術チームに所属しており、現在は退任した創業者が書いたフォーラムソフトウェアを中心に運営しています。このシステムは、老朽化した ASP.NET Core, an open-source web development framework | .NET Server 環境で動作しており、別のプラットフォームへの移行を強く希望しています。

ソフトウェアで最も人気のある機能の一つが「物語の批評機能」です。ユーザーはタイトルと単語数とともにドキュメントをアップロードできます。現在フィードバックを求めているすべての物語を表示する専用ページがあります。また、ソフトウェアには少しのゲーミフィケーション機能が組み込まれています。物語をアップロードすると自動的にディスカススレッドが作成され、750 文字を超える返信を投稿したユーザーにはポイントが付与されます。ユーザーが十分な数の返信を受け取ると、他のユーザーによるファイルのダウンロードを制限できるようになります。

物語のダウンロードページでは、各ユーザー名の横に、そのユーザーが獲得した批評ポイント数と、そのユーザーの物語が受け取った批評ポイント数が表示されます。これらは概ね同数になるようにするべきとされていますが、すべて名誉の原則に委ねられており、批評を受け取るだけで提供していないユーザーに対して警告が出た例は私の知る限りありません。この仕組みは非常にうまく機能しています（ただし、前述の通り老朽化した技術環境が課題です）。

長年のユーザーの中には、非常に多くのクレジットを蓄積している人もおり、これらのスコアを新しいプラットフォームに移行して、全員のハイスコアを消去せずに引き継ぎたいと考えています。

私の質問は、このような機能を Discourse フォーラムに組み込むのがどれほど簡単かということです。これは独自プラグインの範囲内で実現可能でしょうか、それとも Discourse と API を介して連携する別々のアプリケーションが必要になるでしょうか。ご助言いただければ幸いです。

「いいね！」 4
2

プラグインで実装可能でしょう。ポイントはトピック、投稿、またはユーザーにカスタムフィールドとして保持できます。

機能の明確化のためのいくつかの質問です：

これらのポイントはレスポンスの長さのみに基づくのでしょうか？

「十分な数」はどのように決定されるのでしょうか？

「ファイル」とはストーリーのことだと推測しますが、明示的なアクションが必要でしょうか？つまり、「十分な数のレスポンス」によってアンロックされる「他の人のファイルダウンロードを阻止する」というボタンがあるのでしょうか？

ストーリーが受け取る数（ポイント数？）はどのように決定されるのでしょうか？

「いいね！」 5
3

返信ありがとうございます！

750 文字を超える返信にはポイントが付与されます（「これは批評ポストではありません」という文言を含めることで、批評スレッド内に批評ではない投稿を作成することは可能ですが、そのような使い方をしたことは一度も見たことがありません）。もし著者が自身の批評スレッド内で 750 文字を超える投稿を行った場合、ポイントは一切発生しません。

物語の著者によって決定されます。著者は、自身の物語に対するフィードバックが十分だと判断した時点で、その決定を下すことができます。

はい、ファイルとは物語のことです（Word ドキュメント、RTF ファイル、または他の形式）。著者はいつでも、それ以上のダウンロードを無効にするボタンを押すことができます。共有について二の足を踏んだ場合、誰にもダウンロードされる前にそのボタンを押すことも可能です。

要約しようとするよりも、こちらに SQL 文を示します：

CASE WHEN WordCount < 1001 THEN 0.5 
 WHEN WordCount BETWEEN 5000 AND 9999 THEN 1.5 
 ELSE Round([WordCount] / 10000, 0) + 1 END

実際には、1 万語を超える物語をアップロードする人はほとんどいません。

「いいね！」 3
4

リチャードが言った通り、プラグインなら何でも可能です。ご提案の機能は、おそらく数時間の作業で実現できるでしょう。予算に合わせるためのショートカットもいくつかあります。カスタムバッジも役立つかもしれません。新しいプラグインを作成し、移行時にデータをインポートすることも十分に可能です。

古いシステムをそのまま複製することを、最良のシステムを構築することと混同しないでください。

解決済みのプラグインやタグを活用して、レビュー時間を無効化する方法もあります。

システム全体が独自開発の場合、カスタムインポーターの費用は通常1500ドル程度で、必要なプラグインの開発にも同程度の追加費用がかかる見込みです。

「いいね！」 6
5

ストーリーと批評のクレジットを区別するのをやめて、Discourseの「いいね」機能（ハートの共有）をクレジット共有に流用することもできます。これにより、移行や実装がかなりシンプルになります。ただし、クレジットを分離する利点を見落としているかもしれませんね。

「いいね！」 2
6

コミュニティに還元するという考え方は、他の人があなたの作品を読み、改善のためのフィードバックをくれるのであれば、あなたも他の人の作品を読み、彼らにフィードバックを与えるべきだというものです。それがDiscourseの組み込み機能で管理できれば素晴らしいのですが、どのように実現できるのか見当たりません。

「いいね！」 3
7

ユーザーが受け取る「いいね」について、より詳細なクエリを実行できます。例えば、ストーリー投稿に対する「いいね」と、フィードバック共有に対する「いいね」を区別するには、ストーリーカテゴリ内の初期投稿と後続の投稿に対する「いいね」をクエリすることで可能です。

その後、特定の数値に到達したユーザーに授与されるバッジ（ユーザータイトルやフラアと併せて）を設計できます。

「いいね！」 2
8

問題は、私の理解では「いいね」は投稿の人気を示す手段ですが、私が移行しようとしているシステムは、ユーザーが一定の努力基準を満たしているかを監視する仕組みだからです。したがって、ストーリーのスレッド内で、特定の文字数を超え、かつストーリーの著者ではない投稿に対して、自動的に一度だけ「いいね」がつくようにできれば、当社のシステムには合致するでしょう。しかし、それは「いいね」の仕組みとはあまりにも合わないようです。

「いいね！」 2