最後に投稿を編集した後のスレッドの再浮上

特徴
1

最近のDiscourseの変更により、スレッドの最後の（または最初の）投稿を編集した際の「bump（スレッドを最新にする機能）」が削除されました。

これは私たちが頼りにしていた機能であり、スタッフランク以外のメンバーがこれを模倣するための実用的な方法がありません。

この機能の恩恵を最も受けていたのは、告知スタイルの投稿や、意図的に返信が少ない、または全くない投稿をbump（スレッドを最新にする）するためでした。

これらはトピックに対する実際の更新であり、編集によって古い情報が削除されていました。投稿が最新フィードの先頭に戻ることは非常に望ましく、すべてのメンバーに何らかの変更があったことを知らせることができました。

はい、これはある程度、一連の返信によって模倣できますが、時間の経過とともに、ユーザーが何を伝えようとしていたのかを把握するのが煩雑になります（例えば、10件の変更を含む返信を想像してみてください）。元の投稿または最新の投稿を編集し、トピックが最新フィードの上位に表示される方がはるかにすっきりしていました。

この件に関して賛否両論あることは理解していますが、これは長年にわたるDiscourseの長年の先例であり、以前の機能をDiscourseに復元するオプションを追加することは、誰もが満足させるでしょう。おそらく、投稿に対するどのようなアクティビティが最新フィードに表示されるかを細かく制御するために、将来的にはオプション機能が拡張される可能性があります。

この変更について議論されたバグスレッドへのリンクは以下にあります。

「いいね！」 1
2

必要な信頼レベルに達していないため、これに投票することはできませんが、もし可能であれば、この変更に賛成する意向を表明したいです。

「いいね！」 1
3

私が以前にも述べたように、意味のある編集があった場合にトピックを上げること（bump）も惜しいです。

私はフォーラムのメンテナンスに関する通知を https://status.discourse.org/ のRSSフィードから受け取るために rss-polling を使用しています。メンテナンスが始まるとトピックが作成され、終了が告知される編集があった際にトピックが上げられていました。この上げ（bump）が現在欠落しており、誰も編集すべきではないためトピックをWikiにしたくありませんし、ドキュメントにもしたくありません。そのため、現在の回避策は役に立ちません。

あるフォーラムでは、ユーザーがプロジェクトを発表する個別のトピックの他に、ユーザーのプロジェクトを紹介するギャラリートピックがあります。このトピックはインスピレーションを集めるのに非常に役立ちます。発表トピックから画像を1枚選び、そのリンクと共にギャラリートピックに追加しています。投稿内の画像が多すぎるとパフォーマンスの問題を引き起こし、編集も困難になるため、10プロジェクトごとに新しい投稿を作成しています。2番目または9番目のプロジェクトが追加された際の編集による上げ（bump）は役立っていました。これはユーザーが更新に気づくのに役立ち、特に手動でプロジェクトを追加するユーザーにとっては非常に役立ちました。アクティビティの日付のおかげで、誰かがすでにプロジェクトを追加していないかすぐに確認できました。今では、それぞれがトピックを開いて確認する必要があります。

同様の機能を持つ他のトピックもあります。月ごとの変更/アクティビティの概観として機能するトピックで、現在の月に関する最新の投稿が数回更新されます。これは、最後の投稿への変更がトピックを上げたため、非常にうまく機能していました。変更ごとに個別に投稿すると、月ごとにまとめられたエントリの明確さが損なわれ、既存のエントリへの更新が見過ごされやすくなる可能性があります。数件のエントリのために毎月新しいトピックを作成するのは多すぎますし、ユーザーが毎月通知設定をやり直す必要が生じるか、通知のデフォルトステータスを設定できるようにするサブカテゴリ全体が必要になります。

未回答のトピックに対するカテゴリやタグの変更によってトピックが上げられたことも気に入っていました。ほとんどの場合、最新トピックの（フィルタリングされた）リストを使用します。トピックのタイトルが不適切であったり、カテゴリが間違っていたりした場合、クリックしないかもしれません。誰かがその情報を改善した場合、結局は助けられるかもしれないと気づくことがあります。そのため、そのような変更によってトピックが私の既読ラインよりも上に移動することが役立っていました。

カテゴリやタグについて学ぶのにも役立ちました。新しいトピックで追加されたタグや、モデレーターによってトピックが移動されたことによるカテゴリ間の詳細な違いから、新しいタグについて知ることがよくありました。なぜ移動されたのか尋ねることもありました。なぜなら、トピックを他のカテゴリに移動する能力には、それらの違いを理解する責任も伴うと考えているからです。

また、Discourseの設定が、別の投稿を書くのではなく、情報を提供するように強制するアプローチも気に入っています。
ポップアップメッセージを引用すると：

