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

Question

如何成功实施开源项目的民主（非BDFL控制）管理类型？特别是针对使用分布式源代码存储库的项目。

在这种环境下，采用什么样的沟通风格最好？

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

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

我特别想鼓励工作流程

定义问题 -> 定义成功的要求和具体指标 -> 架构设计 -> 构建和测试

原因是我经常看到像这是问题，这是我认为应该如何解决这样的邮件。然后立即有人跳出来开始争吵。完全没有生产力。

这种不同意往往源于在问题定义、要求或架构上没有达成共识，或者有时仅仅是因为没有人想过这些事情。

如何鼓励人们正确分析问题、分享好的想法并选择最佳解决方案？

如何组织沟通以避免无谓争吵，做出好的决策而不过于繁琐，并以良好的速度推进？

你有什么建议？有没有这样管理项目的示例？

你认为采用分布式修订控制而非集中式对项目管理风格有何影响？

编辑：在相关问题中发现了一些有趣的链接。

http://gettingreal.37signals.com/toc.php

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

- Evgeny

---

嘿 @mjv，我对 cw 没有任何问题 : )，我希望这不会阻止人们提供一些好的见解，即使他们不能因此获得“声誉点数”。 - Evgeny

非BFDL？我不确定那是什么意思。 - Gabe

BFDL - 慈善独裁者终身制 - 就像 Python 中的 Guido van Rossum没有 BFDL - 我指的是更像同事式的治理形式。 - Evgeny

@mjv 我也加了一个词 "民主的" :) - Evgeny

我理解努力关注协作治理的重点。请根据您的意愿编辑标题（和其他内容）；在我们公开咨询标题时，让我们尽量不展示协作努力缺乏灵活性的情况;-) 建议: “开源治理：给予民主机会！” - mjv

Answer 1

很抱歉这个回答有些离题（即不直接回答问题）。请随意编辑！

项目确实需要行政管理！

这可能来自一个慈善的（或者不是）独裁者，或者一个[我认为是小的]团队，可能是开放的，由多样但志同道合的个人组成。一个标准的笑话是：“该组应该由奇数个成员组成，3个已经太多了”；事实上，小型学院委员会可以非常有效。

然而，这种“非完全民主”的决策实体的要求与问题中建议的过程有一定的关联。为了有效地利用项目贡献者的好意，执行团队需要：

• 被视为合法
• 有效沟通
• 授权“群众”参与路线图定义、问题识别、解决方案范围和所有其他设计级任务。（同时清楚地表明最终决定将在委员会中做出）
• 交付一个良好和充满活力的产品（顺便说一句，通过采用敏捷开发过程，交付时间缩短了）
• 在需要时妥协
• 倡导资源协调汇集的利益，而不是分支。
• 分享荣耀！

为了支持所有这些正式文件和流程非常有用。例如，问题定义->定义要求和具体成功指标->架构->构建程序可以以单个协作编辑文档（基于维基或其他）的形式实现，即每个问题/想法一个。该文档模板化为一个定义的格式：必需的属性，如日期、初始发布信息...和打开（关闭）编辑的部分，遵循给定的时间表。这样可以保持对给定问题的集体思考的更清晰记录，提出了什么建议等等，什么被[权威地]决定了以及为什么。

通过这样的过程，社区感到参与，并希望当最终决定不“他们”的方式时，个人不会太失望。他们可以阅读并评论决策的内容和原因。

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

最后，项目的领导者（无论在“民主”或“部分独裁”的领导下）需要始终关注“维护和平”。

开源项目的贡献者通常是精力充沛、聪明且有自己的想法；意见上的冲突、个性上的冲突、不耐烦等是可以预料的。然而，这些冲突可以通过有系统地采用清晰的事实来解决，积极地进行名字呼喊和非生产形式的调节/编辑等方式来缓解。

- mjv

Answer 2

本文最初发布在MetaOptimize。

开源项目治理章程（v20100227）

让我们确认，建立开源项目治理的主要目标是确保项目的长期健康。

因此，默认倾向于开放和包容。 然而，应根据问题的出现进行政策调整，以维护项目的长期健康。

对于决策模型，我们支持“实干主义”。 贡献最多的人通常会赢得社区的尊重。 排斥他们是使项目失败的最佳方式。

代码库应该对提交者开放，因为提交可以很容易地被撤销，提交权限也可以很容易地被收回。这比排斥潜在的提交者更可取。

为了确保新老开发者的透明度，并允许他们根据项目历史来决定自己的参与度，项目的内部运作应该是透明和开放的。例如，电子邮件归档应该是公开的。

最后，让我们记住，太多的繁文缛节会妨碍进展。因此，应避免繁文缛节和其他阻碍贡献的障碍，并只在问题出现时添加。

本章程可以并且应该根据问题的出现进行修改。

因此，决定如下。

- Joseph Turian

Answer 3

沟通风格:

电子邮件和邮件列表:

• 在公共场合讨论与项目有关的所有事情
• 提问时不要混杂自己的观点
• 鼓励人们提出多种解决方案
• 请人们权衡利弊
• 简洁明了地表达
• 避免使用轻浮的语言，以免被不熟悉你的人误解

- Evgeny

Answer 4

访问存储库

有几个选项可供选择，从一个控制提交者到任何人都可以提交 - 但在社交协议上，他们必须尊重项目指南和路线图。

在我看来，分布式存储库允许您更轻松地允许谁提交，因为有多个备份，存储库变得几乎不可破坏。

另外需要注意的是 - 任何人都可以提交的方法 - 我想测试一下 - 听起来更像是一个“维基”。我可以直接将其与我管理维基（nmrwiki.org）的经验进行比较：尽管完全开放 - 甚至不需要用户注册即可编辑资源，但人们常常担心“破坏东西”，这种担忧成为了做出贡献的心理障碍。因此，对存储库管理的宽容态度可能会奏效。

- Evgeny