問題の再現方法
- 既存のコミュニティを壊さないように、テストインスタンスを取得します。
- 「1日の最大個人メッセージ数」を1に設定します。（デフォルトは20です。この設定で0が何を意味するのか不明なため、次に近い値を使用します。）
- スタッフではないユーザーになりきります。（管理者としては問題が見えませんでした。スタッフはこのレート制限の対象ではないと推測していますが、コードを確認したわけではありません。）
- なりきったアカウントから、他の誰かにテスト用の個人メッセージを送信します。（私は自分自身のアカウントに送信しました。）
- ランダムな投稿を「その他」の理由でフラグ付けします。（他のフラグ理由では問題が発生しないようです。）
ポップアップが表示されるはずです。
エラーが発生しました：1日の最大メッセージ数に達しました。23時間後に新しいメッセージを作成できます。
なぜ重要か
関連する設定はいくつかあります。
- 1日のPMスレッド数。（デフォルト20）
- 1日のフラグ数。（デフォルト20）
- 1日のフラグ数は信頼レベルによって乗算されます。（TL2 => 1.5、TL3 => 2、TL4 => 3）
その結果、TL3ユーザーは24時間で最大20のPMスレッドを開始し、最大40の投稿にフラグを付けることができます。しかし、「その他」の理由を使用するフラグは、PMスレッド制限とフラグ制限の両方にカウントされます。PM制限にはTL乗数がないため、信頼されたユーザーのためにレート制限を増やすことは不可能です。
おそらくより重要なのは、メッセージがユーザーの実際のアクションと関連がないように見えることです。特定のフラグ理由がPMスレッドを開始するとは限りません。この混乱を実際に確認するには、これらのスレッドを参照してください。
本日調査した結果、1日にPMスレッドを使い果たした場合、「その他」の理由を使用しないことをお勧めできます。しかし、これは一部のユーザーが必要なコンテキストをフラグに追加することを思いとどまらせる可能性があるため、理想的ではありません。おそらくPMスレッドのレート制限を増やすだけで、誰かが他のユーザーにスパムを送信できることを発見しないことを願っています。
考えられる解決策
- システムによって生成されたPMスレッドをユーザーのカウントから除外します。 つまり、投稿にフラグを付け、システムがそれをモデレーターとのPMスレッドに親切に変換した場合、それは私の制限にはカウントされないはずです。フラグについては、フラグのレート制限のみが適用されるべきです。
- メッセージを修正して、ユーザーが問題を自己診断できるようにします。 簡潔なコピーを提案することはできませんが、問題が他の種類のフラグではなく、「その他」でのフラグ付けであることを明確にする必要があります。PMスレッドに関連しているという兆候は、注意深く説明されていない限り、省略します。平均的な人にとっては、システムの内部に入り込みすぎます。
- PMスレッドのレート制限にTLベースの乗数を追加します。 正直なところ、20はほとんどの極端な状況を除いて十分だと思います。しかし、フラグが制限を圧迫する場合、信頼されたユーザーに少なくとも通常のユーザーと同じ数のPMスレッド開始を許可したいと思います。