🌳XSOSI 计划 11 月份数据

[will-ww]

接 XSOSI 计划

• 6 月份数据
• 7 月份数据
• 8 月份数据
• 9 月份数据
• 10 月份数据

11 月份数据新鲜出炉，感谢 @frank-zsy ~

本月继续在 Hypercrx 和 OpenDigger 的拉动下，整体继续有 12.3% 的增长，奖金池达到了 15500 ~

[frank-zsy]

根据 @xgdyp 的反馈 @longyanz 在 OpenDigger 中的贡献偏低，对 11 月份数据做了一些细化的分析，得到以下结论，也是引入 OpenRank 算法的一个优化点：

• @longyanz 不太习惯于在 GitHub 上协作，与 @xgdyp 的线下交流沟通较多，一般会形成线下共识后提交 PR，使得线上协作数据偏少
  • 这个需要大家注意，尽量公开协作，类似 ASF 提的没有在邮件列表中的事就是没发生过的，OpenRank 下没在 GitHub 上发生的事就是没发生的。
• 11 月中我这边修改了较多内容，如新的导出方法和导出数据格式的更新，领域数据的提交等，还有 @xgdyp 的 Python kernel 分离工作等，确实压缩了 @longyanz 的贡献。
• metric:new contributors open-digger#1038 该 PR 的价值较高，但由于我和 @xgdyp 也有大量的讨论，所以导致了最终 @longyanz 从中分到的价值并不高。由于我们使用的是类似活跃度的计算方式，open 2 分，comment 1 分，review 4 分的方式来分价值的，所以最终分配是我 44 分（63%）、 @longyanz 21 分（30%）、 @xgdyp 5 分（7%），这显然是不太合理的。
  • 提出一个新的优化点，即对于 Issue 和 PR，不再简单通过事件加权计数的方式来分配，而是作者首先获得一定比例的分配，剩余价值由其他人（包括作者）按照评论数量分配。例如，如果在上述 PR 中，作者 @longyanz 预先分得 50%，剩余 50% 由讨论的三人分配，则最终结果是 @longyanz 65%、我 31%、 @xgdyp 4%，应该是一个更加合理的方式。但目前 review 4、comment 1 的比例可能 review 的比例也过高。

看大家怎么看

[zhicheng-ning]

• 类似活跃度的计算方式，open 2 分，comment 1 分，review 4 分的方式来分价值的，所以最终分配是我 44 分（63%）、 @longyanz 21 分（30%）、 @xgdyp 5 分（7%）

个人认为目前的计算方式有待改进，对于 PR 作者来说，如果自己辛苦完成一个 PR之后获取的价值与其工作量不相匹配，显然会打击社区中开发者的积极性，期待更合理完善的计算方式~:smile:

[frank-zsy]

我个人建议是：PR 和 Issue 作者先分 50%，之后通过评论数量分配，review 的价值 4 分虽然较高，但其实也可以的，上面这个 PR 是因为我 review 了 3 个问题，但 @longyanz 没有回复直接直接关闭了 PR，后续又 reopen，导致我偏高，但如果她直接回复讨论的话，其实是相当的。

[zhicheng-ning]

但 @longyanz 没有回复直接直接关闭了 PR，后续又 reopen，导致我偏高，但如果她直接回复讨论的话，其实是相当的

reopen 是会导致 open 2 分 重复计算，所以 issue author 分数会更高，是这样吗

[will-ww]

创建者分配更高的比例，方向上没有问题。具体的一些细节和我们的一些操作行为规范也是相关的。OpenRank 的价值导向对开发者行为有非常好的教育意义。相信大家逐渐认识到以后，有了更规范与合理的行为，这样的分配也会更加合理，是一个正向驱动的闭环~

[frank-zsy]

reopen 是会导致 open 2 分 重复计算，所以 issue author 分数会更高，是这样吗

