OpenPerf 框架的搭建与落地

[will-ww]

根据 IEEE Open Source Expaned 专栏主题，以及前期开源纲目中的基本内容，可以选择先从如下四个大的领域入手：

• A 开源生态战略：指从经济、社会、教育、学术、政策、、法律、文化等层面，对开源生态整体状态的分析与理解，例如开源生态人口信息、供应链识别与态势、技术生态演化等；
• B 企业开源治理：指企业开源管理办公室（OSPO）涉及到的各类业务场景，例如开源组件选型、开源合规、供应链安全、排名与激励等；
• C 开源软件开发：指软件项目研发过程中 DevOps 下的各类工程性工作，例如 CI/CD流程、机器人自动化、研发效能提升等；
• D 开源社区运营：指开源社区测的项目管理与运营的相关业务，例如社区角色管理、项目/开发者推荐、贡献度计算等。

然后，结合实验室已经开展的研究工作，以及文献中常见的问题与任务，总结如下若干任务，首批放到 OpenPerf 中：

• 仓库分类（Repo classification）：A、B
• 仓库推荐（Repo recommendation）：D
• 开发者聚类（Developer clustering）：D
• 开发者推荐（Developer recommendation）：D
• 机器人分类（Bot classfication）：C
• 供应链网络构建（Supply chain network construction）：A
• 生态知识网络构建（Ecosystem knowledge graph construction）：A
• 开源协作网络构建（Collaborative network construction）：A
• 供应链风险分析（Supply chain risk analysis）：A、B
• 社区情绪分类（Community sentiment classification）：D
• 归档项目预测（Archived projects prediction）：B、C
• 社区行为预测（Community behavior prediction）：D
• 社区异常检测（Community behavior anomaly detection）：B、D
• 开发者/项目影响力排序（developer/project influence ranking）：A、B、D

目前的一个需要考虑问题是，上述这些任务，可以怎么样进行以下归类，方便大家：1）简洁直观理解，2）易于分类整理，3）后续方便参与贡献：

• 按数据类型：离散序列数据、时间序列数据、文本数据、图数据
• 按问题类型：分类、聚类、关联、异常等

[will-ww]

OpenPerf 是实验室一个重要的成果积累型开源项目：

• 学术界端：迭代研究框架，系统产出包括基准、任务、数据集等内容；
• 工业界端：形成业界标准、在学术影响力和工业影响力之间相互转换。

- Benchmark hierarchy

- 开源 Benchmark hierarchy

我们计划分如下几步走：

• 第一：先选择第三类（数据科学问题）的 Benchmark 进行整理，其他后续考虑；
• 第二：重点关注三个类型的数据：时间/事件序列、文本数据、图数据，期中图数据又是重点；
• 第三：充分参考相关知识框架，系统制定 Benchmark 框架，进而导出各种具体的 Benchmark。

以图数据为例，一个代表性的 Benchmark 框架为”图结构-图任务-图场景“，具体参见这里。

而具体 Benchmark 的导出方式可以有如下几种方式：

• 领域专家型（从开源应用场景导出）：例如，企业开源组件选型场景➡️开源仓库分类➡️多标签分类/基于 readme 文本的分类
  • 企业 OSPO 专家（关注安全合规、可持续发展等）
  • 研发效能专家（关注 DevOps 研发效能）
  • 社区运营专家（关注 DevRel 等）
  • COSS 企业经营者（关注项目-社区契合度、产品-市场契合度等）
  • 国家干部与政策制定者（关注供应链安全、开源经济效益、开源的碳排放结算等）
• 数据科学家型（从数据科学任务导出）：例如，链接预测➡️用户侧 repo 推荐 / 开发者侧 repo 推荐➡️U-R 图上的链接预测 / D-R 图上的链接预测
• 数据工程师型（从标准数据集导出）：例如，U-R 的 star 关系图➡️Repo 关系网络➡️社区聚类问题

[will-ww]

咱们可以先 Draft 一个中文版的研发专刊（7 月 31 日），然后再凝练 ICSE 的 New Idea（9 月 14 日）~

例如，一个可能的框架：

题目：OpenPerf —— 构建面向开源生态可持续发展的基准测试体系与工具集

• 01 概述 @PureNatural

  • 背景
  • 动机
  • 解决的问题

• 02 OpenPerf 总体架构 @will-ww @PureNatural

  • 面向开源领域的基准测试
  • 各个模块的介绍
  • OpenDigger 的位置与关系

• 03 基准测试任务 @bifenglin

  • 提出首批 9 个基准测试

• 04 工具集与基准结果展示 @bifenglin

  • 展示 OpenDigger 工具集
  • 选取实验室已经发表的成果，展示上一节 9 个基准测试的结果

• 05 相关工作 @PureNatural

给出一个参考框架图：

其中，基准框架包括：

