search

mosn / layotto

A fast and efficient cloud native application runtime
http://mosn.io/layotto/
Apache License 2.0
817 stars 168 forks source link

Community Governance Proposal #167

Closed seeflood closed 2 years ago

seeflood commented 3 years ago

前言

Layotto刚刚发布了第一个版本，社区各位同学做出了很多贡献。为了回报大家的努力，最好的方式就是把社区越做越大（毕竟大家都希望自己写的代码对世界产生更大的影响力，而不仅仅是一两个公司的自high项目)

那么怎么才能把社区做大呢？其中一件能做的事情就是制定好的社区规则。个人理解，好的社区规则要足够透明、开放，允许每个感兴趣的人加入、提建议、参与决策；好的社区规则要让大家能看到投入后的回报，回报有很多种，例如学到感兴趣的知识，实践感兴趣的技术，获得更酷的荣誉 title，获得社区影响力，自己写的代码跑在很多公司的机器上从而获得成就感，成为社区的决策者，获得求职时的亮眼项目履历，参与社区活动获得奖品IDE License……

Layotto 是 MOSN 社区的项目，而 SOFAStack 社区和 MOSN 社区之前用的都是同一套组织架构（如果我理解的不对请指正哈），针对过去的一些问题，本草案试着对规则提出一些变化，希望调动大家积极性，让项目 owner 觉得是在为个人爱好/个人荣誉而参与社区，让每个感兴趣的技术同学都能参与到社区核心决策中，学到自己感兴趣的知识、做自己感兴趣的项目，成为项目的决策者之一，and finally impact the world!

目前 SOFAStack 组织架构

https://www.sofastack.tech/community/

image.png

存在的问题

  1. 虽有 User Group 但活跃度不足
  2. Contributor 晋升路线过长、模糊
  3. 项目 owner 投入开源的时间有限（加班多，也没办法……）、动力不足（最直接的表现是，离职或转岗后缺少继续贡献社区的动力）

v2.0 草案

image

新增角色用红色标识。 解释：

1. Title 社区化：所有社区 title、权限和参与者所属公司无关

此条为了调动大家积极性，让项目 owner 觉得是为了个人爱好/个人荣誉而参与社区，不管去哪家公司都还是SOFAStack PMC member/Co-founder; 让每个感兴趣的技术同学都能参与到社区核心决策中，促进社区活跃

Co-founder（项目创始人）终身荣誉制

作为终身荣誉，但没有实权。比如某位开发者创建了项目A，多年后即使他不再参与社区维护、辗转跳槽多家公司，经历了风风雨雨、起起落落，决定转行不做程序员了、开了家火锅店，他也依然是项目A的 Co-founder

PMC(Project Management Committee) member

PMC member 作为项目核心管理团队，有项目的决策权，和所属公司无关，仅看社区活跃度。比如，某 Co-founder 如果多年不参与社区维护，就不再是PMC member了。比如某位编程爱好者主业是火锅店老板、不是程序员，只要他对项目的贡献足够，他也可以是PMC member。至于如何成为 PMC member，见下面的晋升规则

欢迎各位项目 owner 给自己和其他人发 title

只有让项目 owner 和社区贡献者有动力持续维护，社区才会越做越大，因此欢迎大家给自己和其他人发 title，不需要谦虚。

​

2. 社区晋升规则：透明、让大家能看到确定性回报

Active Contributor 和 Reviewer

Active Contributor 是一年贡献超过xxx 个 PR 的 Contributor。（每个项目自己定） Reviewer 从 Active Contributor 中诞生，具有 Review PR 的义务，并且对某个项目/模块的 PR 的点赞（LGTM）有效。 ​

Core Team 核心开发者团队

SOFAStack & MOSN 社区的每个项目可以拉个独立的核心团队群(钉钉/微信都行)。 Core Team 负责某个项目的开发和维护工作，对代码的质量负责。 我们将邀请 Active Contributor 加入Core Team，开发者们将在 Core Team 中获得其他开发者的持续帮助、交流，一边锻炼技术能力，一边优化和完善项目。社区开发者们可通过 Core Team 逐渐从初始的 Active Contributor 成长为受到社区认可的 Reviewer、Committer 和 PMC member。 一般而言每个专项兴趣小组都会周期性的组织会议，讨论最近进展和遇到的问题，所有的会议讨论都公开在社区上，方便感兴趣的同学一起参与和讨论。 ​

注：此项设计参考了Tidb社区的 Special Interest Group

完善社区成员晋级的规则、指导机制

社区成员做出怎样的贡献后可以晋级？要有透明、具体的规则，让社区同学从 Contributor 成长到 Committer 或 Maintainer 有路可循，让大家觉得“投入就一定有回报” 具体晋升机制由每个项目的 Core Team 讨论决定

3.决策社区化