不会的，reopen 目前是不计入的，但 author 如果后续有 comment，也会再分 50% 中的一部分，所以如果有一个外部参与者，且两人的评论数相当，则最终作者会获得 75% 左右，另一个参与者大约 25% 左右。

[bifenglin]

首先关于活跃度策略评判我理解的是先活跃度成为一个初始值，然后再pagerank加权转移。活跃度的初始值是按不同事件类型统计加权。这有一些问题：

1. 若是直接通过push到代码仓库，事件有没有统计，
2. 在于一些开源项目，有完善的开发文档或者指导文档的情况下，一些讨论会全部留存在github中么？

一般从开发者角度来看一些问题确实通过及时通讯或者直接当面会议的方式会更方便，也是提升效率的一种，然后将结果存档留存，例如以代码或者文档的方式留存结果。这就导致了一些OpenRank的价值导向与一些开发者行为的理念导致冲突，因为一些开发者行为会将一些工程师自我的思想当导向，比如说工具是为了提升效率，而不是减少效率。

我们认为这个讨论的过程也是价值表现的一种，但是我认为每双周 @xgdyp 组织的opendigger会议也是一种很好的讨论价值，这个怎么算进去呢？

我这边有一些建议是可以XOSI可以提供一系列接口，可以自定义一些事件由项目维护者统计进去。比如说雨雀文档的数量和行数，腾讯会议的次数和发言时常。然后项目维护者对这些事件打分值标签，这是一个很有用的记录和实验。然后我们每个月通过项目各个事件的统计给维护者或者委员会共同打个排名，通过这些分值标签和排名就可以训练每个项目或者组织的权重，这些权重在项目中可以有占比，在全域数据中还是按之前的方案来划分影响力，在局部数据按标签学习的行为划分影响力我认为是一个很好的方式。

[bifenglin]

PS: @longyanz 的行为肯定是一大部分开发者的pattern，特别是刚加入项目的开发者。若是我们因为我们的价值而不考虑这些开发者的实际情况那么肯定会降低一部分新人开发者的参与兴趣。

[frank-zsy]

这也是为什么目前 OpenRank 叫做协作影响力的原因，因为只看 GitHub 上的协作数据，而不看其他的数据。所以：

• 直接 push 代码在正规开源社区是严格禁止的行为，这个是常识，因为直接 push 可以绕过 review 流程，可能引入错误，甚至可能导致某些开发者单独作恶。所以 push 不计入我认为是非常合适的。
• 不在 GitHub 上的行为不计入有两个原因：
  • 目前工程方案上还没有 ready 到可以任意的加入三方数据源，中间涉及的问题会很多，包括跨平台的账号 mapping，跨平台的数据采集和统计，数据模型上的一致性等等。
  • 更重要的是，类似 Apache 基金会提倡的没有在邮件列表中的事就是没发生过的，OpenRank 下没在 GitHub 上发生的事就是没发生的，我们是建议将所有工作都以数字化的形式沉淀到 GitHub，例如双周会 @xgdyp 和 @tyn1998 会各自在仓库中发起新的 Issue，就是一种沉淀，如果后续有视频上传到 B 站，他们再把视频链接以评论方式提交到对应 Issue 也是一种沉淀。而私下的交流虽然看起来更高效，但对于开源社区的发展是长期不利的，因为共识不是公开形成的，当然不应该计入工作量，就是要引导大家公开讨论，在开源社区中，慢才是快。对于这部分可以参考实验室新出版的书「Working in Public」，「开放式协作」。

长远而言，要引入外部数据是可以的，但我不确定目前是已经准备好的，一方面模型上大家是否能有共识，另一方面，例如腾讯会议的发言时长和次数目前如何统计？有接口吗？如何确认腾讯会议中的用户与 GitHub 开发者的对应关系？在外部有新人加入时如何快速匹配？都是需要考虑的。

[frank-zsy]

