Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenRank 贡献度评价在国防七子与特色软件学院推广计划 #426

Open
will-ww opened this issue Aug 18, 2024 · 8 comments
Open

Comments

@will-ww
Copy link
Contributor

will-ww commented Aug 18, 2024

结合本次 CCF 开源软件通识导教班的成功举办,以及开放原子开源基金会的协同推动,工信部拟策划将 OpenRank 贡献度评价,在部属的国防七子(7 所高校),以及工信部与教育部联合建设的首批特色化示范性软件学院(33 所高校)中,进行试点与推广工作。

国防七子(7 所高校)包括:

  • 哈尔滨工业大学
  • 北京航空航天大学
  • 西北工业大学
  • 北京理工大学
  • 哈尔滨工程大学
  • 南京航空航天大学
  • 南京理工大学

首批特色化示范性软件学院(33 所高校)包括:

学校 学院 方向
北京大学 软件与微电子学院 关键基础软件
清华大学 软件学院 关键基础软件 大型工业软件
北京交通大学 软件学院 行业应用软件
北京航空航天大学 软件学院 关键基础软件 大型工业软件
北京理工大学 软件学院 关键基础软件 行业应用软件
北京邮电大学 计算机学院 新型平台软件 嵌入式软件
天津大学 智能与计算学部 关键基础软件 新型平台软件
大连理工大学 软件学院 大型工业软件 嵌入式软件
东北大学 软件学院 行业应用软件
吉林大学 软件学院 行业应用软件
哈尔滨工业大学 软件学院 大型工业软件 行业应用软件
哈尔滨工程大学 软件学院 大型工业软件
复旦大学 软件学院 新型平台软件
同济大学 软件学院 行业应用软件 嵌入式软件
上海交通大学 电子信息与电气工程学院 关键基础软件
华东师范大学 软件工程学院 大型工业软件 嵌入式软件
南京大学 软件学院 关键基础软件 行业应用软件
苏州大学 计算机科学与技术学院 大型工业软件
南京航空航天大学 计算机科学与技术学院 嵌入式软件
浙江大学 软件学院 关键基础软件 新型平台软件
中国科学技术大学 软件学院 新型平台软件 嵌入式软件
厦门大学 信息学院 嵌入式软件
山东大学 软件学院 大型工业软件
中国石油大学(华东) 青岛软件学院 大型工业软件
武汉大学 计算机学院 行业应用软件 新型平台软件
湖南大学 信息科学与工程学院 大型工业软件
重庆大学 大数据与软件学院 行业应用软件
中南大学 计算机学院 大型工业软件 行业应用软件
电子科技大学 信息与软件工程学院 大型工业软件 嵌入式软件
西安交通大学 电信学部 大型工业软件
西北工业大学 软件学院 大型工业软件
西安电子科技大学 计算机科学与技术学院 关键基础软件 嵌入式软件
国防科技大学 计算机学院 关键基础软件

为此,接下来我们需要做三件事情:

  • 开放原子开源基金会的 OpenAtomDashboard 大屏的详细讲解与解读文档(韩、彭)
  • 基于开源贡献评价的工程教育改革与试点方案(王、赵)
  • 基于开源贡献度量的特色软件工程教育评价改革(PPT)撰写(王、赵)

同时,我们也欢迎与鼓励更多的高校和老师加入到试点中来~

@frank-zsy
Copy link

frank-zsy commented Aug 31, 2024

OpenRank 作为一个系列算法,目前主要应用为两个方面:
1、基于开发者-仓库级别的全域协作网络下的协作影响力评价
2、基于开发者-协作单元(Issue, PR)-仓库的单仓协作网络下的贡献度评价

目前这两类算法的应用主要是:
1、全域协作影响力中仓库结果几乎已成为各类项目影响力评价的基础,在此基础之上可以得到项目群、企业、基金会、国家等各类与仓库聚合相关的结果。
2、全域协作影响力中开发者结果除在 OpenLeaderboard 展示外,目前主要用于开源码力榜的结果展示。
3、贡献度评价结合仓库全域影响力结果,可用于多仓跨仓中的总体贡献度度量,用于阿里开源贡献者排行榜等。

事实上上述 2、3 之间的关系容易导致混淆,这种混淆类似于社区 OpenRank 中仓库的结果(或所有 Issue、PR 的影响力之和)与仓库全域影响力的关系。仓库的影响力只用 1 的结果应该是毫无疑问的,而对于开发者而言,如果我们区分影响力和贡献度,那么 2 和 3 是可以共存的。