评审社区化：需求和技术方案公开评审

重要需求的评审、技术方案的评审应该在社区内以开放的方式做评审，而不是蚂蚁员工开内部评审会 例如要做技术方案评审时，社区成员可以在自己的用户群或者 Core Team 群里组织线上会议、开直播，允许每一个感兴趣的人观看、参与。如果觉得直播太重，issue 区发 proposal 也行。 ​

否则，试想：某项目 owner 离开蚂蚁后，虽然他是 PMC member，但是方案评审都不带他，他还会有动力继续参与社区么？ ​

晋升社区化

晋升由社区成员在群内组织投票，具体晋升规则由每个项目的核心团队自行协商决定 ​

其他社区规则

例如冲突解决规则，code review 要几票才能通过等，由每个项目的核心团队自行协商决定

参考资料

Apollo https://github.com/ctripcorp/apollo/pull/3670 ​https://github.com/ctripcorp/apollo/issues/3684 https://github.com/ctripcorp/apollo/discussions/categories/announcements ​

Tidb的社区组织架构 https://pingcap.com/blog-cn/tidb-community-upgrade/

怎么落地？

如果大家讨论觉得没问题了，可以先从 Layotto 和 SOFA-registry 开始试运行该制度。 一开始，先由项目 owner 根据社区贡献程度来确定初始团队(给大家发 title)，再由初始团队讨论细化晋升规则、title 提名。 ​

这是草案、不是结论，欢迎提出不同意见

本文仅作抛砖引玉、试着发出来看看大家意见，欢迎提出您的不同意见~ 本人经验不足，上次正儿八经写这种组织规则还是在小学三年级玩网游《传奇》时创建公会，所以如有不妥快来指正 ​

seeflood commented 3 years ago

English version will be added soon

seeflood commented 3 years ago

记录下钉群里的讨论：

这次设计的目的：

  1. 激励活跃贡献者，有个比contributor更酷的title
  2. 决策社区化，code review可以由活跃贡献者来，不想只有一两个人有review权限
  3. 调动SOFAStack社区各个项目owner积极性，让大家觉得是为了个人爱好/个人荣誉而贡献社区
  4. 让社区参与者能看到“确定性回报”，就比如tidb“一年提交8个pr就能晋升active contributor”。 逻辑是：国内程序员时间有限，最好能有个明确的规则、让大家看到“我牺牲业余时间做这些事，做完我就能得到确定性的回报”，如果规则比较模糊、晋升commiter的规则外人看不到，有经验的人可能就要在心里算笔账

反对观点：

  1. 社区没tidb那么多，怕拆太细了人不够、尴尬

另一种思路： 不新增角色了，还是从contributor直接到commiter，只不过早期定一个明确的commiter晋升规则，门槛低一些，以后人多了再考虑提高commiter门槛

seeflood commented 3 years ago

记录下一位不愿透露姓名的优秀开发者的意见：

  1. 同意反对观点，人少没必要；觉得头衔无所谓，skywalking的那种证书更酷
  2. 担心自己review不动别人代码
  3. 我们的证书不好看 （我去问问现在改证书还来得及么
seeflood commented 3 years ago

记录一位优秀贡献者的意见（终于有人支持这个方案了： image

seeflood commented 3 years ago

参考上述意见，做了些修改：

Draft 2

image

  1. 去掉了Active Contributor；
  2. 保留Reviewer，但是该角色可选，各项目可以按自己项目的情况决定是否加入该角色； Reviewer具有 Review PR 的义务，并且对某个项目/模块的 PR 的点赞（LGTM）有效。Review贡献也算在晋升committer的考虑之内。

Q: 添加这个角色的目的?

Q: 一票LGTM还是两票LGTM才能合并？ A: 目前想法是参考vue社区，reviewer如果review通过可以回复LGTM，但是没有merge权限，项目维护者（有写权限的人）负责实际合并。 项目维护者如果很信任reviewer，可以简单看下pr，没问题就合并；如果pr改动比较大、不太放心，就要自己也认真看一下pr。 所以，约等于两票合并制

Q: 怎么区分Reviewer和Committer? A: 目前的想法，Committer是很高的荣誉，说明他对项目做出了很大贡献、社区想表达对他贡献的感谢，因此颁发committer title，包括以后发证书、做活动发奖也优先考虑。所以我们要定个具体的成为Committer的规则，这个规则可以每个项目自己定，Layotto和SOFA-Registry可以先作为试点。

