团队创建之初，最重要的是需要有共同的愿景，一致的共识。

    去年 Comunion 组建了开发者委员会，确定了核心成员，也为日后的组织治理定下了基调。

    本次会议的目的是为了讨论 V4 版本及重构版本的 UVU 分配，在此之前确实有分配不透明的问题，那么为什么直到 V4 版本才提上议程呢？主要原因有以下几点:
    1.V1 版本，团队刚刚组建，还没有治理的概念；
    2.V2 版本，从初始团队中进一步确定了核心开发者，核心团队初步形成；
    3.V3 版本，组建开发者委员会，以不同功能模块具体功能进行百分比分配实验。

    经过 V3 版本的实验后，按版本功能进行整体分配的原则是可行的。为提升组织治理，加强核心团队共识，激励透明化，特此召开 Governance 会议。

    与会的 Governance 分配委员分别为：Kering、Uta、泽辉、Nigel、前尘、二锅、Lever。

    根据 Comunion 整体发展进度计算，V4 版本的整体分配为400W UVU（含后端重构），将由产品组，前端组，合约组，Voice组 及组织建设组共同分配。

    这是 Comunion 第一次向组织治理迈出的第一步，每位委员就 V4 版本自身代表模块讨论具体分配。由于涉及到各部分的具体分配，在会议过程中可以明显看到各位委员并不是很放的开。

    用二锅的话来说，作为前端委员，其负责整个前端的任务、人员、激励分配。从具体模块来说，他应该争取更多分配，但作为开发者委员，又希望分配更加平均，所以有些矛盾。

    这个问题其实在中心化公司中很常见，估计当时很多委员心中也有这个想法。Kering 专门进行了说明：从个人心理来说，这是无可厚非的，但是我们还是要站在一个更高的角度去审视。对于开发者来说，真正的激励并不是多分配一些 UVU ，而是其从这种模式中获得的方式、方法。现在很多开发者是在参与 Comunion 建设，当有一天这些开发者能利用这些学到的方式、方法去构建属于自己的公司、组织，才是真正的财富。

    随着各位委员不断说出心里的想法，不断探讨各模块现存以及以后会浮现的问题，大家的视野也在逐渐放开，逐渐从自身代表的模块中跳脱出来，以全局性的眼光去综合审视自己代表模块的功能。

    当然，具体的分配过程也是比较粗糙的，更多是以头脑风暴的形式确定，也参考了之前 V3 版本的一些分配。具体分配比例如下：

    • 组织建设 2%
    • Voice 10%
    • 浮动 8%
    • V4 40%-(V4上线+bug修复，稳定版): 15%产品+设计 :30%前端 : 25%后端 ：20%合约 - 10%浮动 （浮动部分由 泽辉 进行具体再分配）

    • 重构40%:（具体分配由 Nigel 根据时间点再分配）账号：后端本身替换，前端+后端 yapi替换，欠的需求，Startup 和钱包绑定的V3，合约确认上链机制


      由于具体的开发过程中会出现很多不可预测因素，并且本次涉及到后端重构，因此留出了很多浮动分配。

      值得一提的是，随着 Comunion 的壮大，必然会有很多新成员加入，而各位委员更多的是作为 Mentor 的角色存在，为了培养更多开发者，扩展组织，为鼓励委员把任务多分给新人，特以提前为各位 Mentor 按比例进行了预留。

      原定于1小时的会议，结果最终进行了2个半小时，虽然过程与结果比较粗糙，但各位核心成员达成了一致的激励共识，这样保证了在 V4 版本开发过程中，不会因为分配不均的问题而引发共识问题。当在实际开发过程中遇到的问题，将由各位委员进行记录，在之后的版本中进行修正。

      一致的共识，是核心团队能够正常运转的前提，核心团队的稳定，组织才有机会迸发出更多的生命力。