チャンネル間で28件のメッセージを移動しましたが、すべて順序が狂っています。
うーん。私だけですか、それともこれらは順序が狂っているように見えますか?
順序が狂っている投稿をもう一度確認しました。\u003chttps://meta.discourse.org/chat/channel/147/chat?messageId=2644\u003e、それらはすべて同じタイムスタンプを持っているようです。
「いいね!」 6
martin
(Martin Brennan)
4
この報告ありがとうございます。機能に盛り込もうとしたのですが、テストがうまくいきすぎたようです
確かに、ここでタイムスタンプはすべて同じものに設定しています。
問題は、移動したメッセージを既存のチャットメッセージの間に割り込ませたくないということで、メッセージを移動すればするほど難しくなります。
これに深く入り込む前に質問ですが、どのメッセージが本来の位置にないか覚えていて特定できますか?数件だけですか、それとも完全に順序が狂っていますか?おそらく不一致の原因となったのは、チャネルのメッセージを取得する際に、ID順(ほとんどの場合DESCで並べ替え、その後逆順にします)で取得していることだと思います。
一方、メッセージムーバーでは順序を維持するために created_at で並べ替えているため、小さな不一致が生じる可能性があります。
これを解決する方法についていくつかアイデアがあります(メッセージムーバーをIDで並べ替えるように変更するか、コントローラーを created_at で並べ替えるように変更すれば十分かもしれません。後者の方が理にかなっていると思うので、そちらを優先します)。しかし、もし判別可能であれば、順序がどれほど乱れているか教えていただきたいです。
「いいね!」 5
新しいチャネルでメッセージがごちゃ混ぜになっていることに気づいた後、元のチャネルから削除を取り消しました。ここでは順序通りに引用できるはずです:
元の順序
新しいチャットフローの本質を捉え、チャットがより大きな議論の種となり得ることを示す方法を探しています。
Meta でのチャットテストの現状から、それを達成する方法についてアイデアはありますか?
フィードバックポイントは素晴らしいですし、すぐにそれらは各自の適切なトピックとして切り離されると思いますが、@chat-testers に新しく参加する人々にとって、素晴らしい手本となるものを期待していました。人々がそれを見て「ああ、なるほど。最初は確信が持てなかったけど、チャットが深い議論の先駆けになり得るんだ」と気づくようなものです。
もしかしたら無理なお願いかもしれませんね 
正直なところ、チャットが深い議論の先駆けになり得るとは思えません 
でも、それは私が年老いているからかもしれません
つまり、@RGJ の考えを変えるような例を探しているのですね 
こちらの例が好きです。ただし、その例はここでは合いません。もしかすると、トピックは「今不足している機能」についてのものであるべきかもしれません。例えば、似たような機能リクエストがあるかどうか確認する時間がない、あるいは他の誰も興味を持たないだろうと思うため、トピックを開始しないようなものです。
@Moin、あなたの検索スキルはいつも感謝しています 
種や木についての例を探していたのですが、ここでは見つかりませんでした
でも、そうですね。アイデアが簡単なやり取りを通じて形成され、その後、正式な議論トピックへと発展するような、リラックスした/友好的で/カジュアルなチャットのようなものが必要です
これは 100% 私の関心とユースケースです。ただし、この「例」という言葉の意味を具体的に明確にできますか。Discourse チャットかどうかに関わらず、より深い議論につながったはずの(もちろん)チャットのサンプル、あるいはより理想的でない媒体(チャット対フォーラム)で実際に深い議論につながったもののサンプルに興味がありますか?もしそうなら、いくつか探すのに少し時間がかかるかもしれませんが、私の生産性コミュニティからは良い例が確実にあります。もし特に Discourse チャット内の例をお探しの場合は、探すのは難しくなるでしょう。しかし、私はこれが Discourse におけるチャットの大きな価値の一つだと確信しており、コミュニティによっては、その役割はより大きくなったり小さくなったりします。
新しい機能に関する議論を紹介することは、少なくともそのアイデアの最初の段階でそれをデモする良い方法だと思います。一部の人の場合、この議論の火花は開発中または開始直前に生まれます。常に議論すべきことは多くあり、トピック(または複数のトピック)を参照することは理にかなっています。
チャットが(そしてすべきである)議論の途中でさえ、すぐにトピックへと変わる状況の、より概念的な例を挙げると、私が参加しているソフトウェア開発管理コミュニティや私の生産性コミュニティでは、これがよく起こります:
- 新しい人がチャットに参加し、一見単純で無害な質問をする
- 非常に情報に詳しい、または情熱的な常連からの回答がすぐに数十行のテキストに成長し、段落区切りが始まり、そのチャットチャンネルはたった一つの質問(トピック)に関する議論だけで埋め尽くされる
- 各「メッセージ」に多くのポイントやアイデアが含まれており、選択して引用/返信する機能がないため、各内容の解析と返信が困難になる
- これらの会話は、チャットのその後の流れですぐに消えてしまう貴重な議論であることも多く、後からトピックに移動させることさえ非常に価値がある可能性がある
最初は、Discourse チャットに不慣れな人々に、それが既存の「長文段落」的な Discourse のイメージとどのように調和するかを示すために、Meta で提供できる例となるトピックやチャットを探していました
つまり、原則をきれいに示すために私たちが作成したものでも構いません
でも、あなたが素晴らしい議論トピックになるような例をたくさん持っているようですね 
フォーラム構造のどこにチャットを位置づけるかを人々が簡単に視覚化できるものは何でも役立つと思います。あらゆるアイデアにオープンです 
この会話自体が、まさにそのような例になっていると感じます。
他のプラットフォームではスレッドになるようなものは、別のチャットになるか、分割されたトピックになる必要があるように思えます。しかし同時に、トピックはここでのように一時的なものではなく、より長期的な議論のようなものにも感じられますか?
一つの方法は、アイデアを開始した初期のチャットメッセージをトピックに引用することかもしれません:How can chat seed topic discussions?
これは、チャットに参加していない人々、特にトピックが質問で始まる場合に可視性を高めることができます
しかし皮肉なことに、私はここで回答しています lol
ふむ、ちょうど自分の返信を同じトピックに引用しようと試みましたが、既存のトピックではなく、新しいトピックに引用するオプションしかないようです
ちょうどそのことを考えていました。
適切なチャットチャンネルがなかったので、各人のチャットを返信として含めるトピックを作成できるかどうか検討していました。でも、あなたがそれをしてくれたおかげで、これには独自のチャットチャンネルがあり、この会話をそこに移動できることがわかりました 
ああ、まさに新しいチャットチャンネルを作成するトピックを作成するようなものです
そして、そのトピックにはチャットからの引用、特にハイライト部分で埋め尽くすことができます
ごちゃ混ぜの状態
これは 100% 私の関心とユースケースです。ただし、この「例」という言葉の意味を具体的に明確にできますか。Discourse チャットかどうかに関わらず、より深い議論につながったはずの(もちろん)チャットのサンプル、あるいはより理想的でない媒体(チャット対フォーラム)で実際に深い議論につながったもののサンプルに興味がありますか?もしそうなら、いくつか探すのに少し時間がかかるかもしれませんが、私の生産性コミュニティからは良い例が確実にあります。もし特に Discourse チャット内の例をお探しの場合は、探すのは難しくなるでしょう。しかし、私はこれが Discourse におけるチャットの大きな価値の一つだと確信しており、コミュニティによっては、その役割はより大きくなったり小さくなったりします。
新しい機能に関する議論を紹介することは、少なくともそのアイデアの最初の段階でそれをデモする良い方法だと思います。一部の人の場合、この議論の火花は開発中または開始直前に生まれます。常に議論すべきことは多くあり、トピック(または複数のトピック)を参照することは理にかなっています。
チャットが(そしてすべきである)議論の途中でさえ、すぐにトピックへと変わる状況の、より概念的な例を挙げると、私が参加しているソフトウェア開発管理コミュニティや私の生産性コミュニティでは、これがよく起こります:
- 新しい人がチャットに参加し、一見単純で無害な質問をする
- 非常に情報に詳しい、または情熱的な常連からの回答がすぐに数十行のテキストに成長し、段落区切りが始まり、そのチャットチャンネルはたった一つの質問(トピック)に関する議論だけで埋め尽くされる
- 各「メッセージ」に多くのポイントやアイデアが含まれており、選択して引用/返信する機能がないため、各内容の解析と返信が困難になる
- これらの会話は、チャットのその後の流れですぐに消えてしまう貴重な議論であることも多く、後からトピックに移動させることさえ非常に価値がある可能性がある
最初は、Discourse チャットに不慣れな人々に、それが既存の「長文段落」的な Discourse のイメージとどのように調和するかを示すために、Meta で提供できる例となるトピックやチャットを探していました
つまり、原則をきれいに示すために私たちが作成したものでも構いません
フォーラム構造のどこにチャットを位置づけるかを人々が簡単に視覚化できるものは何でも役立つと思います。あらゆるアイデアにオープンです 
新しいチャットフローの本質を捉え、チャットがより大きな議論の種となり得ることを示す方法を探しています
でも、あなたが素晴らしい議論トピックになるような例をたくさん持っているようですね 
Meta でのチャットテストの現状から、それを達成する方法についてアイデアはありますか?
正直なところ、チャットが深い議論の先駆けになり得るとは思えません 
この会話自体が、まさにそのような例になっていると感じます。
他のプラットフォームではスレッドになるようなものは、別のチャットになるか、分割されたトピックになる必要があるように思えます。しかし同時に、トピックはここでのように一時的なものではなく、より長期的な議論のようなものにも感じられますか?
フィードバックポイントは素晴らしいですし、すぐにそれらは各自の適切なトピックとして切り離されると思いますが、@chat-testers に新しく参加する人々にとって、素晴らしい手本となるものを期待していました。人々がそれを見て「ああ、なるほど。最初は確信が持てなかったけど、チャットが深い議論の先駆けになり得るんだ」と気づくようなものです
少なくとも、そう思います。
何かをする前に自分の考えを再確認します
もしかしたら無理なお願いかもしれませんね 
しかし皮肉なことに、私はここで回答しています lol
ちょうどそのことを考えていました。
適切なチャットチャンネルがなかったので、各人のチャットを返信として含めるトピックを作成できるかどうか検討していました。でも、あなたがそれをしてくれたおかげで、これには独自のチャットチャンネルがあり、この会話をそこに移動できることがわかりました 
ああ、まさに新しいチャットチャンネルを作成するトピックを作成するようなものです
つまり、@RGJ の考えを変えるような例を探しているのですね 
そして、そのトピックにはチャットからの引用、特にハイライト部分で埋め尽くすことができます
こちらの例が好きです。ただし、その例はここでは合いません。もしかすると、トピックは「今不足している機能」についてのものであるべきかもしれません。例えば、似たような機能リクエストがあるかどうか確認する時間がない、あるいは他の誰も興味を持たないだろうと思うため、トピックを開始しないようなものです。
@Moin、あなたの検索スキルはいつも感謝しています 
種や木についての例を探していたのですが、ここでは見つかりませんでした
でも、そうですね。アイデアが簡単なやり取りを通じて形成され、その後、正式な議論トピックへと発展するような、リラックスした/友好的で/カジュアルなチャットのようなものが必要です
「いいね!」 2
mcwumbly
(Dave McClure)
6
メッセージを引用するよりも移動する方が良いのはいつか、疑問に思っています。既存のトピックがあるかどうかに依存するのでしょうか?よくわかりません。次のいずれかの場合、人々をどちらかに誘導するのが良いでしょうか?
- 既存のトピックにチャットメッセージを引用する
- 既存のトピックにチャットメッセージを移動する
- 新しいトピックにチャットメッセージを引用する
- 新しいトピックにチャットメッセージを移動する
チャットメッセージの文字列は、トピックよりも「チャット」的であるため、一般的には移動よりも引用を奨励したいという気持ちがあります。
「いや、ここでは引用は良くない。代わりに移動する必要がある」というような、皆さんが観察した、または考えているケースはありますか?
「いいね!」 2
Moin
7
議論を引用するだけだと、2箇所で議論が続けられてしまいます。
mcwumbly
(Dave McClure)
8
@Moin は、本当に避けたい場合にメッセージを移動することを提案していますか?
martin
(Martin Brennan)
9
それが完了したこと、ありがとうございます。完全にめちゃくちゃになっています!メッセージの大きなセットでローカルテストを行う必要があります。少なくともこれは必要になると思います。
しかし、IDによる並べ替えは、奇妙な一貫性の問題があるため、一般的に気が進みません。メッセージを created_at で並べ替える方が、一般的にチャンネルにとって良いと思います。@j.jaffeux または @mcwumbly、これについてどう思いますか?もしそうすることに決めた場合、メッセージムーバーは一貫した並べ替えのために created_at の値を10ミリ秒ずつ人工的に間隔を空ける必要があるかもしれません。
一般的に、現在のチャンネルに全く関係がない場合は、より適切なチャンネルに移動する方が良いと思います。以前、Mattermostを使用していたときには、内部でこれを何度も使用しました。例えば、general チャンネルでのインシデント対応の多くは、記録保持のために incident チャンネルに移動されるべきです。または、チャンネルでの無駄話は、random チャンネルに置く方が良いでしょう。
引用して古いゴミを残しておくことには、これらのケースでは価値がないと思います。そして、Moin が言うように、議論が2つの異なる場所で続けられると、混乱を招く可能性があります。
これらの2つのオプションは現在存在しないことに注意してください。最初の実装では、チャットメッセージごとに1つの投稿が作成され、元のメッセージがチャンネルから削除されなかったため、「トピックに移動」を削除しました。将来的にこれを再度行う場合は、次の必要があります。
- a) チャット引用機能を使用して、メッセージのバッチ(たとえば100件ごと)を一緒に引用し、
- b) 重複を避けるために、元のメッセージをチャンネルから削除する。
「いいね!」 5
mcwumbly
(Dave McClure)
10
投稿の順序付けの実装については、@j.jaffeux さんにコメントを譲ることにします。
ああ、そうですね。チャットメッセージをチャット内で移動することについて尋ねていたわけではありませんが、それは便利だろうと思いますし、「投稿内」で短形式と長形式を変換しようとする問題はありません。
なるほど。引用の一般的な形式は、このような「トランスクリプト」のようなものの方が、いずれにしてもそのように読まれる可能性が高いと思います。以前、Slackのトランスクリプト機能を使っていたとき、メインの投稿本文で要約しつつ、[details]で囲むことがよくありました。
それに関連して、より洗練された「コンテキストを展開」機能があれば、単一のメッセージを引用し、オンデマンドで追加のメッセージをインラインで読み込み、トピックを離れることなくチャットのコンテキストをさらに表示できるかもしれません。
スローレーンとファストレーンの境界を越えて議論を参照する場合、これが不可欠または価値があるかどうかについては懐疑的です。
「いいね!」 4
martin
(Martin Brennan)
11
これはトピックへの移動を選択した場合にのみ発生します。移動するつもりだったのに、なぜチャンネルに残しておくのですか?すでに内部でこの件についていくつかの議論がありました。もちろん、メッセージを通常の引用としてトピックに含めるだけでは何も削除されません。
トリビアですが、引用を生成するクラスは実際には ChatTranscriptService と呼ばれています 
これは興味深いですね。実際、私たちのトピック引用にはこれに似たものがあります(おそらく既にご覧になったことがあるでしょう)。チャンネルに実際に行かなくても、もう少しコンテキストを取得できると便利でしょう。
「いいね!」 3
sam
(Sam Saffron)
13
移動のユースケースは次のとおりです。
- 「Whales」に関する議論専用のチャンネルがあります。
- 大勢の人々が、「#penguin」をクリックするのを忘れてしまい、物事が白熱したため、「Penguins」について活発な議論を始めます。
- モデレーターが介入し、「
」でペンギンの話題をペンギンチャンネルに移動させます。
根本的なことは再シーケンスだと思います。
すべてを1つのブロックに移動したいので、「fudge created_at」が唯一の合理的な解決策だと思いますか?また、技術的には移動された時点に作成されます。
「いいね!」 5
mcwumbly
(Dave McClure)
14
ええ、それが必要なのか、それとも引用/文字起こしを非常にうまく機能させることに集中すべきなのか疑問に思っています。
「いいね!」 3
martin
(Martin Brennan)
15
はい、通常のGETメッセージルートがcreated_atで並べ替えられていれば、絶対にそうします。それを解決したいのですが、Joffreyにそのことに関する歴史的な知識があるかどうか疑問に思っていただけです。もしなければ、両方のことを一度に変更します。
「いいね!」 2
j.jaffeux
(Joffrey Jaffeux)
16
はい、サムさんとあなたには100%賛成です😁 一度にすべてを移動し、移動時のcreated_atを付与するのが、私の意見では唯一の合理的なアプローチです。そうでなければ、巨大な問題の缶が開いてしまいます…どこで見つけられるかわかりません?最後に読んだものより前に作成されたものに対する未読通知を受け取る?いやいやいや
「いいね!」 4
martin
(Martin Brennan)
17
「いいね!」 3
martin
(Martin Brennan)
21
これをマージして問題に対処できればと思います。
今のところ、created_at を意図的に未来の日付にずらすようなことはしていません。まずはこれで様子を見ましょう。
「いいね!」 4
martin
(Martin Brennan)
クローズされました:
22
このトピックは11日後に自動的に閉じられました。返信はもうできません。