-
Notifications
You must be signed in to change notification settings - Fork 10
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
Comments
OpenRank 作为一个系列算法,目前主要应用为两个方面: 目前这两类算法的应用主要是: 事实上上述 2、3 之间的关系容易导致混淆,这种混淆类似于社区 OpenRank 中仓库的结果(或所有 Issue、PR 的影响力之和)与仓库全域影响力的关系。仓库的影响力只用 1 的结果应该是毫无疑问的,而对于开发者而言,如果我们区分影响力和贡献度,那么 2 和 3 是可以共存的。 影响力是通过开发者在不同仓库中的活跃得到的,影响力越高的开发者他们在全域更加活跃,而且更加倾向于在不同的仓库上进行协作,因此他们对开源生态的繁荣起到重要的作用。 而贡献度是开发者在不同影响力的仓库中贡献比例的总和,与影响力不同,贡献度并不关心一个开发者是否在很多不同的仓库中协作,而是看开发者在特定仓库中的贡献比例,例如某些开发者只在一些重要的项目中长期活跃,那么由于他们不会在很多仓库中协同,他们的影响力并不会很高,但由于他们在影响力大的项目中贡献比例高,因此他们的贡献度可能很高。 综上所述,作为人才评价的方案,我认为贡献度是更加合理的,针对学生而言,我们并不希望他们泛泛的参与很多的项目,而是希望他们可以参与或发起有影响力的项目,并在其中有较明显的贡献。甚至长远而言,也希望可以用贡献度来替代开发者的全域影响力,因为开源码力榜也更加适合用贡献度来评价。 |
按照上述思路,我们在每月计算仓库全域 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 万人,按照这个基数,我们可以给上述几个档位划分大致比例:
按照 2024.7 数据,根据贡献当量计算上述几个点位值,同时设置 b 值,即取消认证值为 0.8a,则结果大约为:
相对应,可参考的 2024.7 的几个点例:
以上为一个完整的纯基于 OpenRank 的贡献度人才评价的方案,再次基础之上还可以进一步做一些细化工作,例如对开发者的画像做进一步的完善,如使用的语言、擅长的项目领域、协作特征等,作为一个补充。 |
支持!“以后对外就一致了,项目就是影响力,开发者就是贡献度,就不变了” |
@frank-zsy 您好,非常感谢您分享这些深入的思考!在阅读完您的描述后,我有几个疑问想请教下: 1.开发者影响力与贡献度的区分: 2.OpenRank与全域影响力: 3.贡献度计算方法: |
@zhingoll 抱歉,回复晚了。 1、可以这样理解的。事实上在计算全域影响力时,不仅考虑开发者的协作广度,同样也考虑在每个仓库的活跃强度,但这里的关联不使用贡献度来度量,而是使用各项协作行为的加权和来构造,因此和贡献度会有差异。但这样的构造下,事实上开发者不仅要考虑协作广度,在高影响力仓库中,他们需要有高度活跃才可以增加自己的影响力,否则他们从高影响力仓库中可以分得的影响力也是极为有限的,并不能仅通过在大量仓库中浅尝辄止来获得高的全域影响力。 2、全域影响力这里很多人会有疑惑,因为仅考虑协作关系的情况下确实难以说这就可以表示影响力。但事实上这里叫做影响力只是因为在图论中,类似 PageRank 的这类中心向量中心性算法的结果也被称为影响力,所以这里借用了这个词。如你所说,真实的影响力还要考虑其他的各项因素,尤其是例如项目在真实世界的使用情况,这也是我们希望支持的,但目前在数据上较难支撑这样的做法。 3、贡献度的计算有两个阶段。第一阶段是每个仓库内部独立计算的,最终的开发者贡献度仅与这个仓库中的活动有关,而与全域的影响力无关。第二阶段是如果多仓库之间的开发者贡献度需要横向比较,或者需要统计开发者在全域的贡献度时,就会引入仓库的全域影响力。但此时并不是直接使用开发者的仓库 OpenRank 值乘以仓库的全域 OpenRank 值,而是使用开发者在该仓库的贡献比例乘以仓库的全域 OpenRank 值,也就说该仓库上所有开发者的贡献度之和等于该仓库的全域 OpenRank 值。在这种情况下,在较高 OpenRank 仓库中的较小贡献并不会获得很高的全局贡献度,因为仓库的全域影响力虽然较高,但会被所有仓库中的开发者瓜分,而核心贡献者会拿走绝大多数的贡献度,因此不一定会比主导较小全域影响力的开发者贡献度高。这里具体比较起来如何,可能需要针对一些具体的数据案例来做分析了。 |
@frank-zsy 没关系,非常感谢你的详细解释。 |
@zhingoll 整体没有太大问题的,不过目前对外的话基本口径都是仓库看影响力,开发者看贡献度的,所以阿里贡献者排行榜、OpenLeaderboard、开源码力榜中的开发者榜单现在已经全部统一为全域贡献度了,开发者影响力目前不做透出 |
明白了~ |
结合本次 CCF 开源软件通识导教班的成功举办,以及开放原子开源基金会的协同推动,工信部拟策划将 OpenRank 贡献度评价,在部属的国防七子(7 所高校),以及工信部与教育部联合建设的首批特色化示范性软件学院(33 所高校)中,进行试点与推广工作。
国防七子(7 所高校)包括:
首批特色化示范性软件学院(33 所高校)包括:
为此,接下来我们需要做三件事情:
同时,我们也欢迎与鼓励更多的高校和老师加入到试点中来~
The text was updated successfully, but these errors were encountered: