Game Development-Based Learning Experience: Gender Differences in Game Design
学习理论强调课程中内在和外在动机的重要性，而游戏是一种很有前途的方式，可以在构建游戏并在公共场合或社区中展示或分享游戏时提供这两种动机。新技术和新兴的移动游戏行业进一步证明，学习应该随时随地得到推广。这似乎是一个很有希望的机会，让所有学生学习编码在一个有趣的方式提出了这样的问题，基于游戏的概念是否也有助于解决性别差距的妇女在IT相关领域。中学中已经存在性别差异。这些年是第一次职业选择的年份，但对技术科目的参与程度也很低。为了消除这种性别偏见，欧洲项目“不让一个人掉队”的目标是将由奥地利格拉茨技术大学的一个免费开源非营利项目Catrobat开发的应用程序“口袋代码”纳入不同的学校科目，从而使编码更容易获得，对女生更有吸引力。在该项目期间（2015-2017年），教师得到支持，通过构建想法并通过游戏设计实现这些想法，在学习过程中指导学生。对于本文提交的程序进行了分析，根据他们的游戏设计。具体而言，评估考虑了正式的游戏元素，游戏结构和使用的图形，以及口袋代码的具体方面。程序分析显示了性别常用的设计模式，并建议首选的游戏设计特点的女性青少年。这种分析有助于建立一个更具创造性和包容性的基于游戏开发的学习（GDBL）环境，为自我表达提供空间，并通过构建个人体验来建立内在和外在的激励因素。
2019-01-04 cs.CY cs.SE
The Impact of Team Diversity in Agile Development Education
本研究在敏捷开发课程中分析51个团队，发现性别多样性与项目成功中等正相关，国籍多样性影响微弱，二者结合有负面效应，但促进多样性不损害学生表现。
2025-09-10 cs.CY cs.SE
Data-driven Analysis of Gender Differences and Similarities in Scratch Programs
基于块的编程环境（如Scratch）是计算机科学的一个重要切入点。为了创造一个有效的学习环境，有可能解决计算机科学中的性别不平衡问题，必须更好地了解儿童在使用这种编程环境方面的性别差异。在本文中，我们沿着两个维度探索Scratch程序中的性别差异和相似性：为了了解是什么促使女孩和男孩使用Scratch，我们首次使用无监督机器学习对Scratch程序进行主题分析，使用了由8-10年的女孩和男孩创建的317个程序的数据集。为了了解他们是如何为这些主题编程的，我们对这些项目中实现的代码应用了自动化的程序分析。我们发现，与常见的刻板印象一致，女孩更喜欢围绕独角兽、庆祝、舞蹈和音乐的话题，而男孩倾向于喜欢蝙蝠和食尸鬼的阴郁话题，或者足球或篮球等竞争性话题。女孩更喜欢动画和故事，从而产生更简单的控制结构，而男孩创建更多循环和条件语句的游戏，从而产生更复杂的程序。考虑这些差异有助于提高学习成果和由此产生的与计算相关的自我概念，这是培养对计算机科学长期兴趣的先决条件。
2021-08-16 cs.SE
Exploring the Role of Women in Hugging Face Organizations
本研究通过仓库挖掘方法分析Hugging Face平台机器学习项目中的性别多样性，发现女性在组织和代码提交中占比极低，指出解决性别差异对构建包容的开源生态至关重要。
2025-03-21 cs.CY cs.SE
Implicit Mentoring: The Unacknowledged Developer Efforts in Open Source
传统上，导师制被视为一种自上而下的二元学徒制。然而，这种观点忽略了在日常活动中发生的其他形式的非正式指导，开发人员投入时间和精力，但仍然没有得到承认。在这里，我们调查了开源软件（OSS）中不同风格的指导，以定义和识别隐式指导。我们首先定义隐式指导-贡献者通过嵌入在日常（OSS）活动中的指示和建议指导他人的情况-通过与OSS贡献者的形成性访谈，文献综述和成员检查。接下来，通过对37个Apache项目中的Pull Requests（PR）的实证调查，我们构建了一个分类器来提取隐含的指导，并通过经验和性别的双重镜头来描述它。我们对107，895份PR的分析表明，存在隐式指导（所有PR中有27.41%包含隐式指导），并且它不遵循传统的二元，自上而下的学徒模式。当考虑到导师-学员对的性别时，我们发现在93.81%的情况下普遍存在同性恋倾向-倾向于指导那些性别相同的人。在跨性别辅导的情况下，妇女更有可能指导男子。
2023-02-03 cs.SE
She Elicits Requirements and He Tests: Software Engineering Gender Bias in Large Language Models
The University of Melbourne（墨尔本大学）；Shinshu University（信州大学）
软件开发中的隐性性别偏见是一个有据可查的问题，例如技术角色与男性的关联。为了解决这种偏见，重要的是要更详细地了解它。这项研究使用数据采掘技术来调查与软件开发相关的56项任务（如分配GitHub问题和测试）受到嵌入在大语言模型中的隐性性别偏见影响的程度。我们系统地将每个任务从英语翻译成一种无性别的语言，并调查了与每个任务相关的代词。基于翻译每个任务100倍，在不同的排列，我们发现一个显着的差异，性别代词协会与不同的任务。具体来说，需求获取与代词“他”相关联的情况只有6%，而测试与“他”相关联的情况是100%。此外，与帮助他人有关的任务与“他”有91%的关联，而与询问同事有关的任务只有52%。这些研究结果揭示了一个明确的模式，性别偏见有关的软件开发任务，并解决这个问题，无论是在训练大语言模型，并在更广泛的社会具有重要意义。
2023-03-17 cs.AI cs.CY cs.LG
Understanding Underrepresented Groups in Open Source Software
本研究通过系统性文献综述分析了42篇论文，揭示了开源软件中代表性不足群体的研究现状，发现研究多聚焦于性别（62.3%），而年龄、种族等维度关注不足，并指出多样性虽面临障碍但能带来显著益处。
2025-05-30 cs.SE
Is this GitHub Project Maintained? Measuring the Level of Maintenance Activity of Open-Source Projects
背景：GitHub托管了大量高质量的OSS项目。然而，选择“合适的工具”是一项具有挑战性的任务，因为我们没有关于这些高质量项目的准确信息。目的：在本文中，我们提出了一种数据驱动的方法来衡量GitHub项目的维护活动水平。我们的目标是提醒用户使用未维护项目的风险，并可能激励其他开发人员承担此类项目的维护。方法：我们训练机器学习模型来定义一个度量来表达GitHub项目的维护活动水平。接下来，我们分析了2,927个活跃项目在一年时间内的历史演变。结果：从2,927个活跃的项目中，16%在一年的时间内变得不受维护。我们还发现，与用其他语言实现的项目相比，使用Java-C的项目往往具有更低的维护活动。最后，软件工具-如编译器和编辑器-随着时间的推移具有最高的维护活动。结论：GitHub项目维护活动水平的度量可以帮助开发人员选择开源项目。
2020-03-09 cs.SE
Three Metrics to Explore the Openness of GitHub projects
开源软件项目的发展得益于一群志愿者的帮助。因此，这些项目的成功取决于它们吸引（和留住）开发人员的能力。我们相信项目的开放性，即，一个新用户对它的积极贡献有多容易，可以帮助使一个项目更具吸引力。为了探索软件项目的开放性，我们提出了三个度量标准：（1）项目社区的分布，（2）外部贡献的接受率和（3）成为项目正式合作者所需的时间。我们已经将这些指标调整并应用于GitHub项目的一个子集，从而给出了一些关于其开放性的实际发现。
2014-09-15 cs.SE
Identifying Unmaintained Projects in GitHub
背景：开源软件在现代软件开发中的重要性越来越大。然而，人们也越来越担心这些项目的可持续性，因为这些项目通常由少数开发商管理，他们往往是志愿者。目的：在本文中，我们提出了一种方法来识别未积极维护的GitHub项目。我们的目标是提醒用户使用这些项目的风险，并可能激励其他开发人员承担项目的维护。方法：我们训练机器学习模型，根据一组关于项目活动的特征（提交、分叉、问题等）来识别未维护或稀疏维护的项目。我们通过129个GitHub项目的主要开发人员经验验证了该模型的最佳性能。结果：基于真实开源开发人员的反馈，所提出的机器学习方法具有80%的准确率和96%的召回率。我们还表明，我们的方法可以用来评估项目变得不维护的风险。结论：本文提出的模型可以被开源用户和开发人员用来识别不再积极维护的GitHub项目。
2018-09-11 cs.SE
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
