論文の概要: Big Data = Big Insights? Operationalising Brooks' Law in a Massive GitHub Data Set

• arxiv url: http://arxiv.org/abs/2201.04588v1
• Date: Wed, 12 Jan 2022 17:25:30 GMT
• ステータス: 処理完了
• システム内更新日: 2023-03-01 08:39:59.519854
• Title: Big Data = Big Insights? Operationalising Brooks' Law in a Massive GitHub Data Set
• Title（参考訳）: Big Data = Big Insights? brooksの法則を巨大なgithubデータセットで運用する
• Authors: Christoph Gote, Pavlin Mavrodiev, Frank Schweitzer, Ingo Scholtes
• Abstract要約: 大規模リポジトリデータにおける開発者の生産性に関する最近の研究の相違を説明できる課題について検討する。 私たちは、私たちの知る限り、チームのサイズやコラボレーションパターンが個人的および集団的生産性に与える影響を調べるために、GitHubプロジェクトの最大の、キュレートされたコーパスを提供しています。
• 参考スコア（独自算出の注目度）: 1.1470070927586014
• License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
• Abstract: Massive data from software repositories and collaboration tools are widely used to study social aspects in software development. One question that several recent works have addressed is how a software project's size and structure influence team productivity, a question famously considered in Brooks' law. Recent studies using massive repository data suggest that developers in larger teams tend to be less productive than smaller teams. Despite using similar methods and data, other studies argue for a positive linear or even super-linear relationship between team size and productivity, thus contesting the view of software economics that software projects are diseconomies of scale. In our work, we study challenges that can explain the disagreement between recent studies of developer productivity in massive repository data. We further provide, to the best of our knowledge, the largest, curated corpus of GitHub projects tailored to investigate the influence of team size and collaboration patterns on individual and collective productivity. Our work contributes to the ongoing discussion on the choice of productivity metrics in the operationalisation of hypotheses about determinants of successful software projects. It further highlights general pitfalls in big data analysis and shows that the use of bigger data sets does not automatically lead to more reliable insights.
• Abstract（参考訳）: ソフトウェアリポジトリやコラボレーションツールからの膨大なデータは、ソフトウェア開発の社会的側面を研究するために広く利用されている。 最近のいくつかの作品が取り組んだ質問の1つは、ソフトウェアプロジェクトのサイズと構造がチームの生産性にどのように影響するかである。 大規模なリポジトリデータを用いた最近の研究によると、大規模なチームの開発者は小さなチームよりも生産性が低い傾向にある。 同様の方法やデータを使っているにもかかわらず、他の研究では、チームの規模と生産性の間に正の線形あるいは超直線的な関係があると主張している。 本研究では,大規模リポジトリデータにおける開発者の生産性に関する最近の研究の相違を説明できる課題について検討する。 さらに、私たちの知る限りでは、チームのサイズとコラボレーションパターンが個人と集団の生産性に与える影響を調査するために調整された、githubプロジェクトの最大でキュレーションされたコーパスも提供します。 私たちの研究は、成功しているソフトウェアプロジェクトの決定要因に関する仮説の運用における生産性指標の選択に関する継続的な議論に寄与します。 さらに、ビッグデータ分析における一般的な落とし穴を強調し、より大きなデータセットの使用が自動的により信頼性の高い洞察に繋がらないことを示す。

関連論文リスト

• Codev-Bench: How Do LLMs Understand Developer-Centric Code Completion? [60.84912551069379]
  Code-Development Benchmark (Codev-Bench)は、細粒度で現実世界、リポジトリレベル、開発者中心の評価フレームワークです。 Codev-Agentは、リポジトリのクローリングを自動化し、実行環境を構築し、既存のユニットテストから動的呼び出しチェーンを抽出し、データ漏洩を避けるために新しいテストサンプルを生成するエージェントベースのシステムである。
  論文  参考訳（メタデータ） (2024-10-02T09:11:10Z)
• Impact of the Availability of ChatGPT on Software Development: A Synthetic Difference in Differences Estimation using GitHub Data [49.1574468325115]
  ChatGPTは、ソフトウェア生産効率を向上させるAIツールである。 10万人あたりのgitプッシュ数、リポジトリ数、ユニークな開発者数に対するChatGPTの影響を見積もっています。 これらの結果は、ChatGPTのようなAIツールが開発者の生産性を大幅に向上させる可能性があることを示唆している。
  論文  参考訳（メタデータ） (2024-06-16T19:11:15Z)
