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

Question

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

在这样的环境中最好采用什么样的沟通方式？

如何鼓励合并分支到主人？

我最感兴趣的是确定人们可以根据“社会契约”协议直接合并到主分支的情况，他们遵循项目路线图（他们自己帮助定义）并且他们提交的代码会被测试。< / p>

我特别想鼓励工作流程

define the problem - ＆GT; define requirements and specific metrics of success - ＆GT; architect - ＆GT; build and test

原因是 - 我经常看到here is the problem and here is how I think it should be solved等电子邮件 其他人立即跳进去开始战斗。 根本没用。

这种意见的不同意见源于不在问题定义，要求或架构的同一页面上。或者有时候因为没有人想到这样的事情。

如何鼓励人们正确分析问题，分享好主意并选择最佳解决方案？

如何组织沟通，以避免愚蠢的斗争，做出正确的决定，而不是过于官僚化，并以良好的步伐前进？

你有什么建议吗？是否有以这种方式管理的项目示例？

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

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

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

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

Answer 1

很抱歉这个有点偏离主题的答案（即没有直接解决问题的答案）。请高兴地编辑！

项目_do_需要执行治理！

这可能来自单一的仁慈（或不）独裁者，或者可能是开放的[恕我直言，小团体]，他们是多元化但志同道合的人。对此的一个标准笑话是：“该组应由奇数个成员组成，3个已经太多”;事实上，小型合议委员会可以非常有效。

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

• 被认为是合法的
• communicate effectively
• 授权“群众”为路线图定义，问题识别，解决方案范围和所有其他设计级任务做出贡献。 （最后它仍然清楚，最后，并且毕竟已经说过，最终的决定将在委员会完成。
• 提供优质且充满活力的产品（通过采用敏捷开发流程实现BTW，减少交付时间）
• 在需要时妥协
• 提倡以协调的方式汇集资源的兴趣，而不是分支出来。
• 分享荣耀！

支持所有正式文档和流程非常有用。例如，问题中指示的define the problem->define requirements and specific metrics of success->architect->build过程可以以单个协作编辑的文档（基于维基或其他）的形式实现，即每个问题/想法一个。本文档使用定义的格式进行模板化：必需的属性，如日期，初始发布信息...以及打开（和关闭）以便在给定计划后进行编辑的部分。这样可以保持一个干净的（呃）记录集合的方式，特定问题，建议等等，[权威]决定的内容和原因。

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

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

最后，一个项目的领导者（无论是在“民主”还是“部分干部”领导的背景下）需要对“维持和平”始终保持警惕。开源项目的贡献者通常是精力充沛，聪明且自以为是的人;意见冲突，性格冲突，急躁等等。然而，这些冲突可以通过系统地解决明确事实的问题，积极地对名称调用和非生产性形式等进行调节/编辑来缓解。

Answer 2

最初发布于MetaOptimize。

Constitution for Governance of Open-Source Projects (v20100227)

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

因此，默认偏见应该是开放性和包容性。 但是，政策应该随着问题的出现而改变，以保持项目的长期健康。

对于决策模型，我们赞成“干预”。 贡献最多的人通常会尊重社区。 疏远他们是破坏项目的最佳方式。

存储库应该打开提交者，因为提交可以很容易地被还原，并且提交访问很容易被撤销。这可能会疏远潜在的提交者。

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

最后，让我们记住，过多的繁文缛节阻碍了进步。因此应该避免使用繁文缛节和其他障碍，并且只在问题出现时添加。

本宪法可以而且应该根据问题进行修改。

因此可以解决。

Answer 3

沟通方式：

电子邮件和邮件列表：

• 公开讨论有关该项目的一切（？）
• 提问时 - 不要捆绑 有你自己意见的问题
• 鼓励人们提出多个解决方案
• 让人们权衡利弊
• 简明扼要
• 避免与那些不了解你的人产生负面影响的琐碎语言

Answer 4

访问存储库

从one controlling committer到anyone can commit有几种选择 - 但在社会协议中他们尊重项目指南和路线图。

在我看来，分布式存储库允许您对允许提交的人更加放松，因为有多个备份并且repo变得几乎牢不可破。

单独注意 - anyone can commit方法 - 我想测试一下 - 听起来更像是一个“维基”。我可以直接将其与管理维基（nmrwiki.org）的经验进行比较：尽管完全开放 - 编辑资源甚至不需要用户注册，人们常常对“打破东西”持谨慎态度，这种担心成为一种心理障碍做出贡献。因此，对存储库管理采取宽松的方法可能会起作用。