社群治理
姜宁
讲师介绍
TODO 添加讲师相关的内容
开源社群的运作方式
开源项目是如何运作的？
如何保持项目可持续发展？
项目健康运行的指标是什么？
开源项目不同发展阶段采用的策略
从一个小的想法开始亲力亲为
吸引用户构建社群创造价值
仁慈的独裁者（BD）阶段
基于共识的民主决策
仁慈的独裁者
依靠人格和经验的力量行使最终决策权
社群认可的仲裁者，通常是项目的创建者
长期积累的技术领导力
有一定的自我约束力
尊重其他专业知识领域的维护着
Fork所带来的制衡
共识民主决策
BD的退隐建立起来的更开放的民主制度
需要建立起一套正式的基于团队的制度
在基金会孵化过程中一直强调的
以技术为主题的讨论
很多时候是以隐式方式达成共识
达不成共识时，投票解决
投票表决的艺术
谁来参与投票
PMC的作用
投票者并非只是编码人员
投票之前的讨论 — 达成共识的基础
投票的内容
推举新的维护人员
重大决策与民意调查
社群治理指南
行为准则规范
社群的运作指南
开发者指南的-快速入门
社群治理的FAQ
开源软件基金会的价值
为项目开发提供基础设施
提供知识产权管理的法律框架
提供日常的运营和治理支持
基础设施
软件开发相关的基础设施支持
版本控制，问题追踪，构建系统，版本发布
沟通工具，邮件列表
法律框架与知识产权管理
保证知识产权厂商中立
责任与风险管理
确认代码来源
项目的许可证管理
日常运营与服务
提供跨项目的生命周期管理
知识产权的管理
项目孵化，社群建设的指导
资金来源：会员，会费和捐款
参与开源的动机
大家为什么要参与开源项目？
解决自己的痛点问题
有很强的内在的动机
开发好用的软件
通过合作共建赢得尊重
善用委托
常规分散工作量的方式
通过示弱和协商的方式
受托者意识到相关的信任
被委托人感受到接受任务的压力
通过委托可以吸引人们更加深入地参与项目
任务分配与跟进
社群中的任务是很难分配的
通过询问的方式让大家认领任务
被分配的人可以自由接受或拒绝这项任务
分配是需要关注人们感兴趣的内容
公开的讨论跟进进展问题
赞扬与批评
及时给出反馈可以鼓励好的行为
不要吝啬赞扬， 这是最有效的激励
赞扬的时候也需要注意频率，避免赞扬贬值
具体冷静的批评也是值得推崇的
防止属地主义
在ASF中，我们不鼓励在源代码中使用作者标记
让开发者社群为整个项目负责
需要避免参与者独占项目的某一领域
破坏了项目的合作、平等的精神
提升自动化的好处
提升效率的手段
避免人们在手动执行过程中的错误
让开发者实时获得反馈，降低试错成本
节省时间让人类做更有趣的事情
自动化测试
自动化测试对任何软件项目都非常有用
自动化回归测试提供了安全防护网
降低试错成本，鼓励更多人来做探索性的开发
让大家放心进行代码重构
潜在的参与者
将每个用户视为潜在的参与者
建设性地、礼貌地互动
提供Bug报告指导与模版
邀请大家针对错误进行自助式修改
面对面会议
Office Hour
Meetup
黑客马拉松
竞赛
务虚会议
分担管理任务和技术任务
“经理”不代表“责任人”
补丁经理 （追踪审核补丁）
翻译经理 （国际化与本地化）
文档经理 （保持文档的时效性）
问题经理 （追踪Bug报告情况）
社群经理 （维护好开发者的关系）
Committer和维护人员
选择Committer
基于其在社群中的行为，讨论新Committer人选
通过商议以及投票的方式进行（非公开讨论）
技术技能满足正式代码贡献的标准，有很强的合作意愿
不是简单评价代码提交的行数，而是要看到代码提交的质量
Committer的职责
招募用户和开发人员
培养新贡献者
自由讨论的同时做出必要的决策
维护领域知识库，帮助新人和专家
软件使用文档的变形
认可
认可是自由软件世界的主要“货币”
在项目中的名声大体决定了其影响力，这会间接带来金钱
代码管理器能够准确记录谁在何时做了什么
版本发布过程中的感谢
区分常规感谢和特别鸣谢
分叉（fork)
项目的一个副本与另外一个副本产生分歧
分叉类型：
开发分叉， 开发的版本最终会回归到主干
硬分叉， 开发团队理念分歧导致的永久性分歧
是否是硬分叉
对项目的发展方向产生了不可调和的分歧
一组开发者认定与其他的开发者合作成本超过的收益
分叉会涉及到社群的分裂
分叉的主线之争
分叉还存在商标权之争
处理分叉
不是压制分叉，而是减少分叉的影响
不要强迫人们做出排他性的选择
要尽可能地与分叉进行合作
创建分叉
创建之前先排除其他所有的可能性（证明分叉的正义性）。
需要全面的分析，来评估分叉成功性，
大多数的分叉是不一定成功的
参考资料
问题
大家可以现场提问
在演讲之后沟通
给我发送邮件