論文の概要: Characterizing Issue Management in Runtime Systems

• arxiv url: http://arxiv.org/abs/2310.15971v1
• Date: Tue, 24 Oct 2023 16:12:52 GMT
• ステータス: 翻訳完了
• システム内更新日: 2023-10-25 17:47:29.183530
• Title: Characterizing Issue Management in Runtime Systems
• Title（参考訳）: ランタイムシステムにおける課題管理の特徴
• Authors: Salma Begum Tamanna, Gias Uddin, Lan Xia and Longyu Zhang
• Abstract要約: GitHubの34のランタイムシステムリポジトリから約118Kの問題に関する実証的研究を報告する。 拡張、テストの失敗、バグに関する問題は、主にランタイムシステムリポジトリに投稿されている。 82.65%の発行者はラベルでタグ付けされ、28.30%の発行者は指定されていない。
• 参考スコア（独自算出の注目度）: 0.38233569758620056
• License: http://creativecommons.org/publicdomain/zero/1.0/
• Abstract: Modern programming languages like Java require runtime systems to support the implementation and deployment of software applications in diverse computing platforms and operating systems. These runtime systems are normally developed in GitHub-hosted repositories based on close collaboration between large software companies (e.g., IBM, Microsoft) and OSS developers. However, despite their popularity and broad usage; to the best of our knowledge, these repositories have never been studied. We report an empirical study of around 118K issues from 34 runtime system repos in GitHub. We found that issues regarding enhancement, test failure and bug are mostly posted on runtime system repositories and solution related discussion are mostly present on issue discussion. 82.69% issues in the runtime system repositories have been resolved and 0.69% issues are ignored; median of issue close rate, ignore rate and addressing time in these repositories are 76.1%, 2.2% and 58 days respectively. 82.65% issues are tagged with labels while only 28.30% issues have designated assignees and 90.65% issues contain at least one comment; also presence of these features in an issue report can affect issue closure. Based on the findings, we offer six recommendat
• Abstract（参考訳）: Javaのような現代のプログラミング言語は、様々なコンピューティングプラットフォームやオペレーティングシステムにおけるソフトウェアアプリケーションの実装とデプロイをサポートするためにランタイムシステムを必要とする。 これらのランタイムシステムは通常,大規模なソフトウェア企業(ibmやmicrosoftなど)とoss開発者との緊密なコラボレーションに基づいて,githubがホストするリポジトリで開発される。 しかし、その人気と幅広い利用にもかかわらず、私たちの知る限りでは、これらのリポジトリは研究されていない。 GitHubの34のランタイムシステムリポジトリから約118Kの問題に関する実証的研究を報告する。 拡張性、テストの失敗、バグに関する問題は、主にランタイムシステムレポジトリに投稿され、ソリューションに関する議論は、主に問題議論に現れます。 ランタイムシステムリポジトリの82.69%の問題は解決され、0.69%の問題は無視されている。 82.65%の問題はラベルでタグ付けされ、28.30%の発行者は指定され、90.65%の発行者は少なくとも1つのコメントを含む。 調査結果に基づいて 6つの推奨事項を

関連論文リスト

• InEx-Bug: A Human Annotated Dataset of Intrinsic and Extrinsic Bugs in the NPM Ecosystem [0.764671395172401]
  InEx-Bugは103 NPMリポジトリから377のGitHubイシューを手動でアノテートしたデータセットである。 データセットには、メンテナの参加、コードの変更、再開パターンといった、時間的および行動的な豊富なメタデータが含まれている。 分析によると、Intrinsicのバグは(中期8.9対10.2日)より早く解決され、より頻繁に(92%対78%)、また、Extrinsicのバグに比べてコードの変更が頻繁に(57%対28%)必要である。
  論文  参考訳（メタデータ） (2026-02-13T19:03:28Z)
• Outrunning LLM Cutoffs: A Live Kernel Crash Resolution Benchmark for All [57.23434868678603]
  Live-kBenchは、新たに発見されたカーネルバグのエージェントをスクラップし、評価するセルフ進化ベンチマークの評価フレームワークである。 kEnvは、カーネルのコンパイル、実行、フィードバックのためのエージェントに依存しないクラッシュ解決環境である。 kEnvを用いて3つの最先端エージェントをベンチマークし、最初の試行で74%のクラッシュを解決したことを示す。
  論文  参考訳（メタデータ） (2026-02-02T19:06:15Z)
• Analyzing the Availability of E-Mail Addresses for PyPI Libraries [89.21869606965578]
  81.6%のライブラリには、少なくとも1つの有効な電子メールアドレスが含まれており、PyPIが主要なソースとなっている。 698,000以上の無効なエントリを識別します。
  論文  参考訳（メタデータ） (2026-01-20T14:54:58Z)
• RepoGenesis: Benchmarking End-to-End Microservice Generation from Readme to Repository [52.98970048197381]
  RepoGenesisは、リポジトリレベルのエンドツーエンドWebマイクロサービス生成のための、最初の多言語ベンチマークである。 18のドメインと11のフレームワークに106のリポジトリ(60のPython、46のJava)があり、1,258のAPIエンドポイントと2,335のテストケースが検証されている。 その結果、高いAC(最大73.91%)とDSR(最大100%)にもかかわらず、最高のパフォーマンスのシステムはPythonで23.67%のPass@1、Javaで21.45%しか達成していないことが明らかになった。
  論文  参考訳（メタデータ） (2026-01-20T13:19:20Z)