影响力是通过开发者在不同仓库中的活跃得到的,影响力越高的开发者他们在全域更加活跃,而且更加倾向于在不同的仓库上进行协作,因此他们对开源生态的繁荣起到重要的作用。

而贡献度是开发者在不同影响力的仓库中贡献比例的总和,与影响力不同,贡献度并不关心一个开发者是否在很多不同的仓库中协作,而是看开发者在特定仓库中的贡献比例,例如某些开发者只在一些重要的项目中长期活跃,那么由于他们不会在很多仓库中协同,他们的影响力并不会很高,但由于他们在影响力大的项目中贡献比例高,因此他们的贡献度可能很高。

综上所述,作为人才评价的方案,我认为贡献度是更加合理的,针对学生而言,我们并不希望他们泛泛的参与很多的项目,而是希望他们可以参与或发起有影响力的项目,并在其中有较明显的贡献。甚至长远而言,也希望可以用贡献度来替代开发者的全域影响力,因为开源码力榜也更加适合用贡献度来评价。

@frank-zsy
Copy link

按照上述思路,我们在每月计算仓库全域 OpenRank 与主要仓库社区 OpenRank 后,即可进一步计算所有开发者在全域的仓库中的贡献度,从而获得一个开发者在当月的开源世界中的贡献度,并以此为依据进行人才评定。

可以考虑分档的方式来进行评定,即根据全球评分的分布进行不同档位划分。同时这个评定应该是动态的,即一个开发者最终是否得到该档位的认证取决于其最近一段时间的贡献度,如果一个获得某档位评定的开发者不再活跃,应适时取消或修改认证。

由此开发者的评定不应仅取决于当月的情况,而是最近一段时间的贡献度,例如最近 3 个月或 6 个月,并且此时可以使用例如指数移动平均的方法来获取最终值,即最近的月份的权重较高,向前月份的权重是指数级下降的。

举例:假设某档位的基础评分要求为 a,则某开发者在最近一段时间内贡献度的指数移动平均值达到 a 时即自动获得该档位认证。若之后该开发者的贡献度开始下降,则当其某月的移动指数平均贡献度下降到 b 时则自动取消该档位认证。这里的 b 应该与 a 相关,例如 0.5a 或 0.8a。这里不使用 a 作为取消界限是防止因为行为的简单波动导致在一段时间内频繁获得和失去该档位认证。

之后我们需要做的事情是设定多个档位,并根据全球贡献度的分布情况来确定档位对应的 a 值,以及 b 值与 a 值的关系。

下面举个实例:

算法

贡献当量:定义一个开发者在某月的开源贡献当量为该开发者在最近 3 个月在开源中贡献度的指数移动平均值,参数选为 0.7。则此时贡献当量 c=0.7c_1+0.21c_2+0.09c_3,即当月贡献量权重 70%,上月权重 21%,上上月权重 9%。

档位划分

根据开发者贡献当量,可以划分如下档位:

  • 引领者:在开源世界中引领潮流,担任核心贡献者或协调大型项目群,具有显著影响力。
  • 开拓者:开辟新领域,紧随引领者的步伐,在重要项目的研发和创新中发挥关键作用。
  • 贡献者:广泛参与项目,提供重要贡献或拓展早期开源项目的开发者。
  • 参与者:以较低的活跃度参与开源项目,贡献相对有限。
  • 观察者:在开源世界中参与度较低,主要处于观望状态。

确定档位分值

根据上述档位划分,我们可以进一步来确定具体档位的分值,此处需要考虑到全域的贡献度分布情况,我们可以设定一个大致的比例。2024.7 中,GitHub、Gitee 全域有 Issue、PR 活跃的开发者总量是 116 万人,按照这个基数,我们可以给上述几个档位划分大致比例:

  • 引领者:Top 0.1%,约 1160 人
  • 开拓者:Top 3%,约 3.4 万人
  • 贡献者:Top 10%,约 8.1 万人
  • 参与者:Top 30%,约 23.2 万人
  • 观察者:其他,约 81.2 万人

按照 2024.7 数据,根据贡献当量计算上述几个点位值,同时设置 b 值,即取消认证值为 0.8a,则结果大约为:

  • 引领者:25.2,20.16
  • 开拓者:3.6,2.88
  • 贡献者:1.2,0.96
  • 参与者:0.06,0.048
  • 观察者:0,-

