実験的

このディレクトリには、新しいアイデアの迅速な反復開発のための、最小限かつ明確に分離されたスペースが含まれています。

安定性契約: trl.experimental 配下のものは、事前の非推奨化なしに、いかなる リリース（パッチバージョンを含む）でも変更または削除される可能性があります。これらの API は本番環境での処理に依存しないでください。

昇格パス（シンプル）

1. メインリポジトリの外でプロトタイプを作成する: 迅速な反復開発のため、自分のフォークまたは別リポジトリで開発を開始します。
2. 実験的な取り込み: 早期ユーザー向けの準備が整ったら、アイデアをtrl.experimental.<feature>に移動します。
3. 改善: テスト、短いドキュメント/例の追加、および使用方法のデモ。
4. Promote: API が安定し、コミュニティからの明確な関心や採用が見られた場合、trl.<feature>（安定版モジュール）に移行します。

削除

Experimental はステージングエリアであり、長期保存先ではありません。機能は昇格されるか削除されるかのどちらかです。上記の安定性契約に述べた通り、削除には非推奨化のサイクルは必要ありません。コードは git の履歴に残り、paper index のエントリも残ります。そのエントリは、実装がリリースされた最後のリリースを指し示します。

閾値によって削除がトリガーされることはありません。削除に関するプルリクエストにおいて、数値を全員が確認した上で判断が行われます。その判断で考慮される要素は以下の通りです。

• 使用方法。テレメトリ、Hubのタグ、およびプルリクエストまたはディスカッションスレッドへの返信です。これら単体では決定的な根拠にはなりませんが、すべてが沈黙していることは強力なシグナルです。
• コードのスキャンによって生成されるレポートとは異なり、機能を実行した際に発生する外部のイシューやプルリクエスト
• 安定したトレーナーがすでにそれをカバーしているかどうか。カバーされている場合、その方が使用頻度よりも優先されます。
• コスト。CIの時間、メンテナンス、トリアージの負荷。
• 下流の消費者。それをインポートするライブラリ。
• オーナー。プロモーションを希望し、そのための作業を遂行する意思のある人。
• 経過年数。コミュニティがそのモデルを見つけ、試すのに十分な時間が経過しているかどうか。

よくある質問

なぜブランチを使わないのですか？ ブランチはユーザーに提供されないためです。パッケージ内の実験的なコードにより、早期採用者が機能を試したりフィードバックを提供したりできます。

これらのAPIは予告なしに変更または削除される可能性がありますか？ はい。trl.experimental 内のものは、どのリリースでも変更または削除される可能性があります。

本番環境でこれを使用すべきですか？ 状況の変化に合わせてコードを迅速に更新できる場合に限り、使用できます。

trl.experimental の問題をメンテナーは迅速に修正しますか？ 必ずしもそうとは限りません。実験的モジュールは新しいアイデアを試す場であり、メンテナーはそこでバグ修正や機能追加のリクエストを優先しない場合があります。機能が安定版 API に昇格するまで（または昇格しない限り）、問題は未解決のまま残る可能性があります。

論文の実装を貢献しました。削除できますか？ はい。trl.experimental 配下のものは、論文の実装を含め、すべて削除可能です。削除された場合、論文インデックス のエントリは残され、そのコードが同梱された最後のリリースを指すようになります。

ランタイム通知を無効にするには?

使用: export TRL_EXPERIMENTAL_SILENCE=1。