sasanquaneuf
Hello! I applied tokei to my web application, and obtained the following outputs [one] and [two]: [one] (branch a) ``` =============================================================================== Language Files Lines Code Comments Blanks =============================================================================== Batch 4...
目指す方向性は #55で良いと思いますが、右側のプレビューの内容が書き換わっていないので、プレビューとURLで不整合を起こします。 それがここで挙げている事でした。 あるべき姿は、URLの内容に従って過去プレビューを書き直すか、途中でのインスタンスの変更を禁止するか、ではないかなと思います。
ちなみに、なぜこれを気にし始めたかというと、@useridを含むURLを認めるからでした。 /web/statusの、webログイン後の画面からまとめをつくる場合はほとんど問題ないのですが、@useridのページをまとめづくりに利用する場合、例えばqiitadonから見られるトゥートであっても、インスタンスが別になるため、右側に登録をする前にプレビュー表示した時に違うトゥートになります。 ここまでは、まだ仕様としてもよいのかなと思ったのですが、右側に登録してからインスタンスを変更すると、画面上の見た目は変わらないのにURLでは対象トゥートが変わってしまうので、それはさすがにバグかなと思ったのでした。
べき論としては、contentを隠して、CWを表示して、ボタンを押したらcontentが出る、みたいな形式にするのが正しいような気はしました。（規約とか取り決めを把握しているわけではありません） NSFWみたいなものをどう表示すべきかの議論は、既にけっこうありそうですね。
このような話題も本家にあるみたいなので、消えてしまうというのは一般的な事例ではあるみたいですね。 https://discourse.joinmastodon.org/t/reworking-cw-nsfw-image-systems-for-better-userflow-and-design/200/22 > The primary reason I would object to that - in fact, currently, one of only two reasons I would object to that - is that the CW...
追加ボタンを押したら、プレビューの内容≒入力ボックスの内容をクリアしてほしいですね。（同じトゥートをたくさん貼りたい人がいなければ）
#88 と、入力ボックスの一本化を行った場合、まとめURLを入れた場合はただちにプレビューに追加される感じですかね？どうなんだろう
Qithub-BOTのブランチは自動削除されるけど、ほかのひとのリポジトリのブランチは削除されないということでは ※ちなみに、わたしは昔Qithub-BOTに新しいブランチをpushしたらrejectされました
@yumetodo はい、そうだろうなとは思っています。（だから自動削除される運用にしても現状のフローだとあんまり効果ないかもしれないですね、というのが言いたいことでした）
「レビューでどれぐらいOKだったらマージするか」を今後決める必要はありそうですね。 多数決が正しいかと言うと、必ずしも正しくないような気はします。 ただ早くマージされないと、開発速度が遅くなったりコンフリクトが発生したりという事はあるので、早くマージしやすいようなレビューフローを決めるのですかね。