• 任务名称：例如“OSS机器人分类”
• 场景：对应上游场景域中的一个或多个场景，例如 DevOps 机器人自动化；
• 类型：对应知识域中的一个或多个抽象任务，例如，分类（通用任务）、日志数据分类（研究领域）
• 数据集：该任务对应的基准数据集，例如 721 GitHub Apps 数据集
• 评价标准：该任务对应的评价标准，例如 Accuracy、Precision/Recall、F1-score、AUC

[bifenglin]

我先大致画了一个场景架构图。（姑且称为场景架构图），可以从更高层面抽象问题场景。可以包含我们现在的task

[PureNatural]

考虑到距离月底仅剩半个月左右的时间，我觉得我们可以按照王老师给出的整体领域划分先展开一定的文字工作，完成整体论文后尝试投稿，即使没有录用可能也会返回来一部分有价值的评审意见供我们英文文章的完善，毕博给出的图可以将开源平台的具体事件或者现有的数据与王老师概括的各项任务相结合，从而可以一目了然的看出这些任务的可行性，当然毕博的图可能也没有办法将所有的任务涵盖，它相对王老师给出的四大领域更具体了一些

王老师以图数据为例进行了一定的展开，我在想我们的基准测试任务以及工具集与成果展示是不是也以图展开也更好一些。

[PureNatural]

目前的一个需要考虑问题是，上述这些任务，可以怎么样进行以下归类，方便大家：1）简洁直观理解，2）易于分类整理，3）后续方便参与贡献：

• 按数据类型：离散序列数据、时间序列数据、文本数据、图数据
• 按问题类型：分类、聚类、关联、异常等

其实如果从研究者的角度来看如何分类的话，是不是按研究方向分他们会更兴趣一些，因为大部分学生或者老师搜论文也是按自己的研究方向进行检索，例如，复杂网络，推荐系统，社区发现，聚类分析，情感分析等等，不过我觉得按问题类型分也没有问题，按数据分的话，我觉得研究者们可能上来不会首先关心数据类型，他们肯定是先选择研究方向再选数据类型，我觉得只要是他感兴趣的领域或者方向，数据类型可能不是他们最关心的点，不知道大家怎么看？

[will-ww]

目前的一个需要考虑问题是，上述这些任务，可以怎么样进行以下归类，方便大家：1）简洁直观理解，2）易于分类整理，3）后续方便参与贡献：

• 按数据类型：离散序列数据、时间序列数据、文本数据、图数据
• 按问题类型：分类、聚类、关联、异常等

其实如果从研究者的角度来看如何分类的话，是不是按研究方向分他们会更兴趣一些，因为大部分学生或者老师搜论文也是按自己的研究方向进行检索，例如，复杂网络，推荐系统，社区发现，聚类分析，情感分析等等，不过我觉得按问题类型分也没有问题，按数据分的话，我觉得研究者们可能上来不会首先关心数据类型，他们肯定是先选择研究方向再选数据类型，我觉得只要是他感兴趣的领域或者方向，数据类型可能不是他们最关心的点，不知道大家怎么看？

嗯，同意。从研究领域和研究方向来看，是个好的出发点。这里的研究领域需要再明确下和结构化下。

根据《数据挖掘：原理与实践》一书的结构，有如下参考：

数据处理流水线，三个模块：

• 数据采集
• 数据预处理：特征提取、数据清洗、特征选择与转换
• 数据分析

其中，数据分析又包括如下三类（三个层面）：

• 基本问题：聚类、分类、关联模式、异常分析
• 数据领域：文本、时序、序列、图、空间
• 应用领域：数据流、Web、社交网络、隐私保护

[will-ww]

《数据思维》一书中，对数据分析归纳为四个层次：

• 描述性分析（Descriptive）
• 诊断性分析（Diagnostic）
• 预测性分析（Predictive）
• 指导性分析（Prescriptive）

而《数据挖掘原理》一书则对数据挖掘任务做了如下的分类：

• 探索性数据分析（Exploratory）
• 描述建模（Ddescriptive modeling）
• 预测建模（Predictive modeling）
• 寻找模式和规则（Patter and rules）
• 根据内容检索（Retrieval by content）

同时，将一个数据挖掘算法（任务，task），用一个由四个基本组建构成的框架来进行描述：

• 模型或模式结构（model & pattern structure）：模型是对数据的高层次、全局性描述，而模式是一种局部概念，反映了数据某一个方面的信息
• 评分函数（score function）：简单一个已拟合模型的质量
• 优化与搜索方法：优化评分函数，并对不同模型和模式结构进行搜索
• 数据管理策略：处理数据管理与访问的问题

[will-ww]

• 03 基准测试任务 @bifenglin

  • 提出首批 9 个基准测试
• 04 工具集与基准结果展示 @bifenglin

十个基准测试可以考虑如下：

