开源项目如何实现有效的民主治理？ [关闭]

如何成功实施民主（非BDFL http://en.wikipedia.org/wiki/Benevolent_Dictator_For_Life开源项目的受控）管理类型？ 更具体地说 - 对于使用分布式源存储库的项目。

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

如何鼓励分支合并到master中？

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

我特别想鼓励工作流程

define the problem->define requirements and specific metrics of success->architect->build and test

原因是——我经常看到这样的电子邮件here is the problem and here is how I think it should be solved立即有人跳进来并开始打斗。 根本没有生产力。

此类分歧通常源于对问题定义、需求或架构的不同看法。或者有时只是因为没有人考虑过这些事情。

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

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

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

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

edit：在相关问题中发现一些有趣的链接

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

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

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

项目确实需要执行治理！

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

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

• 被视为合法
• 有效沟通 https://stackoverflow.com/questions/2328631/how-to-effectively-implement-non-bfdl-dictator-organization-style-for-an-open-sou/2329203#2329203
• 授权“大众”为路线图定义、问题识别、解决方案范围界定和所有其他设计级任务做出贡献。 （一直以来，很明显，最终，在一切都说了之后，最终决定将由委员会做出。
• 交付优质且充满活力的产品（顺便说一句，通过采用敏捷开发流程，可以缩短交付之间的时间）
• 需要时妥协
• 提倡以协调的方式集中资源，而不是分散资源。
• 分享荣耀！

为了支持这一切正式的文档和流程非常有用。例如，define the problem->define requirements and specific metrics of success->architect->build问题中指出的程序可以以单个协作编辑文档（基于维基或其他）的形式实施，即每个问题/想法一个。该文档采用定义的格式进行模板化：所需属性，例如日期、初始发布信息...以及按照给定时间表打开（和关闭）进行编辑的部分。这可以清晰地记录集体对特定问题的看法、建议等、[权威]决定的内容以及原因。

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

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

最后，项目的领导者（无论是在“民主”领导还是“部分独裁”领导的背景下）需要对“维和”时刻保持警惕。开源项目的贡献者通常是精力充沛、聪明且固执己见的人；意见冲突、性格冲突、不耐烦等都是可以预料到的。然而，这些冲突可以通过系统地解决具有明确事实的问题、积极调节/编辑反对辱骂和非生产性形式等来缓解。