Agentic Very Much! Adoption of Coding Agent in New GitHub Projects
研究新创建的GitHub项目中编码助手的采用情况，发现采用率是之前研究的两倍以上，且AI辅助提交比例显著更高。
2026-06-05 cs.SE
A Topological Analysis of Communication Channels for Knowledge Sharing in Contemporary GitHub Projects
GitHub拥有超过2800万名开发人员，其协作平台的成功通过当代软件项目之间丰富的沟通渠道得以彰显。知识分为两种形式，其共享（通过通信渠道）可以描述为外部化或组合的SECI模型。这些平台彻底改变了开发人员的工作方式，引入了新的渠道，以pull request，issues和wikis的形式分享知识。目前尚不清楚这些渠道如何获取和分享知识。在这项研究中，我们的目标是分析GitHub中的这些通信渠道。首先，使用SECI模型，我们能够绘制知识是如何通过沟通渠道共享的。然后在七个库包项目的大规模拓扑分析中（即，涉及超过7万个项目），我们提取了GitHub中不同沟通渠道的见解。使用两个研究问题，我们探讨了流行和不流行的图书馆软件包项目的渠道和采用渠道的演变。结果表明：（i）当代GitHub项目倾向于采用多种沟通渠道，（ii）沟通渠道随着时间的推移而变化，（iii）沟通渠道用于捕获新知识（即，外部化）和更新现有知识（即，组合）。
2019-09-09 cs.SE
An Insight into the Pull Requests of GitHub
鉴于GitHub项目中不成功的pull请求越来越多，对这些请求的成功和失败的洞察对开发人员来说至关重要。在本文中，我们对来自103，192个分叉项目的20，142名开发人员对78个GitHub基础项目的成功和不成功的拉取请求进行了比较研究。在这项研究中，我们分析了拉式请求讨论文本，项目特定信息（例如，域、成熟度），以及开发者特定信息（例如，经验），以便报告有用的见解，并使用它们来对比成功和不成功的拉取请求。我们相信我们的研究将帮助开发人员克服GitHub中的拉取请求问题，并帮助项目管理员做出明智的决策。
2018-07-05 cs.SE
Testing in the Evolving World of DL Systems:Insights from Python GitHub Projects
本研究通过分析GitHub上300个精选Python深度学习项目，量化了测试自动化、测试类型、测试套件增长及测试实践演变，揭示了开源DL社区中的测试实践现状。
2024-05-30 cs.SE
Wasmizer: Curating WebAssembly-driven Projects on GitHub
本文介绍Wasmizer工具，它定期挖掘GitHub项目，构建并公开WebAssembly源码及二进制数据集，已收集2540个C/C++项目与8915个二进制文件，并用于调查八种编译坏味道。
2023-03-16 cs.SE
Sampling Projects in GitHub for MSR Studies
几乎每一个采矿软件库（MSR）的研究需要，作为第一步，选择主题软件库。这些存储库通常从GitHub等托管服务中收集，使用由研究目标指定的特定选择标准。例如，一项与许可证有关的研究可能对选择明确声明许可证的项目感兴趣。一旦定义了选择标准，就可以使用GitHub API等实用程序来“查询”托管服务。然而，研究人员必须处理这些API的使用限制和缺乏所需信息。例如，GitHub搜索API允许每分钟30个请求，并且在搜索存储库时，仅提供有限的信息（例如，不包括存储库中的提交数量）。为了支持研究人员从GitHub中对项目进行采样，我们提出了GHS（GitHub搜索），这是一个包含25个特征的数据集（例如，提交次数、许可证等）735，669个存储库，用10种程序设计语言编写。这组特征是通过在MSR研究中寻找常用的项目选择标准得出的，数据集不断更新，以（i）始终提供有关现有项目的新数据，以及（ii）增加索引项目的数量。GHS数据集可以通过我们构建的Web应用程序进行查询，该应用程序允许设置研究所需的选择标准的许多组合，并下载匹配存储库的信息：https://seart-ghs.si.usi.ch。
2021-03-08 cs.SE
Experiences and insights from using Github Classroom to support Project-Based Courses
这项工作提出了一种使用GitHub课堂作为共享，结构化和持久化存储库的方法，以支持巴西PUC Minas的软件工程本科课程的基于项目的课程。我们讨论了指导该方法开发的不同利益相关者的需求。对教授和学生的看法的结果表明，这种方法带来了好处。除了吸取的教训，我们提出的见解，通过采用指标来监控技能的发展，验证学生的工作组合，并采用基于项目的课程工具支持，提高下一代软件工程师的教育。
2021-03-12 cs.SE
An Empirical Study of ChatGPT-Related Projects and Their Issues on GitHub
本文基于 GitHub 上 200 个高星 ChatGPT 相关项目及其 23,609 个议题，通过主题建模识别三类项目和十个议题主题，分析其流行度、难度与演化差异，并为开发者和平台管理者提供改进建议。
2024-08-11 cs.SE
Design of the Inspection Process Using the GitHub Flow in Project Based Learning for Software Engineering and Its Practice
基于项目的学习（PBL）的软件开发（我们称之为软件开发PBL）已获得关注，作为一种实用的教育方法。许多研究报告了在软件开发PBL中引入GitHub等社交编码工具的情况。在教育中，向学习者提供反馈（建议，错误更正等）是很重要的，特别是在软件开发PBL中，因为几乎所有的学习者都是第一次从技术和管理方面的角度来处理实际的软件开发。本研究将在一般软件开发活动中进行的检查视为提供反馈的机会，并提出了使用GitHub上的拉取请求的检查过程。通过将所提出的过程应用到实际的软件开发PBL中，我们能够对学习者创建的工件的准确位置进行反馈。
2020-02-06 cs.SE
HackRep: A Large-Scale Dataset of GitHub Hackathon Projects
Eindhoven University of Technology（埃因霍温理工大学）；Carnegie Mellon University（卡内基梅隆大学）
本文介绍HackRep数据集，包含10万多个GitHub仓库，用于研究黑客马拉松项目的持续性、团队构成及地理分布，探索其在软件工程研究中的应用价值。
2026-03-31 cs.SE
What's in a GitHub Star? Understanding Repository Starring Practices in a Social Coding Platform
除了基于git的版本控制系统，GitHub还集成了几个社交编码功能。特别是，GitHub用户可以启动存储库，大概是为了表达对开源项目的兴趣或满意度。然而，作为一个项目的主角的真正和实际意义从来没有深入和有充分根据的实证调查的主题。因此，我们在本文中提供了一个完整的研究GitHub明星的含义，特点和动态增长。首先，通过对791名开发人员进行调查，我们报告说，四分之三的开发人员在使用或为GitHub项目做出贡献之前会考虑星级数量。然后，我们对排名前5,000位的GitHub存储库的特征进行了定量分析。我们提出了四种模式来描述恒星的增长，这是来自聚类后的时间序列代表的恒星数量的研究存储库，我们还揭示了115开发人员对这些增长模式的看法。最后，我们向开源项目经理提供了一系列建议（例如，关于社交媒体推广的重要性）以及GitHub用户和软件工程研究人员（例如，在GitHub明星选择项目时面临的风险）。
2018-11-19 cs.SE
GitHub-OSS Fixit: Fixing bugs at scale in a Software Engineering Course
许多研究表明，将开源项目引入软件工程（SE）课程教学的好处。然而，现有的研究有几个局限性，限制了开源项目在课堂环境中的广泛适应，包括（1）所选择的项目仅限于一个特定的项目，（2）大多数研究只调查了它对教授特定SE概念的影响，以及（3）学生可能会在他们的贡献中犯错误，导致质量差的代码。与此同时，软件公司已经成功推出了Google Summer of Code（GSoC）和FindBugs“fixit”等项目，为开源项目做出贡献。受这些项目成功的启发，我们提出了GitHub-OSS Fixit，这是一个课程项目，通过修复GitHub中报告的错误，教导学生为开源Java项目做出贡献。我们描述了我们的课程大纲，通过鼓励使用几个自动化的程序分析工具来教授学生SE概念。我们还提供了精心设计的指导，供学生参与GitHub-OSS Fixit。由于所有的讲座和实验都是在线进行的，我们认为我们的课程设计可以帮助指导未来的在线SE课程。总体而言，我们的调查结果显示，学生认为GitHub-OSS Fixit可以帮助他们提高许多技能，并应用课堂上教授的知识。总共有154名学生向24个不同的Java项目提交了214个pull request，其中59个项目被合并，82个项目被开发人员关闭。
2021-02-14 cs.SE
(No) Influence of Continuous Integration on the Commit Activity in GitHub Projects
持续集成（CI）的核心目标是对软件项目进行小的增量更改，这些更改经常集成到主线存储库或分支中。本文提出了一个实证研究，调查如果开发人员调整他们的提交活动对上述目标后，项目开始使用CI。我们分析了93个GitHub项目中的提交和合并活动，这些项目引入了托管CI系统Travis CI，但在引入CI之前已经开发了至少一年。在我们的分析中，我们只发现了一个不可忽略的影响，即合并比率的增加，这意味着在项目开始使用Travis CI之后，合并提交相对于所有提交来说更多。这种效应在相关的研究中也有报道。然而，我们在60个未使用CI的GitHub项目的随机样本中观察到了同样的效果。因此，这种影响不太可能是单独引入CI引起的。我们的结论是：（1）在我们的项目样本中，CI的引入并没有导致开发人员的提交活动发生重大变化，（2）在将效果归因于可能不是观察到的效果的原因的治疗之前，将提交活动与基线进行比较是很重要的。
2018-09-14 cs.SE
A Dataset for GitHub Repository Deduplication: Extended Description
本文构建了一个包含 1060 万个 GitHub 重复项目的数据集，通过六项指标排名和去噪图连通分量识别副本并关联最终父项目，为实证软件工程提供去重参考。
2020-06-15 cs.SE
Newcomer Candidate: Characterizing Contributions of a Novice Developer to GitHub
背景：吸引、加入和留住开源软件（OSS）项目的任何新来者对他们的生计至关重要。最近的研究得出结论认为，开放源码软件项目由于放弃和新来者参与不足而有失败的风险。有证据表明，越来越多的新用户正在加入GitHub，然而，他们对OSS项目的贡献程度尚不清楚。目的：在这项研究中，我们创造了术语“新人候选人”来描述GitHub平台的新用户。我们的目标是跟踪和描述他们最初的贡献。作为初步调查，我们在GitHub上收集了208个新候选人的贡献。使用这个数据集，我们计划跟踪他们的贡献，以揭示见解。方法：我们将使用混合方法，即，定量和定性，以确定新人候选人是否实践社交编码，他们的贡献类型，他们的目标项目，以及他们最终加入OSS项目的比例。限制：主要限制是我们的新候选人仅限于从我们的初步调查中收集的候选人。
2020-08-06 cs.SE
How Do Java Developers Reuse StackOverflow Answers in Their GitHub Projects?
本文通过克隆检测、关键词搜索和人工检查的混合方法，挖掘并研究了GitHub Java项目中复用的StackOverflow回答特征，发现被复用的回答得分更高、代码更长，且开发者多采用部分复用或重写而非完全复制。
2024-08-29 cs.SE
Whom Are You Going to Call?: Determinants of @-Mentions in GitHub Discussions
开源软件（OSS）项目的成功依赖于群众的贡献。当一个问题出现在基于拉式请求的系统中时，@-提及被用来呼吁人们进行任务;以前的研究表明，讨论中的@-提及与更快的问题解决有关。在大多数项目中，可能有许多开发人员可以在技术上处理各种任务。但OSS支持分布在各种社会和地理背景以及参与程度的动态团队。因此，重要的是要知道该向谁求助，即，谁可以信赖或信任的重要任务相关的职责，为什么。在本文中，我们试图了解开发人员的哪些可观察的社会技术属性可以用来构建良好的模型，这些模型在GitHub问题和拉请求讨论中被提到。我们建立了未来@提及的整体和特定项目预测模型，以捕捉200个GitHub项目中@提及的决定因素，并了解这些决定因素是否以及如何在项目之间存在差异。我们发现，知名度，专业知识和生产力与@-提及的增加，而响应不是，在一些控制变量的存在。此外，我们发现，尽管存在特定于项目的差异，但整体模型可用于跨项目预测，这表明其在GitHub范围内的实用性。
2018-06-21 cs.SE
A Study of Potential Code Borrowing and License Violations in Java Projects on GitHub
随着开源软件数量的不断增加，像GitHub这样促进代码重用的服务的普及，以及对开源软件许可的常见误解，代码中的许可违规问题越来越突出。在这项研究中，我们从GitHub上编译了一个广泛的流行Java项目语料库，搜索它的代码克隆，并在代码片段层面上对可能的代码借用和许可证违规行为进行了原始分析。我们选择Java作为语言是因为它在工业界很受欢迎，因为可能的法律诉讼，剽窃问题特别相关。我们分析和讨论了文件和项目中94个不同的发现和手动评估的许可证的分布，文件许可证的差异，许可证之间潜在的代码借用的分布，各种类型的可能的许可证违规，最违反的许可证等。研究特定代码块中可能的许可证违规，我们发现，其中29.6%可能涉及潜在的代码借用，其中9.4%可能违反原始许可证。
2020-07-06 cs.SE
How Early Participation Determines Long-Term Sustained Activity in GitHub Projects?
本文结合 Blumberg 绩效模型、XGBoost 与 LIME，基于 GitHub 项目前三个月参与数据预测长期活跃度，揭示经验、投入、非代码贡献和社区结构的作用。
2023-09-28 cs.SE
Studying the Characteristics of AIOps Projects on GitHub
本研究首次系统分析GitHub上的开源AIOps项目，通过仓库指标、定性分析和质量评估，揭示其快速增长但质量较差的问题，并提出改进方向。
2023-09-05 cs.SE
Sosed: a tool for finding similar software projects
在本文中，我们提出了Sosed，用于发现类似的软件项目的工具。我们使用fastText来计算子令牌嵌入到200种语言的120，000个GitHub存储库的密集空间中。然后，我们对嵌入进行聚类，以识别反映源代码中主题的语义相似的子标记组。我们使用900万个GitHub项目的数据集作为参考搜索基础。为了识别类似的项目，我们比较了它们的子令牌之间的集群分布。该工具接收任意项目作为输入，以16种最流行的程序设计语言提取子标记，计算集群分布，并在搜索库中找到具有最接近分布的项目。我们用简短的描述标记了子令牌集群，以使Sosed能够产生可解释的输出。Sosed可在https://github.com/JetBrains-Research/sosed/上获得。该工具演示可在https://www.youtube.com/watch?上获得v=LYLkztCGRt8。子令牌的多语言提取器可在https://github.com/JetBrains-Research/buckwheat/单独获得。
2020-07-06 cs.SE
CORRECT: Code Reviewer Recommendation in GitHub Based on Cross-Project and Technology Experience
同行代码评审在软件开发的早期阶段定位常见的编码规则违反和简单的逻辑错误，从而降低总体成本。然而，在GitHub中，为拉取请求识别适当的代码审查者是一项重要的任务，因为审查者识别的可靠信息通常不容易获得。在本文中，我们提出了一种代码评审推荐技术，不仅考虑了相关的跨项目工作历史（例如，外部库经验），而且还包括开发者在与拉取请求相关联的某些专门技术方面的经验，用于确定她作为潜在代码审查者的专业知识。我们首先激励我们的技术使用探索性研究与10个商业项目和10个相关的库外部的这些项目。在10个商业项目和6个开源项目的17，115个pull请求上的实验表明，该方法在代码评审员推荐中的推荐准确率为85%~ 92%，精确率约为86%，召回率为79%~ 81%，具有很好的应用前景。与最先进的技术相比，也验证了实证研究结果和我们的推荐技术的优越性。
2018-07-09 cs.SE
Do as I Do, Not as I Say: Do Contribution Guidelines Match the GitHub Contribution Process?
开发人员贡献指南用于GitHub等社交编码网站，以解释和塑造项目期望贡献者遵循的流程。他们为所有参与者设定了标准，并“节省了因不正确创建的拉取请求或必须拒绝和重新提交的问题而造成的时间和麻烦”（GitHub）。然而，我们缺乏对典型贡献准则的内容的系统理解，以及在实践中遵循这些准则的程度。此外，理解指南如何影响使用持续集成作为贡献过程的一部分的项目是特别有意义的。为了解决这一知识差距，我们对53个GitHub项目进行了混合方法研究，这些项目具有明确的贡献准则，并对准则进行了编码以提取关键主题。然后，我们使用GitHub活动数据创建了一个流程模型（例如，提交、新问题、新的拉取请求），以将实际活动与规定的贡献准则进行比较。我们发现，这些项目中约有68%与预期过程有很大差异。
2019-08-06 cs.SE
GitHub Actions: The Impact on the Pull Request Process
本文研究 5,000 个热门 GitHub 仓库对 GitHub Actions 的采用情况及其对 PR 流程的影响，发现其改变沟通、提交、拒绝率和合并耗时。
2023-07-27 cs.SE
Social Popularity of GitHub Projects: A Lifeline or a Liability?
Guru Nanak Dev University（古鲁纳克德夫大学）
本研究使用加速失效时间模型分析73,000多个GitHub仓库，发现人力资本是项目存活的关键，而过度社会关注反而成为负担，与易用性结合时加速项目停滞，需平衡可见性与劳动力。
2026-07-02 cs.SE
Social Media Reactions to Open Source Promotions: AI-Powered GitHub Projects on Hacker News
本文通过分析两年内 2,195 条 HN 帖子及 1,814 个相关 GitHub 仓库，发现 Hacker News 推广可显著提升 AI 开源项目的 forks、stars 与贡献者数量。
2025-06-14 cs.SE
Automatic Detection of Public Development Projects in Large Open Source Ecosystems: An Exploratory Study on GitHub
GitHub托管着超过1000万个软件项目，是研究开发人员和软件项目行为的最重要数据源之一。然而，随着开源数据集规模的增加，挖掘这些数据集的潜在威胁也越来越大。随着数据集的增长，人类确认所有样本的质量变得越来越不现实。一些研究已经调查了这个问题，并提供了解决方案，以避免样本选择中的威胁，但其中一些解决方案（例如，寻找发展项目）需要人为干预。当要处理的数据量增加时，这些半自动解决方案变得不那么有用，因为需要人工干预的工作远远超出了可承受的范围。为了解决这个问题，我们研究了GHTorrent数据集，并提出了一种方法来检测公共开发项目。结果表明，我们的方法可以从两个方面有效地改进样本选择过程：（1）我们提供了一个简单的模型来自动选择样本（准确率0.827，召回率0.947）;（2）我们还提供了一个复杂的模型，以帮助研究人员仔细筛选样品（比手动确认所有样本减少63.2%的工作量，并且可以实现0.926的精确度和0.959的召回率）。
2018-05-08 cs.SE
Automatic Detecting Unethical Behavior in Open-source Software Projects
鉴于开源软件（OSS）项目的快速增长，道德考虑变得越来越重要。过去的研究集中在特定的伦理问题上（例如，开放源码软件中的性别偏见和公平性）。在OSS项目中，几乎没有关于不同类型的不道德行为的研究。本文首次从利益相关者的角度对OSS项目中的不道德行为进行了研究。我们对316个GitHub问题的研究提供了一个由六个道德原则指导的15种不道德行为的分类（例如，新的不道德行为的例子包括软分叉（复制一个仓库而不分叉）和自我推广（推广一个仓库而不自我识别为仓库的贡献者）。我们还确定了18种受不道德行为影响的软件工件。在我们的研究中发现的各种类型的不道德行为（1）在GitHub中做出贡献时，需要引起开发人员和研究人员的注意，（2）指出了OSS项目中自动检测不道德行为的未来研究。基于我们的研究，我们提出了Etor，一种可以自动检测六种类型的不道德行为的方法，通过使用本体工程和语义Web规则语言（SWRL）规则来建模GitHub属性和软件工件。我们对195，621个GitHub问题（1，765个GitHub存储库）的评估显示，Etor可以自动检测548个不道德行为，平均真阳性率为74.8%。这表明了OSS项目中自动检测不道德行为的可行性。
2023-02-23 cs.SE
GitHub OSS Governance File Dataset
该研究提出了一个包含710个GitHub托管OSS项目的纵向数据集，包含其治理文件、提交记录、问题和评论等，旨在促进关于正式治理文档对OSS项目和社区影响的研究。
2023-04-02 cs.SE
An Exploratory Study of Documentation Strategies for Product Features in Popular GitHub Projects
本研究通过对 25 个热门 GitHub 仓库的定性内容分析，揭示了开源项目功能文档普遍存在非结构化、与源代码关联薄弱的问题，指出功能可追踪性和可维护性面临风险。
2022-08-02 cs.SE
Engineering Students' Usage and Perceptions of GitHub Copilot in Open-Source Projects
University of Florida（佛罗里达大学）
研究探讨了工程学生在开源项目中使用GitHub Copilot的差异，分析了性别、编程能力及AI熟悉度对使用情况的影响，发现学生更倾向于使用聊天和代码生成功能。
2026-04-12 cs.SE
What's Inside a GitHub Repository? An Empirical Study on the Contents of 10K Projects
DCC, UFMG（联邦米纳斯吉拉斯大学计算机系）；REALISE Lab, Concordia University（康科迪亚大学）
本文通过分析10000个GitHub仓库的文件和目录，揭示了过去十年仓库内容的变化，包括README.md标准化、GitHub Actions兴起、配置格式演变及生成式AI相关内容的增长。
2026-07-15 cs.SE
Continuous integration in a social-coding world: Empirical evidence from GitHub. **Updated version with corrections**
持续集成是一种软件工程实践，它频繁地将所有开发人员的工作副本与一个共享的主分支合并，例如，一天几次随着GitHub的出现，一个以其“社交编码”功能而闻名的平台，该功能有助于协作和共享，并且目前是开源世界中最大的代码主机，协作软件开发从未如此突出。在GitHub开发中，可以区分两种类型的开发人员对项目的贡献：直接贡献，来自对主项目存储库具有写访问权限的典型的一小群开发人员，以及间接贡献，来自分叉主存储库的开发人员，在本地更新他们的副本，并提交pull请求进行审查和合并。在本文中，我们将探讨GitHub开发人员如何使用持续集成，以及贡献类型（直接与间接）和不同的项目特征（例如，主程序设计语言或项目年龄）与自动构建的成功相关联。
2015-12-06 cs.SE
Poster: Communication in Open-Source Projects--End of the E-mail Era?
通信在软件工程中是必不可少的。特别是在分布式开源团队中，沟通需要得到包括邮件列表、论坛、问题跟踪器和聊天系统在内的渠道的支持。然而，我们并不清楚开源项目中的利益相关者使用哪些沟通渠道。在这项研究中，我们通过调查400个GitHub项目的统计代表性样本来填补知识空白。我们通过正则表达式在项目数据上发现所使用的通信渠道。我们发现：（1）有一半的GitHub项目使用可观察到的沟通渠道;（2）GitHub问题、电子邮件地址和现代聊天系统Gitter是最常见的渠道;（3）邮件列表只有五个，市场份额低于所有现代聊天系统的总和。
2018-03-26 cs.SE
Attribution Required: Stack Overflow Code Snippets in GitHub Projects
Stack Overflow（SO）是最大的开发者问答网站，提供了大量可复制的代码片段。使用这些片段会引起各种维护和法律问题。SO许可证需要署名，即，引用原始问题或答案，并要求派生作品采用兼容的许可证。虽然有一个激烈的辩论SO的许可证模型的代码片段和所需的归属，很少有人知道的程度，代码片段被复制从SO没有适当的归属。在本文中，我们提出了一项实证研究的研究设计和总结结果，分析了GitHub项目中SO代码片段的属性和非属性使用。平均而言，3.22%的被分析仓库和7.33%的流行仓库包含对SO的引用。此外，我们发现开发人员更愿意参考SO上的整个线程，而不是特定的答案。对于Java，至少有三分之二的复制片段没有属性。
2017-07-03 cs.SE
Unusual Events in GitHub Repositories
在大型和活跃的软件项目中，让开发人员了解所有项目活动变得不切实际。虽然可能没有必要了解每个提交或问题，但可以说了解不寻常的提交或问题是很重要的。为了研究这一假设，我们在200个GitHub项目中识别出了异常事件，使用了一个全面的列表，列出了工件可能异常的方式，并要求140名负责这些事件或受这些事件影响的开发人员对相应信息的有用性发表评论。基于2,096个答案，我们确定了开发人员认为特别有用的不寻常事件的子集，包括大量的代码修改和不寻常的审查活动，以及这些答案背后原因的定性证据。我们的研究结果提供了一种方法，可以减少开发人员需要解析的信息量，以便在项目中保持最新的开发活动。
2018-04-30 cs.SE
Bounties in Open Source Development on GitHub: A Case Study of Bountysource Bounties
由于开源软件的自愿性质，很难找到一个开发人员来完成特定的任务。例如，有些问题报告可能过于繁琐，而且对于自愿做这些报告的人来说并不令人兴奋，但这些问题报告可能对项目的成功具有高度优先级。为了激励实施这样的问题报告，可以提出金钱奖励，即，奖励给完成该特定任务的开发人员。在本文中，我们研究了GitHub上开源项目中的奖金，以更好地了解如何利用奖金来解决问题报告方面的问题。我们调查了5,445个GitHub项目的赏金。这些赏金是通过Bountysource平台提出的，总赏金价值为406，425美元。我们发现，1）一般来说，提出奖金的时间和奖金使用频率是影响问题得到解决的可能性的最重要因素。更具体地说，如果问题报告是针对奖金使用更频繁的项目，并且如果奖金提议更早，那么问题报告更有可能得到解决。2)在以前没有使用奖金的项目中，问题报告的奖金价值是影响问题解决可能性的最重要因素。这些项目的支持者提出了更高的赏金价值来解决问题。3)对于那些将资金投资于长期问题报告的支持者来说，存在浪费资金的风险。
2019-04-04 cs.SE
The Landscape of Toxicity: An Empirical Investigation of Toxicity on GitHub
该研究通过大规模混合方法实证分析2828个GitHub开源项目，使用ToxiCR检测并手动验证评论毒性，揭示了毒性类型、项目特征与参与者行为的关联，为缓解开源社区毒性提供了数据支撑。
2025-02-12 cs.SE
Deciphering WONTFIX: A Mixed-Method Study on Why GitHub Issues Get Rejected
本研究采用混合方法分析GitHub 3132个热门仓库的wontfix标签使用情况，发现约30%项目使用该标签，归纳出八大使用原因，指出其是资源管理关键工具但可能影响社区参与与管理透明度。
2025-10-01 cs.SE
Automatic Identification and Extraction of Assumptions on GitHub
本文提出 Assumption Miner 工具，自动识别并提取 GitHub 项目中分散的开发假设，并通过 TensorFlow 项目示例及评估验证其有效性。
2023-04-25 cs.SE
Testing GitHub projects on custom resources using unprivileged Kubernetes runners
针对现有基于 Kubernetes 的 GitHub Actions Runner 需要 cluster-admin 权限的问题，提出一种完全非特权的自定义设置方案，并在配备 GPU 的集群上验证了其自动部署和测试的可行性。
2023-05-17 cs.SE
TestMiner: Software Testing Analysis for GitHub Repositories
UFMG（米纳斯吉拉斯联邦大学）；University of Sheffield（谢菲尔德大学）；University of Bordeaux, CNRS（波尔多大学，法国国家科学研究中心）
研究针对软件系统测试特性差异带来的理解困难，提出TestMiner工具，可提供项目测试实践概述。通过本科课程中50名学生使用该工具探索真实仓库测试实践，学生反馈良好，此为其主要贡献。
2026-07-15 cs.SE
PHANTOM: Curating GitHub for engineered software projects using time-series clustering
内容：在采矿软件库领域，有许多方法用于过滤数据集，以避免分析低质量的项目。不幸的是，现有的过滤方法并没有跟上现有数据源的增长，例如GitHub，研究人员经常依赖快速而肮脏的技术来管理数据集。目的：本研究的目的是开发一种能够以资源有效的方式过滤大量软件项目的方法。方法：本研究遵循设计科学研究（DSR）方法。所提出的方法PHANTOM从Git日志中提取了五个度量。每个测量被转换成一个时间序列，这是表示为使用k-means算法聚类的特征向量。结果如下：使用之前研究中的基础事实，PHANTOM被证明能够重新发现训练数据集上的基础事实，并且能够在验证数据集上以高达0.87的精度和0.94的召回率识别“工程”项目。PHANTOM使用一台个人计算机在21.5天内下载并处理了1，786，601个GitHub存储库的元数据，比之前使用200个节点的计算机集群的速度快33%以上。通过管理两家公司拥有的100个存储库，研究了在开源社区之外应用该方法的可能性。结论：可以使用无监督的方法来识别工程项目。与现有的监督方法相比，PHANTOM具有竞争力，同时将硬件要求降低了两个数量级。
2020-06-30 cs.SE
Incivility in Open Source Projects: A Comprehensive Annotated Dataset of Locked GitHub Issue Threads
本文构建了一个包含 404 个锁定议题线程和 5961 条评论的标注数据集，用于分析开源项目中的不文明行为，并识别其常见特征、触发因素、目标和后果，为自动检测工具提供资源。
2024-02-06 cs.SE
Usage and Attribution of Stack Overflow Code Snippets in GitHub Projects
Stack Overflow（SO）是最受软件开发人员欢迎的问答网站，提供了大量可复制的代码片段。使用这些片段会引起维护和法律问题。SO的许可证（CC BY-SA 3.0）需要署名，即，引用原始问题或答案，并要求派生作品采用兼容的许可证。虽然有一个激烈的辩论SO的许可证模型的代码片段和所需的归属，很少有人知道的程度，代码片段被复制从SO没有适当的归属。我们提出了一项大规模实证研究的结果，分析了公共GitHub（GH）项目中SO答案中非平凡Java代码片段的使用和属性。我们遵循三种不同的方法来对未归因使用的比例进行三角测量，并与软件开发人员进行了两次在线调查，以补充我们的结果。对于我们分析的不同项目集，包含引用SO的文件的项目比例在3.3%和11.9%之间变化。我们发现，在所有分析过的包含SO代码的存储库中，最多有1.8%的代码以与CC BY-SA 3.0兼容的方式使用。此外，我们估计，从SO复制的代码片段中，最多有四分之一是根据需要进行属性化的。在接受调查的开发人员中，近一半的人承认在没有署名的情况下从SO复制代码，约三分之二的人不知道SO代码片段的许可及其影响。
2018-09-21 cs.SE
A Tool to Extract Structured Data from GitHub
GitHub存储库包含有关项目贡献者、提交数量及其贡献者、发布、拉取请求、程序设计语言和问题的各种详细信息。然而，没有开源项目的系统数据集存在，其中包含有关GitHub上用于知识获取和挖掘的存储库的详细信息。在本文中，我们开发了名为GitRepository的工具支持，它有助于基于所提出的模式创建存储库的数据集。在最初的1680个存储库中，数据集托管了620个存储库（应用了星和叉的基本过滤器）和247个存储库（应用了所有预定义的过滤器后）。该工具提取GitHub存储库的信息，并以CSV格式保存数据。文件和数据库（.DB）文件。
2020-12-07 cs.SE
GitQ- Towards Using Badges as Visual Cues for GitHub Projects
GitHub托管数百万个软件存储库，方便开发人员以多种方式为许多项目做出贡献。大多数关于仓库的信息都是基于文本的，以star、fork、commits等形式出现。然而，愿意为GitHub上的项目贡献内容的开发人员通常会发现，由于GitHub上存在大量的仓库，因此选择合适的项目进行贡献或重用是一件很有挑战性的事情。此外，获取这些所需的信息往往成为一个繁琐的过程，因为人们必须仔细挖掘隐藏在存储库中的信息。为了减轻工作密集型的挖掘过程，研究人员提出了npm标记来概述与项目的构建状态相关的信息。然而，这些标记是静态的，并且将它们的使用限制在包依赖性和构建细节上。向存储库添加诸如标记之类的可视提示可能会减少开发人员的搜索空间。因此，我们提出了GitQ，以自动增加GitHub存储库，其中包含代表源代码和项目维护信息的徽章。将GitQ作为浏览器插件呈现给GitHub可以让使用GitHub的开发人员轻松访问它。基于UTAUT模型，GitQ由15名开发人员进行评估，以了解开发人员对其有用性的看法。我们观察到，15个开发人员中有11个认为GitQ在使用GitQ生成的视觉提示来识别正确的存储库集方面很有用。源代码和工具可以在GitHub上下载，网址是https：//github.com/gitq-for-github/plugin，演示可以在https://youtu.be/c0yohmIat3A上找到…
2022-05-02 cs.HC cs.SE
Automating Test Case Identification in Java Open Source Projects on GitHub
软件测试是软件质量保证的重要组成部分。许多研究人员从测试人员的动机以及测试应该或不应该如何编写的角度来处理测试过程。然而，从建议中并不知道如何在实际项目中编写测试。本文研究了“test”一词在不同自然语言中的指称;“test”一词出现的次数是否与测试用例的数量相关;以及测试框架的使用情况。该分析是在从430万个GitHub项目中选出的38个GitHub开源存储库上进行的。我们手动分析了803个类中的20，340个测试用例，并使用自动化方法分析了170 k个类。结果表明：（一）存在弱相关性（ii）使用静态文件分析的算法正确检测了97%的测试用例;（iii）15%的分析类使用了main（）函数，它代表了在不使用任何第三方的情况下测试生产代码的常规Java程序。党的框架。由于实现的多样性，这种测试的识别非常复杂。这些结果可以被用来更快地识别和定位存储库中的测试用例，理解定制测试解决方案中的实践，以及挖掘测试以提高未来的程序理解。
2021-07-30 cs.SE
Stack Overflow in Github: Any Snippets There?
当程序员寻找如何实现某些编程任务时，Stack Overflow是搜索引擎结果中的热门目的地。多年来，Stack Overflow已经积累了一个令人印象深刻的代码片段知识库，这些代码片段都有充分的文档记录。我们有兴趣研究程序员如何在他们的项目中使用这些代码片段。我们能在实际项目中找到Stack Overflow代码段吗？当使用片段时，这个副本是字面上的还是经过修改的？这些适应是目标工件的特性所要求的专门化，还是程序员的特定需求所激发的？本文介绍的大规模研究分析了Github上托管的90.9万个非fork Python项目，其中包含2.9亿个函数定义，以及Stack Overflow中捕获的190万个Python代码片段。结果是作为块级代码克隆内部和堆栈溢出和GitHub之间的定量分析，并通过我们的研究结果的定性分析作为编程行为的分析。
2017-05-02 cs.SE
Connecting the Models: A Global Mega-model of MDE Projects on GitHub
Universidad de Murcia（穆尔西亚大学）
通过挖掘7436个GitHub项目中的32.5万多个MDE工件，构建数据集并恢复每个项目的元模型，进而建立全局元模型，以研究模型驱动工程在实践中的使用和组合情况。
2026-06-28 cs.SE
Technical Debt Management in OSS Projects: An Empirical Study on GitHub
技术债（TD）是指延迟的任务和不成熟的工件，可能会带来短期的好处，但在长期的维护和发展过程中会产生额外的更改成本。在过去的十年中，人们对TD进行了广泛的研究，许多开源软件项目被用来探索TD的具体方面，并验证TD管理的各种方法。然而，对于开放源码软件开发中的时分复用实践，仍然缺乏全面的理解，这渗透了开放源码软件社区对时分复用概念的理解，以及在开放源码软件开发中如何管理时分复用。为此，我们对整个GitHub进行了实证研究，以探索基于OSS项目中的问题的TDM的采用和执行。我们从GitHub的问题跟踪系统中收集了2009年至2020年期间分布在3，598个存储库中的35，278个标记为TD（TD问题）的问题。调查结果如下：（1）开放源码软件社区正在接受TD概念;（2）对TD实例的分析表明，TD可能会影响软件系统的内部和外部质量;（3）在31.1%的存储库中只发现了一个TD问题，在69.0%的存储库中，所有TD问题都是由一个开发人员发现的;（4）27.3%的知识库在发现TD问题后忽视了TDM;（5）在有TD标签的知识库中，32.9%的知识库放弃了TDM，只有8.2%的知识库采用TDM作为一贯做法。这些发现为TDM实践者提供了有价值的见解，并为进一步调查提供了有前途的研究方向。
2022-12-11 cs.SE
GitHub Marketplace for Practitioners and Researchers to Date: A Systematic Analysis of the Knowledge Mobilization Gap in Open Source Software Automation
用于分发软件产品和服务的市场已经变得越来越受欢迎。GitHub以其通过Git提供的版本控制功能而闻名，于2017年推出了自己的市场。GitHub Marketplace托管第三方应用程序和操作，以自动化软件团队的工作流程。目前，该市场拥有32个不同类别的440个应用程序和7，878个操作。总体而言，419个第三方开发者在这个平台上发布了他们的应用程序，111个不同的客户采用了它们。GitHub项目的流行和可访问性使得这个平台和托管在其上的项目成为软件工程研究中最常见的实验对象之一。一个简单的Google Scholar搜索显示，自2017年以来，有24，100篇研究论文在软件工程领域讨论了GitHub，但没有一篇研究了市场。GitHub Marketplace提供了一个独特的信息来源，介绍了开源软件（OSS）生态系统中从业者用于自动化项目工作流程的工具。在这项研究中，我们（i）挖掘并提供GitHub Marketplace的描述性概述，（ii）对开源软件自动化的研究进行系统的映射，以及（iii）比较自动化工具的最新技术水平和实践水平。最后，我们讨论了GitHub Marketplace在该领域内的知识动员和协作潜力。这是该领域对GitHub Marketplace的第一次研究。
2022-07-31 cs.SE
A Preliminary Study of Fixed Flaky Tests in Rust Projects on GitHub
本文初步研究 GitHub 上 Rust 项目中已修复的 flaky tests，通过分析 53 个测试发现异步等待和并发问题是主要根本原因，为理解 Rust 测试 flakiness 的成因与修复策略提供依据。
2025-02-04 cs.SE
A Study of Cursorrules Files in GitHub Open Source Projects
Leiden Institute of Advanced Computer Science, Leiden University（莱顿大学高级计算机科学研究所）
本研究对GitHub开源项目中的.cursorrules文件开展实证研究，明确其分布、内容特征及与.mdc文件的主题连续性，揭示其多用于小型非专业项目的现状。
2026-08-12 cs.SE