• What Drives Issue Resolution Speed? An Empirical Study of Scientific Workflow Systems on GitHub [4.902956965439]
  科学的システム(SWS)は再現可能でスケーラブルで自動化された科学分析を可能にする上で重要な役割を担っている。 本稿では、GitHubがホストするSWSプロジェクトの集合体における課題管理と解決に関する実証的研究について述べる。
  論文  参考訳（メタデータ） (2025-12-21T18:41:27Z)
• Deciphering WONTFIX: A Mixed-Method Study on Why GitHub Issues Get Rejected [0.0]
  調査では、GitHub上のさまざまなオープンソースリポジトリで willtfix とラベル付けされている問題の存在状況と理由について調査している。 調査の結果、GitHub上のプロジェクトの約30%が、いくつかの問題に対して wontfixラベルを適用していることがわかった。 この研究は、ユーザ固有のコントロールファクタからメンテナ固有の決定まで、ラベル付け問題の背後にある8つの一般的なテーマを、Ventfixとして特定した。
  論文  参考訳（メタデータ） (2025-10-01T23:22:18Z)
• Classifying Issues in Open-source GitHub Repositories [0.0]
  GitHubは、オープンソースコミュニティでもっとも広く使われているソフトウェアメンテナンスプラットフォームである。 開発者は困難に直面しながら、GitHubで問題を時々報告する。 GitHubリポジトリのほとんどは、問題の定期的なラベル付けを保持していない。
  論文  参考訳（メタデータ） (2025-07-25T06:20:54Z)
• CodeAssistBench (CAB): Dataset & Benchmarking for Multi-turn Chat-Based Code Assistance [18.886738819470086]
  我々は,マルチターンプログラミング支援を評価するための最初のベンチマークフレームワークであるCodeAssistBench (CAB)を紹介した。 既存のプログラミングQ&Aベンチマークとは異なり、CABは質問に関連するGitHubの問題からスケーラブルなデータセットを自動的に生成する。 このフレームワークを用いて,231リポジトリにわたる3,286の現実世界のプログラミング質問をテストセットとして構築した。
  論文  参考訳（メタデータ） (2025-07-14T17:19:00Z)
• "I wasn't sure if this is indeed a security risk": Data-driven Understanding of Security Issue Reporting in GitHub Repositories of Open Source npm Packages [8.360992461585308]
  この研究は、GitHubリポジトリ全体で報告された10,907,467件のnpmパッケージを収集した。 これらの問題に関連するタグは、セキュリティ関連の問題に0.13%しか存在しないことを示している。 手動解析のアプローチに続いて、高精度な機械学習モデルを構築し、セキュリティ関連の問題としてタグ付けされていない1,617,738件を特定した。
  論文  参考訳（メタデータ） (2025-06-09T13:11:35Z)
• SwingArena: Competitive Programming Arena for Long-context GitHub Issue Solving [90.32201622392137]
  We present SwingArena, a competitive evaluation framework for Large Language Models (LLMs)。 従来の静的ベンチマークとは異なり、SwingArenaはLLMをイテレーションとして組み合わせて、テストケースを作成し、継続的インテグレーション(CI)パイプラインを通じてパッチを検証するパッチとレビュアーを生成することで、ソフトウェアのコラボレーションプロセスをモデル化する。
  論文  参考訳（メタデータ） (2025-05-29T18:28:02Z)
• CrashFixer: A crash resolution agent for the Linux kernel [58.152358195983155]
  この作業は、システムレベルのLinuxカーネルバグのベンチマークと、Linuxカーネルで実験を実行するプラットフォームを共有するkGymの上に構築されている。 CrashFixerはLinuxカーネルのバグに適応する最初のLCMベースのソフトウェア修復エージェントである。
  論文  参考訳（メタデータ） (2025-04-29T04:18:51Z)
• Unveiling Pitfalls: Understanding Why AI-driven Code Agents Fail at GitHub Issue Resolution [22.03052751722933]
  問題解決フェーズにおけるPythonの実行エラーは、低解像度率と推論オーバーヘッドの増加と相関している。 私たちは、ModuleNotFoundErrorやTypeErrorのような最も一般的なエラーを特定し、OSErrorやデータベース関連の問題のような特に困難なエラーを強調しました。
  論文  参考訳（メタデータ） (2025-03-16T06:24:51Z)
• SWE-bench Multimodal: Do AI Systems Generalize to Visual Software Domains? [64.34184587727334]
  視覚的ユーザ向けJavaScriptソフトウェアにおけるバグ修正機能に基づいて,システム評価を行うSWE-bench Multimodalを提案する。 SWE-bench Mは、Webインターフェース設計、ダイアグラム、データ視覚化、シンタックスハイライト、インタラクティブマッピングに使用される17のJavaScriptライブラリから収集された617のタスクインスタンスを特徴とする。 分析の結果,SWE-benchシステムはSWE-bench Mと競合し,視覚的問題解決や言語間の一般化に限界があることが判明した。
  論文  参考訳（メタデータ） (2024-10-04T18:48:58Z)