しかし、これは、他の人があなたの投稿を編集して追加情報を提供したことに気づいて初めて意味があります。Metaで何度か遭遇した例ですが、プルリクエストがマージされた後に投稿が更新される場合です。その情報を投稿に追加しても、すでに投稿を読んだ人を通知することはなく、まだ読んでいない人はワンボックスのバッジから容易にわかります。
私にとって、ユーザーによる3回連続の返信をブロックする設定がまだ有効であり、その編集がかつて持っていた効果を残念ながら持たなくなったにもかかわらず、編集を解決策として提案するのは意味がありません。

「いいね！」 3
4

この機能については強い意見はありませんが、関連する問題として、投稿を自動で「bump（再浮上）」させた後、そのbumpした旨のメッセージを削除したいのですが、それができなくなりました。bumpメッセージを削除すると、投稿は以前の位置まで沈んでしまいます。もし、メッセージを編集することで「最終bump日時: 1日前」という表示を作成せずに投稿をbumpできるなら、それは便利でしょう。

（できれば、投稿をbumpし、bumpメッセージを削除しても、手動で「bump日時をリセット」しない限り、投稿はフロントページに残っていてほしいです。）

「いいね！」 1
5

興味深いアイデアですね。編集によって投稿がアクティビティフィードの上部に移動する機能を復元するものは何でもありがたいです。

@lindsey この機能の一部を復元するために何かできることはありますか、それとももう遅すぎてこれが新しい標準となってしまったのでしょうか？

6

変更を元に戻したり、すべての編集でバンプを復元したりする現在の計画はないことをお詫び申し上げます。お望みの答えではないことは理解していますが、このトピックを監視し続け、将来的に皆様のユースケースをより良くサポートする方法を検討してまいります。

7

何かがもはや起こらないという事実も同様です。Discourseの動作が変更されたことに気づいた管理者が何人いるかについてのデータはありますか？bumpを防ぐ方法についての繰り返しのリクエストがあったというあなたの議論は理解できます。管理者が望まないbumpに気づくことは明らかです。しかし、トピックがbumpされない場合、たとえそれがbumpされることを望んでいたとしても、bumpされていないことにさえ気づきません。したがって、人々がそれを求める可能性は低いように思われます。

例えば、この投稿の編集で、「試してみます」がフォローアップの質問に変更されたことに気づきたかったでしょう。Localization of posts on topics with more than 20 posts - #7 by nat のような他の投稿での編集を見るのも同様に良かったでしょう。

また、最近、トピックがbumpされるとスパムがより簡単に見つかるという事実が再び話題になりました。編集中に投稿がbumpされるべきという、現在ではかなり限定的なケースで、なぜこれが関連するのか疑問に思います。しかし、ほとんどの投稿のデフォルトを変更したときには問題になりませんでした。なぜ、wikiである最初の投稿が、wikiであるトピックの最後の投稿よりも多くのスパム保護を必要とするのでしょうか？

以前にも何度も述べたように、利点は理解していますが、欠点に対する解決策を見つけることへの関心はあまりないようです。1年後などに現在のワークフローの代替手段があっても意味がありません。最後の投稿の編集によってトピックが一番上に移動する、サポートされているDiscourseのバージョンにはあまり時間が残されていないため、今すぐ新しい解決策を見つける必要があります。

8

これはスパムを表面化させることを目的としたものでは全くありません。

wiki投稿やドキュメント投稿は、それらの投稿への編集が一般的に関心事であるという理論に基づいて、トピックのトップに再浮上（bump）されます。

スパム対策については、これらの再浮上は実際にはあまり多くの露出を提供していなかったという理論があります。ほとんどの投稿は最後の投稿ではなく、それらへの編集はどちらにしても再浮上によって表面化していませんでした。したがって、編集によるスパムが問題である場合、それはどのような場合でも別の解決策を必要とします。これはその問題に対する効果的な解決策では決してありませんでした。

9

誤解があると思います。私の言いたいのは、最初の投稿にあるWiki投稿がなぜ再浮上されるかということではありませんでした。GitHubのコメントで言及されていた、no-bump APIパラメーターを制限する背後にある理由について話していました。

これはスタッフAPIキーに限定すべきでしょうか？一般ユーザーが再浮上を回避できるようにすることは望ましくないと思います（これにより、トピックにスパムを注入し、人々の注意を引かずに済むようになる可能性があるため）。

もしスパムが真の懸念事項であるならば、この制限は一貫して適用されるべきであり、再浮上がまだ行われているごく少数のケースに限るべきではありません。私が驚いたのはまさにこの点です。ここではスパムが問題として引用されていますが、例えばトピックの最後の投稿であるWikiなどでは、再浮上はスパム対策のメカニズムとして意図されていません。

Wiki投稿が更新時に再浮上されることには感謝しています（ただし、再浮上の理由が最初の投稿であるにもかかわらず、トピックの最後に移動させられるというUXは依然として混乱を招きます）。
私の言いたいのは、スパムに関するこの明白な一貫性のなさを指摘しているだけです。

「いいね！」 2
10

最後の投稿の編集について知りたかったが、トピックが更新されなかったため見逃した別のケースです：Restrict uploads - #30 by Arkshine

「いいね！」 1