１つの言語にだけ機能実装するようなプルリクエストをどうするか

[Hiroshiba]

内容

いろんな言語でコアを展開しようとしていますが、おそらく1つの言語だけで機能実装するようなプルリクエストが飛んでくると思います。
僕たちの都合的には1つの言語でだけ機能実装されることはあまり良くない（言語ごとに入っている機能が異なってすごくややこしくなる）けど、プルリクエスト送ってくださった方にとってはそんなこと知らないので、温度感に違いが発生してしまうかもしれません。

あらかじめこの辺りをルール化しておくと不要な衝突を避けられる気がします。
どういうルールにするか考えたいです。

Pros 良くなる点

不要な衝突を避けられる

方法

Rust以外の1つの言語でだけ特別に機能実装してリリースされることはない、ということをルール化する

その他

長いことをOSSやってて思ったんですが、この辺りの気持ちを明文化しておかないと結構事故るので、こういうのは気づいた時に早めにルール作っていくのが良さそうに思ってます。
特に意見なさそうだったら↑の方法に書いた感じでプルリクエスト出そうと思います。

[qryxip]

方針には賛成です。しいて言うなら、やめてほしいラインの例は行数を割いて入れるのが親切かなという程度です。
(PydanticとかZodとかserdeとかのチェックの強化だったり、Pythonでだけstyle_idをNewType化するとかであれば受け入れてよいのではと私は思ってます)

[sevenc-nanashi]

（機能追加をVoicevox Core自体の機能追加、例えばユーザー辞書とかと想定。）コントリビュータによっては実装が難しい（例えば自分はSwift APIを書ける気がしない）ので、少しつらくなる気がします。
プロジェクトルートに、

機能名	Rust	C	Python	Java
tts(kana: false)	⭕	⭕	⭕	⭕
tts(kana: true)	⭕	⭕	⭕	🚧

みたいな感じの機能リストを置いて、機能追加時に書かせるのはどうでしょう？

[y-chan]

あ、@.sevenc-nanashi さんは少し勘違いされているかもです...!

このIssueでは、Rustコア(エンジン)で実装されていない(しない)機能を他言語ラッパーにのみ実装する事例を考えていると思います。
他言語ラッパーにおいて、工事中が起きうるのは仕方ないのかなと。
そして、このIssueでは工事中に関しては考えていないと思います。(もし考えていたらすみません...)

私もこのIssueで述べられている方針に賛成です。
ラッパーのフォルダのREADMEとか、各ファイルのコメントなどに書いてあげれば親切そうには見えますが、メンテナンスが面倒なので簡易でもいいかなという気持ちです(結局の目的は、PRが来たときに「うちはこういう方針だ」と示せればいいと思うので)
実際、コア本体ができること以上のことをいずれかの言語のラッパーができる状態は望ましくないと思います。
ただ、 @.qryxip さんの言うような、各言語の特性を汲んだ機能実装などは許容してもいいのかなと思いました。

[Hiroshiba]

Rust以外の言語で実装されていない機能に関してどうするかに関しても取り決めがあったほうが良さそうに思います！
（機能リスト、良い感じなのではと個人的には思いました。）

僕も型チェックの強化とかはまあ各言語のライブラリ等の状況によって追加実装があっても良い気がしています。
とりあえず、Rust以外の１言語でのコア機能（定義が難しい）追加実装はマージできない方針なことを追記するプルリクエストを書いてみようと思います！

[Hiroshiba]

✅ #632