而Reviewer是感兴趣的contributor都可以来做(当然前提是对代码理解到位），多多益善，因为Review PR的人多了能让社区更活跃

欢迎各位继续提意见！

seeflood commented 3 years ago

记录另一位优秀贡献者的意见： image

seeflood commented 3 years ago

记录一位高情商的优秀贡献者观点：证书好看！ image

关于证书： image

Xunzhuo commented 3 years ago

我认为，问题并不是出在晋升路线的长短问题，甚至反而晋级路线越短越让贡献者望而却步，比如我怎么直接从contributor变成commitor？会给开发者很大的心理负担，反而会劝退一大批初级贡献者，然而这部分本应该占贡献者中的大多数；

我觉得应该根据开发者的不同水平制定更清晰的角色，才能调动起不同水平和兴趣的贡献者参与进来，所以我个人认为，问题反而是应该把角色给分清晰，并且让贡献者在每一级感受到社区的反馈和激励，不同角色有不同的权限和职责，这样才能形成良好的社区活跃度

个人认为晋级路线应该为： contributor -> member -> reviewer -> commiter -> PMC.

Contributor之上可以加一层Member的title，活跃的Member可以成为Reviewer，具体来说：

如何成为Member，这个在初期不能门槛太高，比如提交过PR被merge了，或者有价值的issue的，就可以邀请GitHub id 到社区成为member，成为member之后，他的职责是code review以及处理issue，如果发现member处理issue和code review的频率很高，比如连续一个月，每周至少处理过2个issue或1个PR，就可以成为Reviewer；

成为Reviewer之后，职责相比member要更明确，就是处理issue和PR，而且必须保持每周至少处理2个issue或1个PR，如果一个月内，有两周处理的频率没有达到标准，会回退到Member；

而commiter 我个人人为，晋升规则可以有两条：

关于角色权限问题：

  1. member可以处理issue，比如加label，assign任务，code review的LGTM权限
  2. reviewer与member有相同权力可以处理issue，比如加label，assign任务，code review的LGTM权限
  3. commiter 具有merge的权力，但是何时merge，需要除了他本人之外，有两个人以上的code review，然后他就能merge
  4. PMC 具有决策能力，委任commiter ，以及新PMC选举的投票权，当然他具有merge的能力，不过为了防止错误，即使PMC，也需要两位以上的code review，才能merge。

其实这就是Kubernetes社区的思想，具体有些晋升的指标可能不太一样哈（可以再讨论制定），比如Kubernetes社区成为member需要5个PR被merge，同时需要2个以上的member的sponsor，他需要在community repo提issue，达到基础标准之后，两个以上member去issue下评论sponsor去推荐他，他就会被commiter 邀请进入kubernetes

当然他们社区活跃度有它在cloud native popularity的原因，不过其实他优秀的社区规则，以及合理利用GitHub action建立robot去指引contributor，以及一些自动化的操作如处理基础的委派issue和reviewer，也是相当重要的因素。

包括它的规则表明，一年以内member没做任何贡献，会被踢出去，然后如果要进来，需要重新竞选。

当然提高活跃度，还有更细节的，比如在处理issue时，多去引导contributor，多鼓励然后加一些emoji，会潜在的提高社区贡献者的热情，包括把一些issue当作 good first issue，引导想贡献的contributor去做贡献成为Member。

除此之外，如果要更universal，建议尽量在issue和PR使用英语，沟通平台除了钉钉，多样化一点，比如slack；

seeflood commented 3 years ago

@Xunzhuo 感谢建议！！

  1. 关于Member:我觉得加入Member角色这个点子很棒，因为让贡献者可以在github profile显示组织logo（如果我没理解错的话），很cooooool
  2. 关于Member晋升Reviewer :因为社区目前人不多，我本来想着来了就是朋友、哪位Contributor想当Reviewer的话直接就能当,但是按你的思路其实member也要负责处理issue和code review，那么Member和Reviewer核心区别是啥？看起来好像没啥区别，两个角色都是负责处理issue和code review
seeflood commented 3 years ago

@stulzq @zu1k @tianjipeng @ZLBer @zhenjunMa @TreeLin @taoyuanyuan @nobodyiam @JervyShi 手动艾特一下，各位老师看下上述建议如何~

Xunzhuo commented 3 years ago

@seeflood

  1. 是的，这算是 basic recognized；
  2. 权限相同，但是职责不同。member里面有活跃的，也有不活跃的，有喜欢code review 也有不喜欢的，并不能保证快速的响应，如果有人能保持高活跃度，那就可以给他reviewer 的 title，如果能保持长时间的code review 这会是成为commiter 的一条途径，也就是成为reviewer 就有活跃度的要求，而member是没有要求的，所以两者权限相同，但是职责不同，reviewer有更多的职责，这样能保证社区快速响应，同时带给reviewer的是更深入对项目源码的剖析，以及晋升commiter 的机会，毕竟对源码更深入也应该是commiter 的基本要求，也是commiter 具有merge权限的前提。
seeflood commented 3 years ago

感谢@Xunzhuo的建议，参考 @Xunzhuo 和其他同学的意见，我试着做了修改：

Draft 3

image

0. Co-founder（项目创始人）终身荣誉制

作为终身荣誉，但没有实权，就不在社区角色里列出来了。 比如某位开发者创建了项目A，多年后即使他不再参与社区维护、辗转跳槽多家公司，经历了风风雨雨、起起落落，决定转行不做程序员了、开了家火锅店，他也依然是项目A的 Co-founder 建议各位还在社区的项目创始人自封Co-founder，建议各位在仓库首页或者官网加入致谢项目创始人的段落。因为这是一种荣誉和激励，希望让大家觉得是在为自己的个人影响力做开源

设计这个角色的目的

激励大家往SOFAStack和MOSN社区开源新项目（下半年已经有几个同学有想法了，而且sofa-bolt-go已经在开发了 )； 激励当前的项目owner（如果是创始人的话）； 感谢已经离开社区的初始开发者，邀请回到社区