1. Git 缺失数据补全：亮博大论文第五章
2. OSS 机器人分类：BotHawk__An_approach_for_Bots_detection_in_Open_Source_Software_Projects
3. 开源社区情绪分类：韩博硕士论文
4. 供应链风险预测：A Maintenance Risk Approach for Open Source Software Supply Chains
5. 项目影响力排序：OpenRank
6. 归档项目预测：Understanding the Archived Projects on GitHub
7. 生态知识网络构建：娄博工作
8. 社区行为异常检测：亮博大论文第三章
9. 开源社区行为指标预测：Temporal Autoregressive Matrix Factorization for High-dimensional Time Series prediction of OSS
10. 开发者/仓库库推荐：基于链接预测的同质开源项目推荐（王皓月）

以上十个基准的分类信息如下：

1. 数据预处理、缺失值问题
2. 行为日志数据、分类问题
3. 文本数据、分类问题
4. 图数据、预测问题
5. 图数据、排序问题
6. 行为日志数据、预测问题
7. 数据预处理、网络构建问题
8. 行为日志数据、异常检测问题
9. 行为日志数据、预测问题
10. 图数据、连接预测问题

[bifenglin]

若是阶段性成果是论文的话，是不是需要先拟一个论文大纲？

[will-ww]

若是阶段性成果是论文的话，是不是需要先拟一个论文大纲？

参见上面的内容，大纲和分工已经都有了~ @bifenglin @PureNatural

[bifenglin]

若是阶段性成果是论文的话，是不是需要先拟一个论文大纲？

参见上面的内容，大纲和分工已经都有了~ @bifenglin @PureNatural

看到了，我下周会先完成一个初步版本。然后可以约定个时间点再一起对一下。

[PureNatural]

我在下周三周四左右也会形成一个版本～

[PureNatural]

中英文摘要我也会先出一版～

[bifenglin]

基于十个基准测试任务和王老师的启发，对体系做了个修正。

其中数据类型分为 ：

• 时序数据
• 文本数据
• 图数据

问题类型分为：

• 预测问题
• 分类问题
• 中心性分析问题
• 网络构建问题
• 异常检测问题
• 预测问题
• 链接预测问题

总体分类如下：

基准测试任务	数据类型	问题类型
Git 缺失数据补全	时序数据	预测问题
OSS 机器人分类	时序数据	分类问题
开源社区情绪分类	文本数据	分类问题
供应链风险预测	时序数据	预测问题
项目影响力排序	图数据	中心性分析问题
归档项目预测	时序数据	预测问题
生态知识网络构建	图数据	网络构建问题
社区行为异常检测	时序数据	异常检测问题
开源社区行为指标预测	时序数据	预测问题
开发者/仓库库推荐	图数据	链接预测问题

有问题请多多指正。

[PureNatural]

链接预测问题应该也算预测问题吧～😊

[bifenglin]

链接预测问题应该也算预测问题吧～😊

是预测问题的一个分支，可以合并进去，链接预测是针对图数据的问题。合并起来不容易引起歧义，结果如下：

基准测试任务	数据类型	问题类型
GitHub 缺失数据补全	时序数据	回归问题
OSS 机器人分类	表格数据	分类问题
开源社区情绪分类	文本数据	分类问题
供应链风险预测	时序数据	回归问题
项目影响力排序	图数据	排序问题
归档项目预测	时序数据	回归问题
生态知识网络构建	图数据	网络构建问题
社区行为异常检测	时序数据	异常检测问题
开源社区行为指标预测	时序数据	回归问题问题
开发者/仓库库推荐	图数据	推荐问题

[PureNatural]

https://paperswithcode.com/sota/aspect-based-sentiment-analysis-on-semeval

这个项目里就展示了每一个具体任务下，不同模型跑出来的结果，方便后续科研工作者与其进行对比。 这是自然语言领域下不同任务的模型榜单，基本上很多该方向的研究者都会参考里面的模型。每一个模型都有对应的源码，论文，准确率，F1值等等

我们在未来或许也可以考虑采用这样的方式公开我们实现的一些基准，方便其他人做比较。

[bifenglin]

https://paperswithcode.com/sota/aspect-based-sentiment-analysis-on-semeval

这个项目里就展示了每一个具体任务下，不同模型跑出来的结果，方便后续科研工作者与其进行对比。 这是自然语言领域下不同任务的模型榜单，基本上很多该方向的研究者都会参考里面的模型。每一个模型都有对应的源码，论文，准确率，F1值等等

我们在未来或许也可以考虑采用这样的方式公开我们实现的一些基准，方便其他人做比较。

这个就是变成了一项服务

[PureNatural]

目前OpenPerf已经通过《计算机学报》的一审，但需要大改，由于里面涉及实验室大量之前的工作，所以还要麻烦部分同学和王老师一起提供一些内容，从而顺利的完成修改，辛苦大家，一共16条意见，我把我不是很确定如何回复的列出来

意见1. 文章对基准本身的介绍存在不清楚的地方。例如，一共包含多少项目？每个 任务的输入和输出是什么？输入的数据规模如何？数据的标签如何而来？