这种开发模式显然不是开源社区新人常见的模式，因为开源社区中的新人很难直接与核心维护者建立线下私人联系并进行讨论，以我给企业顶级开源项目做数据的经验，通常是新人因为过多在 GitHub 上提问而贡献偏高，反而不是偏低。

这种线下形成共识后再体现在线上是我们实验室的熟人环境下比较容易产生的情况，另外就是企业内部团队容易在内部会议形成共识后再同步给社区，这些都是目前 CTO、TL 级别严厉反对的行为，我看不出为什么需要去迎合这种行为，而不是引导大家尽量在线上协同？

[bifenglin]

这个外部的数据抽象成可以外部自定义的三个个对象，一个对象是meta数据，一个对象是score，一个对象是actor，由具备权限的人通过约定的形式输入进去，比如通过开一个issue输入，而不是直接跨平台mapping。

确实直接push代码在正规开源社区是禁止的，但是在小规模社区中存在开发者人员不足的情况下，意思是自己给自己review么？我之前研究github机器人行为，里面证实了一些自动化行为会降低开发人员的参与度，所以我这边想法是根据不同社区的不同程度制订不同的策略，而不是一概而论。这符合研究进程。

[bifenglin]

因为开源社区中的新人很难直接与核心维护者建立线下私人联系并进行讨论

新人遇见bug或者疑问一类的直接提交issue，一部分开发者遇见开发问题是去即时通讯工具 例如slakc或者钉钉。

[xgdyp]

我有个关于OpenDigger的小疑惑，我和 @longyanz 在实现指标的过程中，chaoss给出的定义其实很简略，更多地是从业务上的考量出发，而没有涉及到具体的细节上的实现，这也是我们所需要做的工作。这就引发了两个问题，一是我们在初步实现的过程中才会发现其中需要考量的一些问题，就比如我们昨天讨论的unresponsed issue的issue response time该如何设定。我们如果发现了这个问题就会立刻围绕此展开讨论，这里也的确是我们不足的地方，这也是在指标的定义阶段没有考虑到的事情。但是因为讨论的都是细节，如果采用异步的方式来做可能会使讨论的前后的认知成本提升很多，从而效率低很多（因为我的感觉是一天过去，之前的细节都忘了。。）；二是我认为在OpenDigger的指标实现中，我们没有一个规范，导致交流起来很困难（不仅是线上，在线下也一样），更别说要把解释不清的东西在用英文表达出来了，这个是我认为OpenDigger后续要改进的地方。
总的来说，我很认可Working In Public的导向，只是对我们来说还有很大的阻力来去做到这一点（表达能力、语言能力等），但是还是要不断去克服，去达到这个目标的。

[frank-zsy]

是的，我比较认可需要一个 metric 的实现流程，在流程中大家先讨论细节再开始实现，但我最害怕的是讨论细节在线下发生，英文的公开交流对大家都是挑战，我也是需要经常去翻译软件查询的，但我觉得这是必要的，而且是一个很好的训练过程。

[frank-zsy]

十一月的数据暂时不会再更新了~指标变更也需要一定的成本，短期内可能较难完成，会从十二月数据开始生效。

[will-ww]

十一月的数据暂时不会再更新了~指标变更也需要一定的成本，短期内可能较难完成，会从十二月数据开始生效。

好，那就以目前的情况安排发放了~ ------------------->

[frank-zsy]

OK~

[frank-zsy]

对于上面提到的 PR 如果作者先分 50%，后续其他人分 50%，那么结果会有如下变化

修改之前：

修改之后：

@longyanz 的分配价值会从 28% 增长到 59%，我的会从 49% 降低到 24%。

目前策略中，open 的开发者先分 50%，后续 comment 1 分，review 只占 2 分，close 占 1 分，然后大家按比例分配即可。而开发者向 Issue 和 PR 分配时，依然是 open 占 2 分的方式和其他所有事件统一统计分配，这与 Issue 和 PR 向外分配是不一致的。

[frank-zsy]

修改并全部重算后的结果是这样，较大提升了 Issue/PR 作者的权重。