ComSum: Commit Messages Summarization and Meaning Preservation

[e4exp]

• https://arxiv.org/abs/2108.10763
• 2021

我々は、テキスト要約のための700万件のコミットメッセージのデータセットであるComSumを発表する。 ソフトウェアコードの変更を文書化する際には、メッセージとその要約の両方が投稿されます。 我々は、これらのメッセージを収集し、フィルタリングすることで、開発者の作業を要約するデータセットを作成しました。 このデータセットは、その規模の拡大、実用性、そして挑戦的な言語領域とともに、経験的ソフトウェアエンジニアリングの生きた分野からも恩恵を受けています。 コミットが類型化されているように、私たちはルージュだけではなく、その意味の保存によってアウトプットを評価することを提案します。

[e4exp]

1 はじめに

世界で書かれるコードの量は増加の一途をたどっています。23 大規模な開発者グループによってコードが作成される場合、文書化は不可欠となり、結果的にコードの品質の一部となります[Santos and Hindle, 2016]。 コミュニケーションの必要性は、分散型開発において特に重要であり、廊下で叫んでも不適切なドキュメントを補うことはできません。

現在のコード開発は、通常、ソースコードの修正を追跡するバージョン管理システムに支えられており、最も一般的なのはGitです。 Gitでは、各変更はコミットと呼ばれます。 コミットには、コードの変更点と、開発者による説明が記載されています。 説明文には、一行の件名と長い説明文が含まれています。 GitとGitHubは、件名を要約として扱い（付録B参照）、開発者の意欲をさらにかきたてます。 したがって、テキスト要約のデータセットを構築するためには、件名を要約として、コミットメッセージの残りの部分をソースとして使用します。 セクション§3では、コミットの要約データセットであるComSumを作成するためのコミットのクエリとフィルタリングのプロセスについて説明します。 このデータセットは、大規模かつ抽象的であり、要約のための新しい領域を導入する（セクション§4のデータセットの説明）。 このデータセットでいくつかのベースライン結果を検討する（セクション§5参照）。 ベースラインには、ニューラル・サマライズのベースラインと、主題とメッセージの関係に基づくベースラインの両方が含まれる。 これらの結果は、データセットとデータセットの特性に関する技術の状態を明らかにします。 コミットはコードの変更を記述するために使用されるため、変更の分類はその意味の重要な部分を占めています。 そのため、要約モデルを評価する際には、参考文献との単語の重複ではなく、どれだけ意味を保持しているかで評価することができます。 セクション§6で説明し、初期分析を行います。

[e4exp]

3 データセットの作成

本節では、提案するデータセット「ComSum」の作成方法について説明する。 具体的には、信頼性の高い要約を抽出するために、どのようにプロジェクトとコミットを取得し、フィルタリングするかについて説明します。 オープンソースのコードは、様々なプラットフォームで大量に共有されています。 Microsoftが所有するGitHubは、バージョン管理システム「Git」を使用するプロジェクトの大規模なホスティングサービスです。 2018年、GitHubは1億のプロジェクトをホストしていると発表しました［Warner, 2018］。 データセットは、BigQuery GitHubスキーマに基づいています[GitHub, 2019]。 このスキーマでは、GitHubにプッシュされたコミットを、さまざまなメタデータ属性によってクエリすることができます。 BigQuery GitHubスキーマには、2021年以前の約340万件の公開プロジェクトが含まれているが、その大半は、小規模であったり、最近のものではなかったり、コードですらなかったりと、ソフトウェア工学の研究には適していない。

3.1 プロジェクトの選択

ソフトウェアは、一般的な目標を共有するプロジェクトやリポジトリで書かれます。 いくつかのファイルが共有されているだけのプロジェクトもあれば、常に更新されているプロジェクトもあります。 私たちは後者に焦点を当て、明確なコミュニケーションが重要ではなく、強制されてもいないコミットを避けるために、前者をフィルタリングすることを目的としています。 そのため、データセットの構築では、関心のあるプロジェクトを特定し、無関係なプロジェクトをフィルタリングすることが主な作業となります。 フィルタリングは、Amit and Feitelson [2021]がソフトウェアのコード品質を研究するために開発した方法をベースにしています。 まず、2020 年の間に少なくとも 50 回のコミットを必要とすることで、十分に大規模で最新の プロジェクトのみを選択します。 これは1週間に1回以下のコミットであり、小さなプロジェクトをフィルタリングするにはかなり低い限界であることに注意してください。 しかし、このステップだけで、関連するプロジェクトの数を 32,562 にまで減らすことができました。 これは、前のステップの 0.96% です。

次のステップは、冗長なプロジェクトの削除です。 Githubでは「フォーク」が可能です。 フォークとは、あるプロジェクトをコピーして、調査したり、メインのプロジェクトを変更せずに修正したりすることです。 我々はGitHub APIを使ってフォークを特定し、データセットから削除しました。 また、「Apache Software Foundation」の「Spark」を使用するために、星の数が多い人気プロジェクトとのコミット数が多すぎるプロジェクトも削除しました。 これは、「Apache Software Foundation」の「Spark」を使用するためであり、趣味で作られたプロジェクトではありません。 このステップでは、前のステップの78%にあたる25,535件のプロジェクトを抽出しました。 バグがないことで特定された、ソフトウェアプロジェクトではなさそうなプロジェクトをフィルタリングしました。 バグを修正したコミットがないプロジェクトは、負の修正コミット確率（CCP）で識別されました[Amit and Feitelson, 2021]。 負のCCPを持つプロジェクトは、ソフトウェアプロジェクトである可能性が低く、プログラミング言語の識別によって外部から検証され、プルリクエストの開発メカニズムが使用されていないことを意味する。 無効な CCP を持つプロジェクトをフィルタリングした後、22,820 個のプロジェクトが残りましたが、これは前のステップの 89% です。 このうち、次の条件に当てはまるコミットがあったのは 19,720 プロジェクトで、これは前のステップの 86％、プロジェクト全体の 0.57％にあたります。

3.2 コミットの選択

データセットを構築する際には、使用目的が非常に重要になります。 今回のケースでは、将来的に様々な用途が考えられます。 例えば、一人用のプロジェクトはコミュニケーションを表していないので、削除した いと思うかもしれない。 また、一人用のプロジェクトは、将来の自分のためのドキュメンテーションであるため、一人用のプロジェクトにのみ興味を持つ人もいるかもしれません。 将来の柔軟性を考慮して、ここでは不必要なフィルタリングを加えないことにしました。 制約条件は2つだけです。 メッセージの長さは、件名よりも少なくとも100文字以上としました。 100という値は任意ですが、意味のある要約をするためには、長さにかなりのギャップが必要です。 将来の再現性のために、2021年より前のコミットのみを考慮しました。 この条件は、データセットの安定性を保証するには不十分であることに注意してください。 なぜなら、既存のプロジェクトが削除され、そのコンテンツがインデックスから削除される可能性があるからです。 この問題に対処するために、データセットの静的バージョンと、それを抽出するためのコードを公開しています。