rubocop-i18n を puppetlabs org から rubocop org にリポジトリ移管したので、その際の思考など。外部 org のリポジトリを取り込むということは、あまりやっていなかったのでその端書きとして。
話の発端としては、RuboCop の Discord に、puppetlabs org でメンテナンスされなくなった rubocop-i18n を rubocop org で引き取ってもらえないかというものだった。
まず、こういった重要な話がチャットでそのまま繰り広げられそうな勢いだったので、大元の GitHub イシューの方に巻き戻した。重要なコンテキストの共有が雑にチャットだけで済まされると、後で経緯を追う検索がしんどくなる (or できなくなる) とか容易に想像がつくので、自分の方でオープンに行う形で巻き取ることにした。フロー型とストック型の情報ツールの使い分け、ちゃんとやろうな。
あとは、puppletlabs という org での Code of Conduct や CODEOWNERS もろもろ、rubocop org 移管後の所管となる rubocop org に準拠したいので、あらかじめ了解を得ておいた。
現在のライセンス選定の理由への問い合わせは単なる好奇心で変更する気はないというか、唐突に変更されて困るのはユーザーなので、そういったあたりは変更する気がない旨も伝えておいた。
その後は具体的な移行手順のやりとり。GitHub リポジトリの権限だけあっても、rubygems.org にリリースできなければ意味がないので、そちらもあわせてもらうようにした。また、puppetlabs/rubocop-i18n を rubocop/rubocop-i18n として GitHub の Transfer 機能で行う場合は両方に権限が必要なので、移行元の puppetlabs/rubocop-i18n リポジトリに管理者権限のコラボレータとして招待してもらう。きちんと Transfer 機能で移行しておけば、移管元のリポジトリ URL にアクセスした場合に、移管先 URL にリダイレクトされるのでこれは重要。
こんな感じで事前にやりとりした話をリポジトリに適用したり、溜まっている Pull Request 解消して、rubocop-i18n 3.1.0 としてリリースしておいた。
自分は使ったことがないのですが、rubocop-i18n を使っていて RuboCop 本体の非推奨警告が出ている場合はアップグレードしておくと良さそうです。