这个由于当时碍于篇幅的原因，在第4章我们没有对那9个任务做太多详细的介绍，而是列举了3个典型的例子详细介绍，现在审稿人要求补充数据集的规模，所以每一小节可能都要做一些说明 4.2 开源自动化机器人识别与分类

• 这一小节的数据说明麻烦毕博给出一些说明，@bifenglin

4.4 开源软件供应链风险预测

• 这一小节同样麻烦毕博

4.5 开源项目影响力排序 这个任务的描述和6.1.2影响力指数基准的理解实在太像了，我不太确定要怎么判断此任务和影响力指数基准任务的区别。

4.6 开源归档项目预测 麻烦小雅

4.7开源网络指标预测 此任务感觉和毕博在opensoda上的任务有些类似，毕博可以确定一下

意见3. 第4.2章提到的软件机器人是什么？可以做什么事情？发表的论文有哪些？这里的Biman账户和BodeGha账户具体说明意思？为什么要识别这些账户？Github上没有对这些账户的记录吗？

这部分内容还是要麻烦毕博给出解释了

意见4：文中第3.1章节，对于“基准测试体系的溯源性和校准”的解释很抽象，能否举例说明？

此问题有两个审稿人都提出来了，这部分我想着就从openrank影响力基准讲解，OpenPerf 中的影响力、活跃度 等指数类基准，通过“开源项目 影响力排序”等任务进行定义并产出最终数据，同时将排名靠前(例如 Top100)的对象作为标杆集，类似这样的实例去讲解溯源性和校准，这个麻烦 @will-ww 王老师看能不能把这个故事润色一下讲的更好一些。

意见9：数据科学任务类基准中各任务选择的依据是什么？测试任务的设计是否能够覆盖所有的开源场景

这里说的选择依据我还真不好确定该去怎么细讲，很多任务都是根据同学们自己的研究方向，现有的研究成果而提出来的，或者就从问题类型，数据类型，应用场景，研究领域覆盖的角度去阐述，同时我们的任务肯定没有覆盖所有的场景，但我觉得可以强调我们设计的基准测试体系是可以覆盖的

意见13：请具体说明图2中“支撑”、“导出”、“探索”这几个箭头的具体含义，并说明基准测试任务是如何构建的。

这里审稿人问基准测试任务是如何构建的，我们一共9个任务，是想让我笼统的回答一个抽象的构建方法，还是说9个任务都描述，我比较倾向前者。我的理解是，可能就是让我们把图2的整个流程讲明白即可，当前可能更多的内容是对图2较多模块的介绍，看大家怎么理解

意见14：本文标题夸大实际贡献。正如本文第7章所述，OpenPerf主要聚焦于数据科学相关的任务，并非整个开源社区所有任务，因此标题中应明确本文范围是“数据科学相关”。此外，标题中提及开源生态“可持续发展”，但纵观全文，审稿人并未发现对开源生态“可持续发展”的定义、说明或讨论，即本文没有回答什么是开源生态“可持续发展”，满足什么条件可以使开源生态“可持续发展”，所提出的方法如何使开源生态“可持续发展”。若无此类讨论，审稿人建议避免使用该类无实际意义的词汇

我感觉还是听审稿人的意见比较合适，要不就把标题修改为 “OpenPerf：面向开源生态的数据科学基准测试体系”或者“OpenPerf：基于数据科学的开源生态基准测试体系”，OpenPerf：面向开源生态的基准测试体系，OpenPerf：面向开源领域的基准测试体系。这个可能还需要 @will-ww 王老师把控一下

大家尽量12月20日之前把内容提出～辛苦大家，有其他问题可以一起讨论。

[will-ww]

意见4：对于“基准测试体系的溯源性和校准”的解释很抽象

这是个不错的可以深入的点，我们需要单独具体再讨论下。同意初步将 OpenRank 作为我们的核心进行校对基础，看怎么来自圆其说一下。

意见9：数据科学任务类基准中各任务选择的依据是什么？测试任务的设计是否能够覆盖所有的开源场景

这个意见不难，实际是是搞反了，并不是我们同学们做的工作拼成 OpenPerf 的，而是应该在 OpenPerf 的指导下，引导大家开展相关工作。我们有专业、成体系的开源业务知识。这块可以采用的背书包括：开源治理系列标准、开源纲目等。

意见13：请具体说明图2中“支撑”、“导出”、“探索”这几个箭头的具体含义，并说明基准测试任务是如何构建的。

这个可以抽象成一个具体的方法和流程，而不是单独每个去说。还是从业务入手，由具体的开源业务问题所导出来。

意见14：本文标题夸大实际贡献。

• 原题目：OpenPerf：面向开源生态可持续发展的基准测试即服务系统
• 候选，如：OpenPerf：面向开源生态可持续发展的数据科学基准测试体系

大家继续~

[PureNatural]

经过两周左右的整理，我已经完成了所有意见的回复，添了近一万多字，下面列出提到的几个主要问题的回复

