論文の概要: Guiding Effort Allocation in Open-Source Software Projects Using Bus Factor Analysis

• arxiv url: http://arxiv.org/abs/2401.03303v1
• Date: Sat, 6 Jan 2024 20:55:40 GMT
• ステータス: 処理完了
• システム内更新日: 2024-01-09 19:25:17.050973
• Title: Guiding Effort Allocation in Open-Source Software Projects Using Bus Factor Analysis
• Title（参考訳）: バスファクター分析を用いたオープンソースソフトウェアプロジェクトの取り組み
• Authors: Aliza Lisan, Boyana Norris
• Abstract要約: プロジェクトのバスファクタ(BF)は、「プロジェクトが進めないよう無力化する必要がある主要な開発者の数」と定義されている。 コード変更行(LOCC)やコード行のコサイン差(change-size-cos)といった他のメトリクスを用いてBFを計算することを提案する。
• 参考スコア（独自算出の注目度）: 1.0878040851638
• License: http://creativecommons.org/licenses/by/4.0/
• Abstract: A critical issue faced by open-source software projects is the risk of key personnel leaving the project. This risk is exacerbated in large projects that have been under development for a long time and experienced growth in their development teams. One way to quantify this risk is to measure the concentration of knowledge about the project among its developers. Formally known as the Bus Factor (BF) of a project and defined as 'the number of key developers who would need to be incapacitated to make a project unable to proceed'. Most of the proposed algorithms for BF calculation measure a developer's knowledge of a file based on the number of commits. In this work, we propose using other metrics like lines of code changes (LOCC) and cosine difference of lines of code (change-size-cos) to calculate the BF. We use these metrics for BF calculation for five open-source GitHub projects using the CST algorithm and the RIG algorithm, which is git-blame-based. Moreover, we calculate the BF on project sub-directories that have seen the most active development recently. Lastly, we compare the results of the two algorithms in accuracy, similarity in results, execution time, and trends in BF values over time.
• Abstract（参考訳）: オープンソースプロジェクトが直面する重要な問題は、主要な人材がプロジェクトを離れるリスクである。 このリスクは、長い間開発が続けられ、開発チームが成長してきた大規模プロジェクトで悪化します。 このリスクを定量化するひとつの方法は、プロジェクトに関する知識の集中度を測定することだ。 正式にはプロジェクトのバスファクタ(BF)と呼ばれ、"プロジェクトが進行できないようにするのに無力になる必要のある主要な開発者の数"と定義されている。 提案したBF計算アルゴリズムのほとんどは、コミット数に基づいて、開発者のファイルの知識を測定する。 本研究では,コードの変更行数(locc)やコード行数のコサイン差(change-size-cos)などのメトリクスを用いてbfを計算する。 CSTアルゴリズムとRIGアルゴリズム(git-blame-based)を用いて、これらのメトリクスをオープンソースの5つのGitHubプロジェクトでBF計算に使用します。 また,近年最も活発な開発が見られたプロジェクトサブディレクトリ上でbfを算出する。 最後に,2つのアルゴリズムの精度,結果の類似性,実行時間,時間経過に伴うBF値の傾向を比較した。

関連論文リスト

• Green My LLM: Studying the key factors affecting the energy consumption of code assistants [1.747820331822631]
  本稿では,GitHub Copilotのような大規模言語モデルに基づくコードアシスタントのエネルギー消費について検討する。 その結果,コードアシスタントのエネルギー消費と性能は,コンカレント開発者の数など,様々な要因に影響されていることがわかった。
  論文  参考訳（メタデータ） (2024-11-07T16:00:29Z)
• Codev-Bench: How Do LLMs Understand Developer-Centric Code Completion? [60.84912551069379]
  Code-Development Benchmark (Codev-Bench)は、細粒度で現実世界、リポジトリレベル、開発者中心の評価フレームワークです。 Codev-Agentは、リポジトリのクローリングを自動化し、実行環境を構築し、既存のユニットテストから動的呼び出しチェーンを抽出し、データ漏洩を避けるために新しいテストサンプルを生成するエージェントベースのシステムである。
  論文  参考訳（メタデータ） (2024-10-02T09:11:10Z)
• RAGLAB: A Modular and Research-Oriented Unified Framework for Retrieval-Augmented Generation [54.707460684650584]
  大きな言語モデル(LLM)は対話、推論、知識保持における人間レベルの能力を示す。 現在の研究は、LLMに外部知識を組み込むことによって、このボトルネックに対処している。 RAGLABはモジュール的で研究指向のオープンソースライブラリで、6つの既存のアルゴリズムを再現し、RAGアルゴリズムを調査するための包括的なエコシステムを提供する。
  論文  参考訳（メタデータ） (2024-08-21T07:20:48Z)