1. Member

角色说明

新增Member角色，其实就是邀请加入组织。 当然，考虑到过往一些项目是只有Committer才能拉组织，该角色可选、不强制要求，各项目可以按自己项目的情况决定是否加入该角色。 目前的想法是先在Layotto和SOFA-Registry试验加入该角色。 但：Layotto的组织目前用的是MOSN，所以其实加入Layotto组织，就是加入MOSN

添加这个角色的目的?

加入组织后，贡献者的github profile页显示组织logo，这很酷，可以激励大家加入社区、做出贡献。

Member的职责

Member职责是code review以及处理issue，如果发现member处理issue和code review的频率很高，就可以成为Reviewer（详见下）；

Member分配的github组织权限

默认权限，没有写权限。但是LGTM有效

成为Member的条件（加入组织的条件）

每个项目自己定吧。目前收集到大家的不同意见有： a. 提交过有价值的PR b. 提交过2个有价值的PR c. 变更过100行（代码或文档） d. 愿意帮忙review代码和issue的Contributor都可以拉进组织，来了就是朋友

我个人的想法是按项目活跃度定门槛，比如SOFA-Registry可以把标准定低些，比如选择d（因为很缺人来快速响应仓库啊！！！）；Layotto可以把标准定稍微高一些？比如a或b 这个具体等每个项目有首届PMC后投票吧

2. Reviewer

角色职责

和Committer一样，也是负责code review以及处理issue，算是对Member贡献的认可和感谢。长期review贡献多可以晋升Committer Reviewer要承担一定的review责任。比如某个issue/Pull request涉及某个模块，项目维护者可以request这个模块的Reviewer进行Review、负责把关。比如有人给Layotto的WASM模块提bug，可以request WASN模块的reviewer @zhenjunMa

该角色可选，各项目可以按自己项目的情况决定是否加入该角色；

成为Reviewer的条件

如果发现member处理issue和code review的频率很高，比如连续一个月，每周至少处理过2个issue或1个PR，就可以成为Reviewer； 比如contributor对某个模块提供了2次重要PR后，可以邀请担任该模块的Reviewer（举个例子，邀请@zu1k 担任WASM模块的Reviewer） 具体条件每个项目的PMC决定

Reviewer是否会回退到Member

每个项目自己定。目前收集到的不同意见： a. 成为Reviewer之后，职责相比member要更明确，就是处理issue和PR，而且必须保持每周至少处理2个issue或1个PR，如果一个月内，有两周处理的频率没有达到标准，会回退到Member； b. 认为给Reviewer定目标太有KPI味了，工作背KPI就够难了别给社区搞KPI

Reviewer分配的github组织权限

image

添加这个角色的目的?

  1. 希望能让MOSN和SOFAStack社区响应速度更快一些，响应pr快一些（至于如何提高issue响应速度，我还没想到啥办法，欢迎提建议
  2. 决策社区化，code review可以由活跃贡献者来，不想只有一两个人有review权限
  3. 很多爱好者可能一段时间有空、一段时间没空（国内程序员现状.....)，没空的时候通过Review PR和issue，可以只花少量时间就能参与项目、做出贡献、知道项目这段时间发生的变化

code review时，一票LGTM还是两票LGTM才能合并？

A: 目前想法是参考vue社区，reviewer如果review通过可以回复LGTM，但是没有merge权限，项目维护者（有写权限的人）负责实际合并。 项目维护者如果很信任reviewer，可以简单看下pr，没问题就合并；如果pr改动比较大、不太放心，就要自己也认真看一下pr。 所以，约等于两票合并制

3. 其他

欢迎各位继续提意见！

seeflood commented 3 years ago

Hi guys, according to the discussion above,I submitted a PR #203 to announce our community roles,promotion rules and initial PMC member list Welcome to give your advice or different opinions! Meanwhile,if you are interested to join in as special roles like Member, Reviewer or Committer, please contact me