意见4：文中第3.1章节，对于“基准测试体系的溯源性和校准”的解释很抽象，能否举例说明？

以阿里巴巴开源开发者贡献激励榜为例，该应用旨在通过精准地评价个人在项目中的影响力从而进一步形成对开发者的激励，鼓励更多开发者参与到项目的开发中。若将影响力排名前3的开发者视为开发者标杆，对其溯源发现评价的主要依据为影响力指数基准，影响力指数基准通过计算开发者在协作网络中的贡献度而来，而最终的排序结果则通过开源影响力排序任务产出最终数据，自上而下对标杆类基准完成溯源。同时，可以通过开源影响力排序任务来判定影响力指数的合理性，对每次给出的排序结果进行一次次校准，使其逐步合理；而影响力指数计算的最终结果会直接涉及到标杆类基准最终的判定，通过不断优化调整影响力指数的计算方式则可以校准标杆类基准最后的结果，使其更加符合实际情况。OpenPerf基准测试体系的设计初衷是希望涵盖开源生态下的大多数基准测试任务，目标相对宏大。当前课题组已对三类基准分别给出一定的测试结果，在未来会针对该体系进一步优化，对不同子类下的基准测试展开详细定义，完善整个体系下的基准测试结果。

意见9：数据科学任务类基准中各任务选择的依据是什么？测试任务的设计是否能够覆盖所有的开源场景

在OpenPerf体系的引导下，结合数据科学任务的多种问题类型、数据类型、研究领域以及开源领域的主要应用场景，实验室成员完成了开源场景下较为典型的9个数据科学任务类基准。当前我们设计了9个数据科学类基准任务，并未覆盖所有的开源场景，因为开源领域的任务是可扩展的，研究者们可以根据自己的研究方向结合开源的场景提出新的任务，但我们设计的体系是可以覆盖整个开源场景的，在未来会补充更多基准测试的任务。已在本文未来工作中描述。

意见13：请具体说明图2中“支撑”、“导出”、“探索”这几个箭头的具体含义，并说明基准测试任务是如何构建的。

我们对基准测试任务的构建流程进行了详细的描述，内容如下： OpenPerf通过最底层的数据科学知识体系，结合具体的数据领域、研究领域以及多种通用任务类型，同时结合上层具体的业务场景，共同探索开源领域的基准空间。开源领域业务场景包含开源生态战略、企业开源治理、开源软件开发以及开源社区运营，不同场景下包含详细的业务，以上场景均从开源领域的各个方面支撑开源软件生态健康的可持续发展。同时为了保持开源软件生态健康的可持续发展，又可以导出开源软件生态的具体业务场景，再根据详细的业务场景探索具体任务的基准空间。在开源领域知识体系和具体业务场景驱动下，确定基准框架中的具体任务、任务类型、数据集、评价标准以及模型设计，则完成一个基准测试任务的构建。

意见14：本文标题夸大实际贡献。正如本文第7章所述，OpenPerf主要聚焦于数据科学相关的任务，并非整个开源社区所有任务，因此标题中应明确本文范围是“数据科学相关”。此外，标题中提及开源生态“可持续发展”，但纵观全文，审稿人并未发现对开源生态“可持续发展”的定义、说明或讨论，即本文没有回答什么是开源生态“可持续发展”，满足什么条件可以使开源生态“可持续发展”，所提出的方法如何使开源生态“可持续发展”。若无此类讨论，审稿人建议避免使用该类无实际意义的词汇

开源生态的可持续发展是指开源软件可以在长期内能够持续健康地发展和维护的状态。一个具有可持续发展的开源生态能够吸引、培养和维护社区参与者，同时保持项目的稳定性、可靠性和活跃性。为了使开源生态可持续健康的发展，当前关于开源生态的研究已经取得了部分成效，但由此所带来的一个重要问题就是缺乏相关的基准、 标注与评价规范，造成了一个“有数据无基准”的局面。一个开源项目处于怎样的发展位置、一个社区的健康成熟度达到了怎样的水平、企业开源程序办公能力处于行业什么位置、开发者贡献度、项目影响力等基础数据与评价，都是数据使用方迫切需要的开源领域知识。而这些都需要多方来共同开展研究与实践来形成一套与指标、数据相匹配的基准。 同时，我们也在6.3-6.5节中，以三个行业具体的应用为例，增加了关于OpenPerf如何使开源生态可持续发展的描述。以6.3节为例，蚂蚁集团 OSPO 开源治理大屏使用了 OpenPerf 中的影响力、活跃度、风险度等指数类基准，而这些指数类基准又通过“开源软件供应链风险预测”、“开源社区异常行为检测”等任务进行定义并产出最终数据。OpenPerf基准服务从宏观的角度分析集团下多个开源项目的发展现状，有效地量化不同项目的活跃度与影响力，为项目的可持续发展提供一定的参考。

看大家和王老师 @will-ww 这边有没有一些修改意见，争取下周提交修改稿。

[PureNatural]

针对二审返回的修改说明如下：

