will-ww
commented
2 months ago 谢谢 @huangfan0 给出的初步探索分析与思考，Vital nodes identication 和 Influence maximization 都是业界定义的非常完整的问题（相关论文可以参考这里），利用相关成果对开源生态数据分析会有很多好的点。不仅在验证 OpenRank，还能启发出很多相关问题。接下来，可以细粒度的把几件基础任务做好：
- 各种规模和类型的子图构建，形成更加丰富的基准数据集
- 利用开源协作中的特性，构建传播模型，合理的抽象既有益于问题求解，还能推动有效的实践落地
- 先把工程化全流程跑通（类似 MVP），结合包括 OpenDigger 开源项目一起来做，各种优化点可以随后再跟上
huangfan0
Description
1.实验结果
根据之前影响力最大化的思路，目前实现了一个比较粗粒度的实验，分别用独立级联模型（IC）、线性阈值模型(TL)和传染病模型(SIR)在我本地的一个协作网络图上对比了openrank与PageRank的结果图，发现OpenRank可以比PageRank多影响2000-5000个节点，初步验证了OpenRank的有效性。
1.数据：构建的数据是一个二部图，两种类型的节点：开发者(共43315个)和仓库（50000个）；5中类型的边：pr, issue, push, release 和folk。开发者和仓库节点都是影响力相对较高的节点。
2.初始激活节点的设置：发现激活种子节点比较大的时候，对比的传播规模的结果是更好的。开发者节点和仓库节点都选取前1万个节点时，最后的传播规模两则相差不大；当种子节点在2万-3万时，OpenRank明显要比PageRank要好。如图 独立级联模型：
线性阈值模型：（阈值选取节点的度，节点权重设置为OpenRnak 数值）
传染病SIR模型：
2.后续的研究计划
后续的实验应该要细粒度一些，目前想到的是从数据和模型两方面着手。
2.1. 数据：
①目前构建的是协作网络的子图，数据规模应该算中等，后续可以建立相同类型比较小规模和更大规模的子图上进行实验。
②协作关系只考虑了GitHub工作流的交互结构属性，只属于开发者和仓库的边，还想到仓库与仓库的关系（还没想好是什么关系），开发者与开发者的follow关系，（社交属性）但这个数据通过REST API请求。但是API请求总是遇到网络连接问题，验证了身份但还是请求的频率有限制，还不太清楚什么原因。 目前大多数研究是在开发者同质网络上找到有影响力的开发者，但如果考虑异质性就可以找到影响力的开发者的同时找到有影响力的仓库。
③其他类型的图数据结构。主要是节点和边的选择。我看到有论文把仓库下的文件也作为了一个节点来做建模。
2.2 模型
①现在只是用了三个现成的模型，应该还需要确定一个更细粒度的传播算法。 参考The Nodes Influence Maximization in OpenSource Software Community Basedon Probability Propagation Model这篇论文，核心创新点在于1.开发者follow网络在一个节点激活另外一个节点时，引入了激活概率，这个概率是通过star，folk和pull request 的次数加权处理得到。2.映入了一个算法（SIUF）选取种子激活节点（类比于OpenRank算法的位置） 想映入异质图上的传播激活概率来解决数据的异质性，具体怎么确定传播概率还没想清楚，这需要实验验证最后的传播规模更大才有效。
②初始种子激活节点的选择，也可以不一定全部按OpenRank的排名前多少的节点作为种子节点，因为OpenRank反应的是协作的结构关系，可不可以还同时考虑节点自身的属性，如开发者的following数量，仓库的star数量，最后与OpenRank做加权求和？
③另外，OpenRank的优势本来具有动态的时间连续性，因为它继承了上个月的结果，所以想从时间的角度去分析开发者或仓库的动态演化过程，具体方法还没有想好。