(ほとんど)放棄されたGitHubプロジェクトに貢献するにはどうすればよいですか?


43

私は最近、GitHubでオープンソースのコラボレーションに取り組もうとしていますが、どのような方法で進めるのが好奇心situation盛かという状況に陥りました。

約1か月前、GitHubで、しばらく使用していて、いくつかのバグを見つけた(修正した)ライブラリのプロジェクトを見つけました。

GitHubコラボレーションへの最初の進出として、最近のアクティビティが最も多いと思われるレポを見つけ、1つのバグを修正し、ユニットテストを追加し、GitHubにプッシュし、プルリクエストを行いました。数時間以内に、私がフォークしたレポジトリのメンテナーは、PRを受け入れ、同様に待っていた他の人々からのいくつかの他のPRにマージしました。

これに拍車をかけ、発見したバグをさらに3つ修正しました。それぞれが自分のリポジトリの別々のブランチにあり、それぞれに問題とプルリクエストを提出しました。

それはほんの1か月前のことで、それ以降プル要求はそのままで、そのままになっています。リポジトリをフォークしたユーザーはあまりアクティブではないようです。過去1年間にGitHubで合計7回の投稿を行っただけで、最初のプルリクエスト以降、そのリポジトリにはコミットがありません。

だから私の質問:

この状況でどのように進みますか?理想的には、親リポジトリにマージされていない自分のリポジトリに変更を加えて、ライブラリの断片化を回避したいと思います。それにもかかわらず、バグ修正と機能の追加を続けたいと思いますが、すべてをマスターブランチにマージし、そのブランチからすべての新しい修正をベースにした場合、フォークしたレポのメンテナーが戻ってきたら、勝ちました「すべての変更を機能/バグ修正ごとに個別のプル要求に分割することはできません(プル要求は通常、機能またはバグ修正ごとに1つのプル要求である必要があると読みました)。

元のレポと一致する1つのブランチを保持し、そのブランチの新しいブランチをすべてベースにしてから、すべてのコミットをマスターブランチにマージしたままにする必要がありますか?そのため、新しい変更をマスターブランチにマージする必要があるたびに、膨大な数のブランチとますます面倒なタスクが残ります。

このような状況にアプローチする典型的な方法は何ですか?プロジェクトは、新しいプルリクエストをレビューするためではなく、元の貢献者によって放棄されることになるのはかなり一般的なようです。これは、誰かが舵を取るだけでそれで走るべき状況ですか?元の貢献者が戻ってきて、再びプロジェクトに取り組みたいと思うと、断片化を引き起こすようです。


4
この質問がおもしろいと思うときは、新しいオープンソースのstackexchangeサイトの提案にも興味があるかもしれません。
フィリップ

好奇心の強い見物人だけのために、メールの会話から出てきたものを共有することに注意してください。:)
winkbrace

@winkbraceこれまでのところ、何もありません。返信はありませんが、2日前にメールを送信しました。何かが発生した場合は、皆さんにお知らせします
JLRishe

回答:


39

私はまだこのような状況にはありませんでしたが、私はそれを試してみました:

所有者に連絡してみてください

たぶん彼らは本当に興味を失ったかもしれませんが、プロジェクトを他の誰か、特にすでに思いやりのあるコミットメントを示した誰かに移したいと思っています。

しかし、おそらく彼らは何か他のもの(仕事、休暇、病気、他のプロジェクト)に専念していて、あなたのPRを処理する時間がありませんでしたが、後でそれを行う予定です。

または、何らかの理由でプロジェクトの作業を永久に停止している可能性があります。

尋ねることなく、あなたはそれを見つけられません。

コミュニティと連絡を取る

確かにプロジェクトに貢献した、または少なくともプロジェクトを使用した他の人々がいます。誰がプロジェクトを分岐したかを確認します(変更を加えていない場合でも、このプロジェクトが成功するのを見ることに興味があるかもしれません)。誰が問題を報告したか、それらにコメントしたかを確認してください。メーリングリスト、フォーラム、StackOverflowメンバーなど、GitHubの外部にもコミュニティがあるかもしれません。

私は最終的にプロジェクトを本当に引き継ぎます、あなたは彼らのサポートが欲しいかもしれません。そして、新しいマスターリポジトリがどこにあるかを知る必要があります。

引き続き適切なプルリクエストを行う

これは、所有者とコミュニティの両方にあなたがそれについて真剣であることを示し、彼らにあなたの貢献を判断させましょう。


1
ありがとうございました。もう少し検索すると、このアドバイスはnpmパッケージこの種の状況に利用できるガイドラインに似ているようです。私はちょうど所有者に電子メールを送りました、そして、彼/彼女が答えるのを見るでしょう。
JLRishe

リポジトリの「所有者」が実際に多数のユーザーを持つ組織である場合、特定のリポジトリのPRを承認できる人を見つけることは非常に困難です。
カウリネーター

15

元のリポジトリの所有者がどこにも見つからず、かなりの期間欠席している場合は、自分のリポジトリをプロジェクトの別のバージョンとして公開します。

これにより、ライブラリの開発のリーダーを引き継ぎ、二度と更新されることなくコーナーで死んでしまうことはありません。元の所有者がレポジトリを閉じた場合でも、世界はフォークされたバージョンを使用できます。


1
はい、単にforkプロジェクトとで、README.md参照を残し、元の所有者に「感謝」します。
ジャレッドバロウズ

回答ありがとうございます(+1)。あなたは間違いなくいくつかの良い点を挙げています。私は最終的にこれに頼ることができますが、今のところは、oefeのアドバイスに従い、レポの所有者に電子メールで連絡できるかどうかを確認します。
JLRishe

もちろん、リポジトリを忘却の対象にしないでください。多くの優れたコードは、Githubの奥深くに隠さなければなりません。元の所有者はもういません。
クラマハ

私は同様の状況にあり、このオプションを使用する必要があるかもしれません-プロジェクトの元の所有者は、繰り返される連絡試行に応答していません。プロジェクトの名前を保持し、最後の公式バージョンからバージョン番号を増やし続けることは適切ですか?名前を変更すると、プロジェクトの既存のユーザーが見つけるのが難しくなるのではないかと心配しています。
ペリシンチオン

1
私もそのような状況にある可能性があります。しかし、元のプロジェクトはすでにBowerに登録されています。名前を保持することは、元の作者に登録を解除してもらうか、バウアーのメンテナーに連絡して介入するよう依頼することを意味します。ただし、後者はあまり気にしません。名前の変更が最良の選択肢かもしれません。
ローレンスI.シデン

0

現在、ほとんどの小規模から中規模のフリーおよびオープンソースプロジェクトはgithub、gitlabなどでホストされているため、Web APIを使用してプロセスの一部自動化することができます。

元のリポジトリがにあると仮定すると、https://github.com/someUserX/projectY/プロセスは次のようになります。

  1. (「マニュアル」)少なくとも彼のgitコミッターの電子メールと問題(有効な場合)を通じて、さまざまな方法で元の作者に連絡してください。

    数週間以内に許可を受け取った場合、または応答がなかった場合、ホストWeb APIを使用して次のような手順を実行するスクリプトを実行できます。

  2. という新しい(GitHub)組織を作成し、projectYその中に元のリポジトリをフォークします->https://github.com/projectY/projectY/

  3. 元の作成者とプルリクエストのすべての作成者(既にマージされ、まだ開いている)を組織管理者として追加する
  4. 新しいフォークの元のリポジトリからすべての(オープン)プルリクエストを再作成します
  5. (未解決の)問題についても同じことをする
  6. すべての管理者に新しいレポを通知します
  7. 古いリポジトリに最後のプルリクエストを作成し、「放棄された」/「アーカイブされた」通知を追加し、READMEの上部にある新しいリポジトリにリンクします。

私はこのアプローチで見る主な問題は、いくつかの「悪い」の貢献者は、管理者のアクセスを得るかもしれないということですが、フリーソフトウェアエバンジェリストとしてピエター・ヒントジェンズは説明(この講演では、たとえば)、悪いコミットは単に元に戻す、とに何のスレッドを提起することはできません生きているプロジェクトであり、時間の経過とともに悪いコミッターが良いものになるのを助けるかもしれません。
ホイジュ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.