（1）意见1：文章对基准本身的介绍存在不清楚的地方。 补充意见：对不同任务的描述非常分散，建议用一个表格来列出主要的内容。

对意见（1）的修改说明： 感谢您提出的建议。我们在第4章的开头给出了一个关于基准测试任务的表格，列出了主要的内容，其中包含项目数量、输入、输出、标签来源和评价指标5项关键数据，并在表格下方对表格中的部分内容进行了必要的解释。 开源行为数据补全与预测、开源自动化机器人识别与分类和基于链路预测的开源项目推荐详细内容见第5章。

开发者的个人情绪在软件开发的过程中会影响生产效率、任务质量、工作满意度等，故本文将开源评论文本情绪分类任务作为基准测试任务之一，选取了GitHub star数排名前50的仓库，提取了2022年中这些项目的issue评论，对数据进行了预处理，移除了非英文评论，为了保证数据集的质量，由3名开源生态学研究方向的硕士研究生对长度不超过128的短评论文本进行打标签，得票高的情绪为该条数据的最终结果，在选择文本时尽量选择了带有明显情感词的评论，暂未考虑中性评论，最后产出5000条正向评论以及5000条负向评论数据。

开源软件供应链风险预测任务旨在通过量化软件供应链的各种风险（测试完整度、外部依赖度、团队健康度等9中风险指标），最终得出可维护性评分。通过实证分析的方式验证可维护性评分的有效性。

开源项目影响力排序任务通过对GitHub中2022年全域17万左右活跃项目进行获取，项目与项目之间通过开发者产生关联从而形成一个开源项目网络图，该图中包含了280多万条连边。该任务旨在通过高效的图排序算法对图中含有不同影响力值的开源项目进行排序。

---

（2）意见2：第4.3介绍的是情绪分类。这里Github的评论指的具体是什么？ 作者回复：我们选取了Github star数排名前50的仓库，提取了2022年中这些项目的issue评论，对数据进行了预处理，移除了非英文评论 补充意见：评论issue的大部分是开发者自己吗？这样的评论能反应项目的质量吗？

对意见（2）的修改说明： 感谢您的提问，根据参考文献[1-5]的描述, 开发者的个人情绪在软件开发的过程中会影响生产效率、任务质量、工作满意度等，以下研究多数通过对GitHub存在的issue评论、PR评论以及Commit评论文本等，挖掘开发者在软件开发过程中的情感，尽管GitHub作为一个开放的代码托管平台，任何人都可以在仓库下发表评论，多数研究者认为issue中的大多数评论都来源于开发者，故将其作为研究的一部分。

文章中并未说明issue评论能反应项目的质量，由于开发者的个人情绪在软件开发的过程中会影响生产效率、任务质量、工作满意度等，决策者可以通过平台中的消极评论及时做出反馈，从而使得项目健康的发展。因此本文将开源社区情绪分类作为数据科学类基准测试任务中的一项任务。

[1]Jurado F, Rodriguez P. Sentiment Analysis in monitoring software development processes: An exploratory case study on GitHub's project issues[J]. Journal of Systems and Software, 2015, 104: 82-89. [2]Fisher C D, Ashkanasy N M. The emerging role of emotions in work life: An introduction[J]. Journal of Organizational Behavior: The International Journal of Industrial, Occupational and Organizational Psychology and Behavior, 2000, 21(2): 123-129. [3]De Choudhury M, Counts S. Understanding affect in the workplace via social media[C]//Proceedings of the 2013 conference on Computer supported cooperative work. 2013: 303-316. [4]Venigalla A S M, Chimalakonda S. Understanding emotions of developer community towards software documentation[C]//2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering in Society (ICSE-SEIS). IEEE, 2021: 87-91. [5]Miller C, Cohen S, Klug D, et al. " Did you miss my comment or what?" understanding toxicity in open source discussions[C]//Proceedings of the 44th International Conference on Software Engineering. 2022: 710-722.

（3）意见5：没有OpenPerf。开发者和研究者也可以自己搜集这些数据。相比之下，OpenPerf带来的好处在哪里？ 1）作者回复：一个开源项目处于怎样的发展位置、一个社区的健康成熟度达到了怎样的水平、企业开源程序办公能力处于行业什么位置、开发者贡献度、项目影响力基础数据与评价，都是数据使用方迫切需要的开源领域知识。 补充意见：这些问题似乎不能通过OpenPerf来解决。

对意见（3）1）的修改说明： 感谢您的意见。本文在引言部分围绕本文的主要贡献，对该部分内容进行了更准确的描述，内容如下：

一个开源项目处于怎样的发展位置、企业开源程序办公能力处于行业什么位置、开发者活跃度、项目影响力等基础数据与评价，都是数据使用方迫切需要的开源领域知识。

