ベータ版トラックの取り扱いを再検討する

[keiji]

前提

現在、COCOAには2つのベータトラックと、1つのリリーストラックが存在する。

• ベータトラック
  • クローズドベータ
  • オープンベータ（準備中）
• リリーストラック

位置づけとして、次の通り。

クローズドベータ

連携チーム関係者およびコントリビューターの中でお声がけした人にのみ配布するもの。実験的な機能が含まれる代わりに動作は安定していない。位置づけ的にはアルファ版とか、Canaryのイメージ。

オープンベータ

希望者がベータプログラムに申し込む（またはベータ利用の操作を行う）ことで利用できるもの。実験的な機能が含まれる代わりにリリース版と比べて動作は安定していない。
一般的な「ベータ版」のイメージ。

リリース版

通常インストールできるバージョンで、動作は安定している。

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

初期の想定では、実験的な機能をクローズドベータに導入。安定度をある程度高めた状態でオープンベータへ「移行」し、ベータテスターのさまざまな環境で動作確認をしながら改善点を洗い出し、反映をした上で改めてリリース版に取り込むかを決めるという流れだった。
（つまり、クローズドベータからオープンベータの間はあくまで「移行」であり、ベータ版とリリース版の間に壁がある）

しかしながら今回（v2.0.0）では、クローズドベータの段階で「閾値未満の接触一覧」画面をオープンベータに入れない（継続検討）という決定があった（ #848 #847 ）。そのため、v2.0.0についてはクローズドベータからオープンベータへの「移行」ができず、結果としてfeature/beta feature/openbeta release/2.0の3つのブランチをそれぞれメンテナンスする必要が発生している。

そのため現状は、ある変更を入れようとするときに、3つのラインを維持する必要がある（ #885 #886 #887 ）。当然メンテナンスコストは上がって作業効率は落ち、ミスの危険性も増す。

さらに、オープンベータ版にはENv2移行という目玉はあるものの、クローズドベータにある「閾値未満の接触一覧」のような目に見えるものがない。さらにベータ版なので接触通知が発生しても公費負担にならず、ベータテスターがベータ版を使うベネフィットが乏しいと個人的に感じている。

このような状況を改善するため、ベータ版トラックの取り扱いについて再検討する必要がある。

解決策についてお書きください / Describe the solution you'd like

いくつか解決策が考えられるので列挙する。実現性などは考慮しない。

クローズドベータを廃止して、オープンベータとリリース版のみとする

クローズドベータを廃止して、いきなりオープンベータで配布をする。
今回のように実装したけどクローズドで検討して足踏みするより、実装が決まったらオープンベータとして出すことが同時に決まる構造の方がコストの削減にはつながる。一方、機能案、画面案ではどうにも可否の判別が付かない（実装してみないことには検討もできない）機能がこぼれてしまうのが課題。

クローズドベータからオープンベータへは機能を維持したまま「移行」することを定める

これは内部の取り決めとして、クローズドベータに機能を入れるなら、最低限オープンベータまでは出すと決めてしまう。
十数人規模のクローズドベータで画面についてあれやこれや検討するのは時間がもったいない。積極的にオープンベータとして公開して、数百人、数千人規模の利用者の評判を見たり、ベータテスターの声を集めた方が良いアプリができる。

不具合があるかもしれないことは起動の度に聞いているし、通知が来ても公費負担にならないなどの措置を取っている。

オープンベータからリリース版へ機能を維持したまま「移行」することを定める

つまり、オープンベータはリリース版の一歩手前であって、機能や画面の仕様はリリース版と同じと言う扱いにする。
APKはリリース版と同じものを使い、オープンベータが様々な環境で問題なく動作することを確認後、そのままリリース版に「移行」する。
動作試験と安定度という意味ではこの方法が一番良い一方、実験的な機能の評判を見るという役割は担えなくなる。

人を増やす

現状のコラボレーター（エンジニア）２人の体制で３つのラインをメンテナンスするのは通常の機能開発や不具合の修正に影響が大きいので増員する。

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

オープンベータをやめる。

オープンベータはv1.4.0での不具合発生の反省から導入される安全手段。オープンベータをやめるという選択肢は選んではいけないと考える。

その他 / Additional context

まぁ、 #880 こういうことをやりたいなと思っても、オープンベータにも入れられないかもしれないと思うと、手の動きも鈍るよねと言うことで。

[daisuke-nogami]

個人的な意見のメモですが、クローズドベータをもっと多くの方に使って貰えるようにしつつ

• オープンベータからリリース版へ機能を維持したまま「移行」することを定める

という方向がよいと思いました。
ChromeのCanaryってかなりユーザがいたりしますよね。

しかし、普段からパブリックコメントしようと何しようと直前に政治家がひっくり返せる（場合によってはそれが素晴らしい行動として賞賛されて票になる）という霞が関の文化ゆえの今回のドタバタなのですが、そういうのを、少しでもここから直せないかなぁとは思います。

（逆に、政策ではパブリックコメントの時点で全力で止めにかからないといけないようなものもありますが、COCOAの場合は開発チームとGithubの議論で適切な落とし所に持っていけているので、「なにかを止める」機能はCOCOAのオープンベータには不要だと思いますし、そこはクローズドベータが担っているわけで）