相对应,可参考的 2024.7 的几个点例:

  • 全球第一,home-assistant 社区 frenck,贡献度 198
  • 全球100,前微软工程师 erictraut,贡献度 55
  • 中国第一,chenjiahan,贡献度 78
  • 中国100,FASTSHIFT,贡献度 15
  • 尤雨溪 贡献度 23,吴晟、tison 贡献度 18
  • 王老师 贡献度 4.9,Frank 贡献度 6.2

以上为一个完整的纯基于 OpenRank 的贡献度人才评价的方案,再次基础之上还可以进一步做一些细化工作,例如对开发者的画像做进一步的完善,如使用的语言、擅长的项目领域、协作特征等,作为一个补充。

@will-ww
Copy link
Contributor Author

will-ww commented Sep 1, 2024

支持!“以后对外就一致了,项目就是影响力,开发者就是贡献度,就不变了”

@zhingoll
Copy link

zhingoll commented Sep 6, 2024

OpenRank 作为一个系列算法,目前主要应用为两个方面: 1、基于开发者-仓库级别的全域协作网络下的协作影响力评价 2、基于开发者-协作单元(Issue, PR)-仓库的单仓协作网络下的贡献度评价

目前这两类算法的应用主要是: 1、全域协作影响力中仓库结果几乎已成为各类项目影响力评价的基础,在此基础之上可以得到项目群、企业、基金会、国家等各类与仓库聚合相关的结果。 2、全域协作影响力中开发者结果除在 OpenLeaderboard 展示外,目前主要用于开源码力榜的结果展示。 3、贡献度评价结合仓库全域影响力结果,可用于多仓跨仓中的总体贡献度度量,用于阿里开源贡献者排行榜等。

事实上上述 2、3 之间的关系容易导致混淆,这种混淆类似于社区 OpenRank 中仓库的结果(或所有 Issue、PR 的影响力之和)与仓库全域影响力的关系。仓库的影响力只用 1 的结果应该是毫无疑问的,而对于开发者而言,如果我们区分影响力和贡献度,那么 2 和 3 是可以共存的。

影响力是通过开发者在不同仓库中的活跃得到的,影响力越高的开发者他们在全域更加活跃,而且更加倾向于在不同的仓库上进行协作,因此他们对开源生态的繁荣起到重要的作用。

而贡献度是开发者在不同影响力的仓库中贡献比例的总和,与影响力不同,贡献度并不关心一个开发者是否在很多不同的仓库中协作,而是看开发者在特定仓库中的贡献比例,例如某些开发者只在一些重要的项目中长期活跃,那么由于他们不会在很多仓库中协同,他们的影响力并不会很高,但由于他们在影响力大的项目中贡献比例高,因此他们的贡献度可能很高。

综上所述,作为人才评价的方案,我认为贡献度是更加合理的,针对学生而言,我们并不希望他们泛泛的参与很多的项目,而是希望他们可以参与或发起有影响力的项目,并在其中有较明显的贡献。甚至长远而言,也希望可以用贡献度来替代开发者的全域影响力,因为开源码力榜也更加适合用贡献度来评价。

@frank-zsy 您好,非常感谢您分享这些深入的思考!在阅读完您的描述后,我有几个疑问想请教下:

1.开发者影响力与贡献度的区分:
关于开发者影响力和贡献度的区分(如果可以区分的话),请问是否可以这样理解:影响力主要侧重于开发者在开源世界全域的协作广度,显示他们如何在整个开源世界中活跃(这里的“活跃”是否也是基于开发者在仓库中的贡献行为定义的?);而贡献度则侧重于他们在特定社区或项目中的深度贡献,具体反映了他们在特定环境下的作用和影响。它们代表了衡量开发者在全域和局部层面的不同属性,这样理解对吗?