其中“一个开源项目处于怎样的发展位置”，即对应本文中的“开源项目影响力排序”任务与“影响力基准”，通过影响力排序可以看出当前开源项目处于整个开源社区中的发展位置，具体应用对应本文6.3节“行业应用1：蚂蚁集团OSPO开源治理大屏”，该大屏已在蚂蚁集团开源办公室落地

“企业开源程序办公能力处于行业什么位置”，同样在“行业应用1：蚂蚁集团OSPO开源治理大屏”中能够体现蚂蚁开源办公室下的各个开源项目的发展情况，企业与企业之间的对比榜单见https://open-leaderboard.x-lab.info/,即6.2节中的“标杆类基准：OpenLeaderboard排行榜”，可以看出蚂蚁集团的排名相对靠前，即可以体现出该企业开源程序办公能力处于行业中的位置。

“开发者活跃度、项目影响力等基础数据”即本文提出的活跃度与影响力基准，可以衡量开发者和开源项目在某段时间内的活跃度与影响力，这两项基准被中国电子技术标准化研究院作为开源社区治理的评估标准，同时在蚂蚁，阿里，开放原子基金会，木兰开源社区，华东师范大学开源课程中均有使用。

综上，本文在OpenPerf的基准测试体系下，提出了多项基准，部分基准已经实际落地在了各个企业、组织和高校课程中，通过这些行业的实际应用，本文认为OpenPerf是实际解决了“一个开源项目处于怎样的发展位置、企业开源程序办公能力处于行业什么位置、开发者活跃度、项目影响力等基础数据与评价”这些问题的。

2）作者回复：而这些都需要多方来共同开展研究与实践来形成一套与指标、数据相匹配的基准。同时，针对开源领域的基准测试还处于初步探索阶段，开源领域数据类型的多样性、研究问题的广泛性以及协作网络的复杂性使得构建开源基准测试面临较大的挑战。 补充意见：OpenPerf是如何解决上述目标的？

对意见（3）2）的修改说明： 感谢您的提问。为了突出本文重点解决的问题，即“当前，关于开源生态的研究大多基于某一项具体的研究点展开分析而缺少对开源生态基准体系的构建，一个开源项目处于怎样的发展位置、企业开源程序办公能力处于行业什么位置、开发者活跃度、项目影响力等基础数据与评价，都是数据使用方迫切需要的开源领域知识”，故对引言部分的内容移除了“同时，针对开源领域的基准测试还处于初步探索阶段，开源领域数据类型的多样性、研究问题的广泛性以及协作网络的复杂性使得构建开源基准测试面临较大的挑战”的描述，重点落在形成一套与指标、数据相匹配的基准测试体系中。

“而这些都需要多方来共同开展研究与实践来形成一套与指标、数据相匹配的基准”即课题组成员通过获取GitHub全域协作行为数据，并基于该数据构建出全域协作行为网络，联合阿里、蚂蚁等国内知名企业以及木兰开源社区、开放原子基金会共同探索当下开源生态迫切需要解决的问题，课题组通过企业和社区的反馈情况结合现有的数据资源，提出一种面向开源生态可持续发展的基准测试体系，并以开源项目的形式发布基准测试服务，推动开源生态的持续发展。

（4）意见6： “开发者的行为数据表现出复杂的关联性和周期性特征”，“复杂的关联性和周期性”的具体体现是什么样的？此外，作者们还提到“这些复杂的特性使得传统的统计方法难以对开发者行为进行准确的预测和分析，开源运营者等更希望从统计指标来找到增强网络指标的方法”，“这些复杂的特性”指的是哪些特性？ 1）作者回复：关联性指表示开发者的行为之间存在一定的关系，可能是因果关系或者相关性。这种关系可能涉及到开发者在不同任务之间的相互影响，或者在某一任务中不同开发者之间的协作。例如，一个开发者的特定决策可能会影响到其他开发者的工作，或者某些任务的完成可能与其他任务的开展有关。 补充意见：开发者的决策是如何记录下来的？如何确定某一个决策影响到了其他开发者的工作？ 对意见（4）1）的修改说明： 感谢您的提问。在GitHub中开发者的决策通常通过Issues、Pull Requests、Discussions等方式记录下来。例如，在对Pull Requests审阅的过程中，项目维护者会对开发者提交的代码进行评价指导，使得该PR可以顺利的合入仓库中，若项目的维护者认为该PR质量较差，则可以拒绝合入，从而影响到开发者的工作[1-3]。此外，在Discussions中我们也可以大概浏览到项目近期的开发计划，即项目的维护者对该项目未来发展的一些决策，开发者们也可以根据这些决策完成自己感兴趣的任务。 根据评审给出的意见，作者已对文章进行大修，移除了关于数据科学基准测试任务的背景介绍，通过表格突出基准测试任务的重点内容。关于“开发者的行为数据表现出复杂的关联性和周期性特征”等内容，不在文章中体现。 [1]Dias K, Borba P, Barreto M. Understanding predictive factors for merge conflicts[J]. Information and Software Technology, 2020, 121: 106256. [2]Azeem M I, Panichella S, Di Sorbo A, et al. Action-based recommendation in pull-request development[C]//Proceedings of the International Conference on Software and System Processes. 2020: 115-124. [3]Li Z, Yu Y, Wang T, et al. Are you still working on this? An empirical study on pull request abandonment[J]. IEEE Transactions on Software Engineering, 2021, 48(6): 2173-2188.