• FlowBench: Revisiting and Benchmarking Workflow-Guided Planning for LLM-based Agents [64.1759086221016]
  ワークフロー誘導計画の最初のベンチマークであるFlowBenchを紹介します。 FlowBenchは6つのドメインから51のシナリオをカバーしている。 以上の結果から,現在のLLMエージェントは良好な計画を立てるためにかなりの改善が必要であることが示唆された。
  論文  参考訳（メタデータ） (2024-06-21T06:13:00Z)
• DevEval: Evaluating Code Generation in Practical Software Projects [52.16841274646796]
  我々はDevEvalという名の新しいベンチマークを提案し、実践プロジェクトにおける開発者の経験と一致している。 DevEvalは、119の実用的なプロジェクトから2,690のサンプルを含む厳格なパイプラインを通じて収集される。 DevEvalの5つの人気のあるLCMを評価し、コード生成における実際の能力を明らかにする。
  論文  参考訳（メタデータ） (2024-01-12T06:51:30Z)
• Code Ownership in Open-Source AI Software Security [18.779538756226298]
  コードオーナシップのメトリクスを使用して、5つの著名なオープンソースAIソフトウェアプロジェクトにおける潜在的な脆弱性との相関を調査します。 この結果は、ハイレベルなオーナシップ(マイナーなコントリビュータの数が限られている)と脆弱性の減少との間に肯定的な関係があることを示唆している。 これらの新しいコードオーナシップメトリクスによって、プロジェクトキュレーターや品質保証の専門家が現場プロジェクトを評価し、ベンチマークするのを助けるために、Pythonベースのコマンドラインアプリケーションを実装しました。
  論文  参考訳（メタデータ） (2023-12-18T00:37:29Z)
• Individual context-free online community health indicators fail to identify open source software sustainability [3.192308005611312]
  私たちは1年間に38のオープンソースプロジェクトを監視しました。 この期間に計画は放棄されず、計画された1つのプロジェクトのみが閉鎖された。 結果は極めて異質で、ドキュメント間の共通性はほとんどなく、イシューやコードコントリビューションに対するレスポンス時間の平均、資金/スタッフリソースが利用可能でした。
  論文  参考訳（メタデータ） (2023-09-21T14:41:41Z)
• Fast Optimal Locally Private Mean Estimation via Random Projections [58.603579803010796]
  ユークリッド球における高次元ベクトルの局所的プライベート平均推定の問題について検討する。 プライベート平均推定のための新しいアルゴリズムフレームワークであるProjUnitを提案する。 各ランダム化器はその入力をランダムな低次元部分空間に投影し、結果を正規化し、最適なアルゴリズムを実行する。
  論文  参考訳（メタデータ） (2023-06-07T14:07:35Z)
• Leveraging Data Mining Algorithms to Recommend Source Code Changes [7.959841510571622]
  本論文では、4つのデータマイニングアルゴリズムを用いてソースコード変更を推奨する自動手法を提案する。 性能(精度,リコール,F測定)と実行時間の比較を行った。 Aprioriは大規模プロジェクトに適しているように見えるが、Eclatは小規模プロジェクトに適しているようだ。
  論文  参考訳（メタデータ） (2023-04-29T18:38:23Z)
• Scalable Batch Acquisition for Deep Bayesian Active Learning [70.68403899432198]
  ディープラーニングでは、各ステップでマークアップする複数の例を選択することが重要です。 BatchBALDのような既存のソリューションでは、多くの例を選択する際に大きな制限がある。 本稿では,より計算効率のよいLarge BatchBALDアルゴリズムを提案する。
  論文  参考訳（メタデータ） (2023-01-13T11:45:17Z)
• Big Data = Big Insights? Operationalising Brooks' Law in a Massive GitHub Data Set [1.1470070927586014]
  大規模リポジトリデータにおける開発者の生産性に関する最近の研究の相違を説明できる課題について検討する。 私たちは、私たちの知る限り、チームのサイズやコラボレーションパターンが個人的および集団的生産性に与える影響を調べるために、GitHubプロジェクトの最大の、キュレートされたコーパスを提供しています。
  論文  参考訳（メタデータ） (2022-01-12T17:25:30Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。