UIの破壊的な変更に対し、移行期間を設ける

[zawa-ch]

1679a40#diff-5b0a139a59f26487da327db64360e065d0da27ace4d076abf04731ce66218d9dR1207-R1212 で投稿プレビューに斜線がついたとき、 #14703, #14734 のようにそれに関連したIssueが建てられたように、(少なくともエンドユーザーから見える)インターフェースに対して大きな/破壊的な変更が加わると

• それが仕様であることを認識するまでに時間がかかる
• 変更が受容されるまでにはさらに時間がかかる

ため、新しいインターフェースに移行するまでの期間を十分に取るような実装を行うよう、提案を行います。

おそらく、この提案によってすべきことの要約は次のとおりです:

• インターフェースの変更に移行期間を設ける
  少なくとも1〜2ヶ月程度は新しいインターフェースと以前のインターフェースを設定によって変更できるようにする。
• 新しいインターフェースが利用可能であることをわかりやすくする
  Github の Feature Preview のように、新インターフェースのプレリリースの設定を専用の場所にまとめ、 Misskey 更新後そのページを見るまでバッジを表示するなどの方法で利用可能であることをエンドユーザーにわかりやすくする。
  新インターフェースを更新時点で適用し、設定から差し戻し可能にする実装も考えられます。
• エンドユーザーの反応に基づき、確定、取消、選択可能のいずれにするかを決定する
  なお、ここでそれぞれの単語は次の意味を持ちます。
  • 確定 - 新しいインターフェースを公式に取り入れ、以前のインターフェースを置き換える。
  • 取消 - 新しいインターフェースを取り下げ、以前のインターフェースを継続する。
  • 選択可能 - 新しいインターフェースを取り入れるが、その使用はエンドユーザーに委ねるようにする。

[tai-cha]

理想論としては全くもって正しいと思えますが、実現と保守のコストを考えるとすぐに実現できるかは不明です
（ドキュメンテーションにもコストは掛かるしフィーチャースイッチの実装、それを知らせるUIをUI変更のたびに行うのはコストがかなり肥大化するため）

[syuilo]

何が破壊的で何が破壊的でないかの基準が難しそうですね