2）作者回复：周期性特征：…… 补充意见：能举例一个具体的例子吗？

对意见（4）2）的修改说明： 感谢您的提问。这里的周期性特征即开源软件的开发日程与现实世界中的工作周期高度吻合，通常周期为1周，以Gitee平台中openHarmony项目为例，我们对该项目的日志事件数据进行统计，发现该项目在周一至周五的日志数据最多，周末较少，呈现成以周为周期的周期性特征，在5.1节“开源行为日志数据补全与预测”基准测试任务中，证明了考虑了该周期性特征的TAMF方法表现优于其他方法。

（5）论文题目是OpenPerf：面向开源生态...，什么是开源生态？建议在文章开始的引言部分有明确的论述，包括开源生态建设的价值和意义。 对意见（5）的修改说明： 感谢您给出的建议，我们已经修改了引言部分，添加了参考文献说明了开源生态的定义以及开源生态建设的价值和意义。内容如下： 开源生态是指由开源软件、开发者以及相关社区组成的一个生态系统[5-6]。该生态系统的核心是开源软件，它们的源代码是公开的，开发者们可以查看、修改和分发。当前，开源软件已经形成了一种全球化创新发展的生态系统, 其中大众参与的软件开发模式正逐步形成一种基于互联网的新型软件生产力, 并已在软件开发和应用的各个环节发挥了巨大作用，促进了技术的快速迭代和发展，推动技术的普及和应用[7-9]。开源生态的可持续发展是指开源软件可以在长期内能够持续健康地发展和维护的状态[10]。一个具有可持续发展的开源生态能够吸引、培养和维护社区参与者，同时保持项目的稳定性、可靠性和活跃性。为了使开源生态可持续健康的发展，较多来自学术界与工业界的研究者们采用数据驱动的研究范式对开源软件生态展开广泛研究，现有研究工作包括企业在开源生态中的合作关系[11]，GitHub软件生态系统演化过程研究[12-13]，开发者贡献研究[14-15]，开发者对开源项目的评论文本分析[16-19]等。

（6）另外，“面向开源生态可持续发展的'数据科学'基准测试体系”与“面向开源领域的基准测试体系”的关系需要在文章中进一步理清，并突出本文的重点以及本文成果的价值。

对意见（6）的修改说明： 感谢您给出的意见。这是我们表述的问题，现将前后文统一描述为“面向开源生态可持续发展的'数据科学'基准测试体系”，同时我们对引言内容进行大量的修改，突出本文的贡献即解决当前开源生态有数据无基准的问题，也对本文的主要贡献进行精简，形成3条核心贡献点。在第4章中移除了任务的背景描述内容，通过表格列出了基准测试的核心内容（输入、输出、评价指标、标签来源等）。主要修改内容如下：

当前关于开源生态的研究已经取得了部分成效，但由此所带来的一个重要问题就是缺乏相关的基准、标注与评价规范，造成了一个“有数据无基准”的局面。一个开源项目处于怎样的发展位置、企业开源程序办公能力处于行业什么位置、开发者活跃度、项目影响力等基础数据与评价，都是数据使用方迫切需要的开源领域知识。而这些都需要多方来共同开展研究与实践来形成一套与指标、数据相匹配的基准。针对上述问题，课题组成员通过获取GitHub全域协作行为数据，并基于该数据构建出全域协作行为网络，联合阿里、蚂蚁等国内知名企业以及木兰开源社区、开放原子基金会共同探索当下开源生态迫切需要解决的问题，课题组通过企业和社区的反馈情况结合现有的数据资源，提出一种面向开源生态可持续发展的基准测试体系。并以开源项目的形式发布基准测试服务，推动开源生态的持续发展。 本文的主要贡献如下： 1）基于现有的基准测试框架，提出一种面向开源生态可持续发展的基准测试体系。该体系自下而上主要包含数据科学任务类基准、指数类基准以及标杆类基准，旨在为开源生态中不同的研究方向提供基准参考。 2）在基准测试体系的引导下，定义了开源研究领域中的9个数据科学任务类基准，实现了3项典型的数据科学类基准测试（开源行为数据补全与预测、开源自动化机器人识别与分类、基于链路预测的开源项目推荐），2项指数类基准（影响力和活跃度）以及1项标杆类基准，并发布了详细评测实验结果。其中，中国电子技术标准化研究院将活跃度与影响力两项指数类基准作为开源社区治理的评估标准。 3）通过3个应用在阿里、蚂蚁以及华东师范大学等国内知名公司和高校的实际案例说明了 OpenPerf 在推动开源生态健康发展中所起到的关键作用。