2.OpenRank与全域影响力:
作为基于PageRank的中心性算法,OpenRank自身应该可以衡量开发者在整个开源世界的影响力大小,开发者的全域影响力是否可以直接等同于他们的全域OpenRank值?有这样的疑问是因为:有一个可能的场景,当某个开发者深耕于某个影响力很高(比如热门、OpenRank值高)的项目时,他/她虽然没有参与很多其他项目,但是由于他/她深耕的这个项目有很多人使用,并且由于这个项目人气很高,有许多开发者也加入其中,和他/她共同进行了协作贡献。那么从“影响力”这个词的视角来看,他/她也可以影响很多人(不论是项目的使用者还是其他开发者)。所以我在想影响力是否一定需要考虑协作广度(开发者参与仓库的多样性)
(一点小想法:如果需要将开发者的协作广度纳入考虑来评估开发者的影响力,可能需要在全域OpenRank的基础上加入评估节点链接多样性的指标,以形成一个单独的、更全面的开发者影响力衡量指标可能比较合适。)

3.贡献度计算方法:
关于开发者贡献度的计算,是否是这样定义的:开发者在特定仓库的OpenRank值乘以该仓库的全域OpenRank值(这可能需要通过归一化或其他方法调整为适当的权重)?如果这样,在第二个疑问成立的前提下,似乎那些全域影响力高的开发者的贡献度也不会低,因为贡献度计算一定程度上已经整合了全域信息(来自仓库的全域OpenRank值)。例如,当某开发者在OpenRank值高的仓库内即使只做出较小的贡献(与仓库内其他开发者相比),也可能获得较高的贡献度。在这种情况下(开发者的全域影响力不考虑协作广度),似乎可以不需要将开发者的贡献度与影响力分开讨论?

@frank-zsy
Copy link

@zhingoll 抱歉,回复晚了。

1、可以这样理解的。事实上在计算全域影响力时,不仅考虑开发者的协作广度,同样也考虑在每个仓库的活跃强度,但这里的关联不使用贡献度来度量,而是使用各项协作行为的加权和来构造,因此和贡献度会有差异。但这样的构造下,事实上开发者不仅要考虑协作广度,在高影响力仓库中,他们需要有高度活跃才可以增加自己的影响力,否则他们从高影响力仓库中可以分得的影响力也是极为有限的,并不能仅通过在大量仓库中浅尝辄止来获得高的全域影响力。

2、全域影响力这里很多人会有疑惑,因为仅考虑协作关系的情况下确实难以说这就可以表示影响力。但事实上这里叫做影响力只是因为在图论中,类似 PageRank 的这类中心向量中心性算法的结果也被称为影响力,所以这里借用了这个词。如你所说,真实的影响力还要考虑其他的各项因素,尤其是例如项目在真实世界的使用情况,这也是我们希望支持的,但目前在数据上较难支撑这样的做法。

3、贡献度的计算有两个阶段。第一阶段是每个仓库内部独立计算的,最终的开发者贡献度仅与这个仓库中的活动有关,而与全域的影响力无关。第二阶段是如果多仓库之间的开发者贡献度需要横向比较,或者需要统计开发者在全域的贡献度时,就会引入仓库的全域影响力。但此时并不是直接使用开发者的仓库 OpenRank 值乘以仓库的全域 OpenRank 值,而是使用开发者在该仓库的贡献比例乘以仓库的全域 OpenRank 值,也就说该仓库上所有开发者的贡献度之和等于该仓库的全域 OpenRank 值。在这种情况下,在较高 OpenRank 仓库中的较小贡献并不会获得很高的全局贡献度,因为仓库的全域影响力虽然较高,但会被所有仓库中的开发者瓜分,而核心贡献者会拿走绝大多数的贡献度,因此不一定会比主导较小全域影响力的开发者贡献度高。这里具体比较起来如何,可能需要针对一些具体的数据案例来做分析了。

@zhingoll
Copy link

@frank-zsy 没关系,非常感谢你的详细解释。
结合之前关于影响力和贡献度的讨论,我根据自己的理解,尝试整理了一张图来展示这俩概念的差异。请问下这张图是否能正确反映目前开发者的全域影响力全域贡献度的计算过程?
image

@frank-zsy
Copy link

@zhingoll 整体没有太大问题的,不过目前对外的话基本口径都是仓库看影响力,开发者看贡献度的,所以阿里贡献者排行榜、OpenLeaderboard、开源码力榜中的开发者榜单现在已经全部统一为全域贡献度了,开发者影响力目前不做透出

@zhingoll
Copy link

@zhingoll 整体没有太大问题的,不过目前对外的话基本口径都是仓库看影响力,开发者看贡献度的,所以阿里贡献者排行榜、OpenLeaderboard、开源码力榜中的开发者榜单现在已经全部统一为全域贡献度了,开发者影响力目前不做透出

明白了~

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants