Open source 如何为开源项目实现有效的民主治理？

如何成功地为开源项目实施民主（非受控）类型的管理？ 更具体地说-用于使用分布式源存储库的项目

在这样的环境中，什么样的沟通方式是最好的

如何鼓励将分支合并到主分支中

我最感兴趣的是建立这样一种情况，即人们可以根据“社会契约”协议直接合并到主分支，他们遵循项目路线图（他们自己帮助定义），并且他们提交的代码经过测试

我特别想鼓励工作流程

定义问题

->

定义成功的要求和具体指标

->

架构师

->

构建和测试

原因是-我经常看到类似于

的电子邮件这里是问题所在，下面是我认为应该如何解决的问题

马上就有人跳进来打起来了。 一点生产力都没有

这种分歧通常源于在问题定义、需求或体系结构上的分歧。或者有时候只是因为没人想过这些事情

如何鼓励人们正确地分析问题，分享伟大的想法并选择最佳解决方案

如何组织沟通以避免愚蠢的争吵，做出正确的决定而不过于官僚主义，并以良好的速度前进

你有什么建议吗？有这样管理的项目的例子吗

您认为采用分布式版本控制而不是集中式版本控制对项目管理的风格有何影响

编辑：在相关问题中找到一些有趣的链接

---

对于这个有点离题的答案（即没有直接回答问题的答案），我深表歉意。请随心所欲地编辑

项目确实需要执行治理！ 这些人可能来自一个仁慈的（或非）独裁者，或者一个可能是开放的、由不同但志同道合的个人组成的（IMHO，小）团体。关于这一点的一个标准笑话是：“这个团队应该由奇数个成员组成，而3个成员已经太多了”；事实上，小型合议委员会可能非常有效

然而，“非完全民主”决策实体的这一要求在某种程度上与问题中建议的流程一致。为了有效利用项目贡献者的善意，执行团队需要

• 被认为是合法的
• 授权“大众”参与路线图定义、问题识别、解决方案范围界定和所有其他设计级任务。（一直以来，我们都清楚地知道，最终，在所有这些都说了之后，最终的决定将在委员会中作出
• 交付一个好的、充满活力的产品（顺便说一句，通过采用敏捷开发过程，缩短了交付之间的时间）
• 必要时妥协
• 提倡以协调的方式集中资源，而不是分散资源
• 分享荣耀

为了支持所有这些，正式文档和流程非常有用。例如，问题中指出的

定义问题->定义需求和特定成功指标->架构师->构建过程可以以单个协作编辑文档（基于wiki或其他）的形式实现，即每个问题/想法一个。此文档以定义的格式为模板：所需的属性，如日期、初始发布信息…以及按照给定的时间表打开（和关闭）以进行编辑的部分。这允许保持对给定问题的集体思考方式、建议内容等的清晰（er）记录[权威性]决定以及原因

有了这样一个过程，社区会感到投入，希望个人在最终决定不按“他们”的方式进行时不会太失望。他们可以阅读和评论决定的内容和原因

另一个有用的方法是通过非正式（或事实上）向有效帮助项目的贡献者提供更大的权重来奖励有效参与。更积极的成员可以进入“内部圈子”，也可以在项目的子集上担任领导角色

最后，一个项目的领导人（无论是在“民主”或“部分献身”的领导背景下）需要对“维持和平”时刻保持警惕。开源项目的贡献者通常都是精力充沛、聪明和固执己见的人；意见冲突、性格冲突、不耐烦等都是可以预料的。但是，通过系统地以明确的事实解决问题、对点名和非生产性问题进行积极的调整/编辑，这些冲突可以得到缓解互动形式等
沟通方式：

电子邮件和邮件列表：


公开讨论与项目有关的一切（？）
提问时-不要捆绑
用你自己的观点提问
鼓励人们提出多种解决方案
让人们权衡利弊
简明扼要
避免轻浮的语言，这些语言可能会被不太了解你的人认为是负面的
访问存储库

有多种选择，从
一个控制提交人
到
任何人都可以提交
——但只要社会同意，他们尊重项目指南和路线图

在我看来，分布式存储库可以让您更轻松地处理您允许提交的对象，因为有多个备份，而且repo实际上是牢不可破的

另作说明