• Visual Analysis of GitHub Issues to Gain Insights [2.9051263101214566]
  本稿では,課題タイムラインに関する洞察を提供するために,可視化を生成するプロトタイプWebアプリケーションを提案する。 問題のライフサイクルに焦点をあて、ユーザによる開発パターンの理解を高めるために重要な情報を記述する。
  論文  参考訳（メタデータ） (2024-07-30T15:17:57Z)
• KGym: A Platform and Dataset to Benchmark Large Language Models on Linux Kernel Crash Resolution [59.20933707301566]
  大規模言語モデル(LLM)は、ますます現実的なソフトウェア工学(SE)タスクにおいて一貫して改善されている。 現実世界のソフトウェアスタックでは、Linuxカーネルのような基本的なシステムソフトウェアの開発にSEの取り組みが費やされています。 このような大規模システムレベルのソフトウェアを開発する際にMLモデルが有用かどうかを評価するため、kGymとkBenchを紹介する。
  論文  参考訳（メタデータ） (2024-07-02T21:44:22Z)
• How to Understand Whole Software Repository? [64.19431011897515]
  リポジトリ全体に対する優れた理解は、自動ソフトウェアエンジニアリング(ASE)への重要な道になるでしょう。 本研究では,リポジトリ全体を包括的に理解するためのエージェントによるRepoUnderstanderという新しい手法を開発した。 リポジトリレベルの知識をより活用するために、エージェントをまとめ、分析し、計画する。
  論文  参考訳（メタデータ） (2024-06-03T15:20:06Z)
• Analyzing the Accessibility of GitHub Repositories for PyPI and NPM Libraries [91.97201077607862]
  産業アプリケーションはオープンソースソフトウェア(OSS)ライブラリに大きく依存しており、様々な利点を提供している。 このようなコミュニティの活動を監視するには、エコシステムのライブラリの包括的なリポジトリのリストにアクセスしなければなりません。 本研究では、PyPIライブラリとNPMライブラリのGitHubリポジトリのアクセシビリティを分析する。
  論文  参考訳（メタデータ） (2024-04-26T13:27:04Z)
• MAGIS: LLM-Based Multi-Agent Framework for GitHub Issue Resolution [47.850418420195304]
  大規模言語モデル(LLM)はコード生成において有望であるが、GitHubの問題を解決する上で困難に直面している。 ソフトウェア進化のためにカスタマイズされた4つのエージェントからなる、GitHub Issue Resolution, MAGISのための新しいMulti-Agentフレームワークを提案する。
  論文  参考訳（メタデータ） (2024-03-26T17:57:57Z)
• An Empirical Study on Workflows and Security Policies in Popular GitHub Repositories [9.048328480295224]
  オープンソースプロジェクトでは、誰でもコントリビュートできるので、アクティブな継続的インテグレーションと継続的デリバリ(CI/CD)パイプラインを持つことが重要です。 これらのプロジェクトの多くはGitHubにホストされており、メンテナが自動セキュリティポリシを作成することができる。 私たちはスター数に基づいてGitHubとセキュリティポリシーを何千もの人気のあるリポジトリで測定します。
  論文  参考訳（メタデータ） (2023-05-25T14:52:23Z)
• GiveMeLabeledIssues: An Open Source Issue Recommendation System [9.312780130838952]
  開発者はしばしば、オープンソースソフトウェア(OSS)プロジェクトのイシュートラッキングシステムをナビゲートして、適切なタスクを見つけるのに苦労します。 本稿では,プロジェクトリポジトリをマイニングし,課題を解決に必要なスキルに基づいてラベル付けするツールを提案する。 GiveMeLabeledIssuesは開発者のスキルとタスクのマッチングを容易にし、プロジェクトのメンテナの負担を軽減する。
  論文  参考訳（メタデータ） (2023-03-23T16:39:31Z)
• Using Developer Discussions to Guide Fixing Bugs in Software [51.00904399653609]
  我々は,タスク実行前に利用可能であり,また自然発生しているバグレポートの議論を,開発者による追加情報の必要性を回避して利用することを提案する。 このような議論から派生したさまざまな自然言語コンテキストがバグ修正に役立ち、オラクルのバグ修正コミットに対応するコミットメッセージの使用よりもパフォーマンスの向上につながることを実証する。
  論文  参考訳（メタデータ） (2022-11-11T16:37:33Z)
• GitRank: A Framework to Rank GitHub Repositories [0.0]
  オープンソースリポジトリは豊富な情報を提供し、人工知能(AI)ベースのシステムの構築にますます利用されている。 このハッカソンでは、既知のコード品質測定とGrimoireLabツールキットを使用して、GitRankという名前のフレームワークを実装し、オープンソースのリポジトリを3つの異なる基準でランク付けします。
  論文  参考訳（メタデータ） (2022-05-04T23:42:30Z)

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

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