• DevBench: A Comprehensive Benchmark for Software Development [72.24266814625685]
  DevBenchは、ソフトウェア開発ライフサイクルのさまざまな段階にわたる大規模言語モデル(LLM)を評価するベンチマークである。 GPT-4-Turboを含む現在のLLMは、DevBench内での課題の解決に失敗している。 本研究は,LLMを現実のプログラミングアプリケーションに展開する上で,現実的な知見を提供するものである。
  論文  参考訳（メタデータ） (2024-03-13T15:13:44Z)
• Guiding Effort Allocation in Open-Source Software Projects Using Bus Factor Analysis [1.0878040851638]
  プロジェクトのバスファクタ(BF)は、「プロジェクトが進めないよう無力化する必要がある主要な開発者の数」と定義されている。 コード変更行(LOCC)やコード行のコサイン差(change-size-cos)といった他のメトリクスを用いてBFを計算することを提案する。
  論文  参考訳（メタデータ） (2024-01-06T20:55:40Z)
• Towards a Structural Equation Model of Open Source Blockchain Software Health [0.0]
  この研究は探索的因子分析を用いて、一般大衆の関心やソフトウェアの人気を表す潜在構造を特定する。 私たちはGitHubリポジトリでスター、フォーク、テキストの言及が組み合わさっているのに対して、堅牢性のための第2の要因は臨界スコアで構成されていることに気付きました。 ソフトウェアヘルスの構造モデルが提案され、一般の関心が開発者のエンゲージメントに肯定的な影響を与え、ソフトウェアの堅牢性を肯定的に予測する。
  論文  参考訳（メタデータ） (2023-10-31T08:47:41Z)
• On Responsible Machine Learning Datasets with Fairness, Privacy, and Regulatory Norms [56.119374302685934]
  AI技術の信頼性に関する深刻な懸念があった。 機械学習とディープラーニングのアルゴリズムは、開発に使用されるデータに大きく依存する。 本稿では,責任あるルーブリックを用いてデータセットを評価するフレームワークを提案する。
  論文  参考訳（メタデータ） (2023-10-24T14:01:53Z)
• Revisiting Sentiment Analysis for Software Engineering in the Era of Large Language Models [11.388023221294686]
  本研究では,ソフトウェア工学のタスクにおいて,小さな言語モデル (sLLM) を微調整したラベル付きデータ不足に対処する際の大規模言語モデル (bLLM) について検討する。 5つの確立されたデータセットを用いて、ゼロショットと少数ショットのシナリオで3つのオープンソースのbLLMを評価する。 実験により,bLLMsは訓練データと不均衡分布に制限されたデータセットに対して最先端の性能を示すことが示された。
  論文  参考訳（メタデータ） (2023-10-17T09:53:03Z)
• The Dimensions of Data Labor: A Road Map for Researchers, Activists, and Policymakers to Empower Data Producers [14.392208044851976]
  データプロデューサは、取得したデータ、使用方法、あるいはそのメリットについてはほとんど言及していません。 このデータにアクセスし、処理する能力を持つ組織、例えばOpenAIやGoogleは、テクノロジーのランドスケープを形成する上で大きな力を持っている。 研究者,政策立案者,活動家がデータ生産者に力を与える機会を概説する。
  論文  参考訳（メタデータ） (2023-05-22T17:11:22Z)
• Kubric: A scalable dataset generator [73.78485189435729]
  KubricはPythonフレームワークで、PyBulletやBlenderとインターフェースして写真リアリスティックなシーンを生成する。 本研究では,3次元NeRFモデルの研究から光フロー推定まで,13種類の異なるデータセットを提示することで,Kubricの有効性を実証する。
  論文  参考訳（メタデータ） (2022-03-07T18:13:59Z)
• Organizational Artifacts of Code Development [10.863006516392831]
  我々は、異なる国に関連付けられたソフトウェアリポジトリの違いを測定することで、国の社会的影響を研究する。 本稿では,レポジトリのシーケンシャル埋め込みタスクとして,開発活動のシーケンスに基づく新しいモデリング手法を提案する。 我々は、よく知られた企業からのレポスに関するケーススタディを行い、国が企業自体よりも開発における違いをうまく表現できることを見出した。
  論文  参考訳（メタデータ） (2021-05-30T22:04:09Z)
• Competency Problems: On Finding and Removing Artifacts in Language Data [50.09608320112584]
  複雑な言語理解タスクでは、すべての単純な特徴相関が突発的であると論じる。 人間バイアスを考慮したコンピテンシー問題に対するデータ作成の難しさを理論的に分析します。
  論文  参考訳（メタデータ） (2021-04-17T21:34:10Z)

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

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