很抱歉这个有点离题的答案(即没有直接回答问题)。请随心所欲地编辑!

项目确实需要执行管理!

这些人可能来自一个仁慈的(或不是)独裁者,或者一个可能是开放的、由不同但志同道合的个人组成的(IMHO,小)群体。关于这一点的一个标准笑话是:“ 这个小组应该由奇数个成员组成,3个成员已经太多了 “事实上,小型合议委员会可能非常有效。

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

• 被视为合法
• communicate effectively
• 授权“大众”参与路线图定义、问题识别、解决方案范围界定和所有其他设计级任务。(一直以来,很明显的是,最终,也就是说,最终的决定将由委员会做出。)。
• 交付一个良好且充满活力的产品(顺便说一句,通过采用敏捷开发流程,缩短了交付之间的时间)
• 需要时妥协
• 提倡以协调的方式集中资源,而不是分散资源。
• 分享荣耀!

支持所有这些 正式文档和流程非常有用 . 例如 define the problem->define requirements and specific metrics of success->architect->build 问题中指出的程序可以以单个协作编辑文档(基于wiki或其他)的形式实施,即每个问题/想法一个文档。此文档使用定义的格式进行模板化:所需的属性,如日期、初始过帐信息。。。以及根据给定时间表打开(和关闭)以进行编辑的节。这样就可以清楚地记录集体对某一问题的想法、建议等,以及[权威性]决定的内容和原因。

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

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

最后,项目领导人(无论是在“民主”或“部分支持”的领导背景下)需要 时刻警惕“维持和平” . 开源项目的贡献者通常是精力充沛、聪明和固执己见的人;可能会出现意见冲突、性格冲突、不耐烦等情况。然而,通过有系统地以明确的事实解决问题,对点名和非生产性形式进行积极的调整/编辑,可以缓解这些冲突。

最初发布于 MetaOptimize .

Constitution for Governance of Open-Source Projects (v20100227)

应该肯定的是,建立开源项目治理的首要目标是确保项目的长期健康。

因此,默认的偏向应该是开放和包容。 然而,应在问题出现时改变政策,以保持项目的长期健康。

在决策模式上,我们倾向于“实行民主”。 贡献最大的人通常会得到社区的尊重。 疏远他们是使项目脱轨的最佳方式。

考虑到提交可以轻松还原,提交访问也可以轻松撤销,存储库应该由提交者打开。这比疏远潜在的提交者更好。

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

最后,让我们记住,太多的繁文缛节阻碍了进步。因此,应该避免繁文缛节和其他阻碍贡献的障碍,只有在问题出现时才加上。

这部宪法可以而且应该在出现问题时加以修订。

因此,请予以解决。

访问存储库

有多种选择,包括 one controlling committer 到 anyone can commit -但社会一致认为他们尊重项目指导方针和路线图。

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

单独说明- 任何人都可以 这种方法——我想测试一下——听起来更像是一个“维基”。我可以直接将这与我管理wiki(nmrwiki.org)的经验进行比较:尽管完全开放,甚至不需要用户注册就可以编辑资源,但人们往往对“破坏性的东西”持谨慎态度,这种担心成为了做出贡献的心理障碍。因此,一种允许的存储库管理方法可能会奏效。

沟通方式 :

电子邮件和邮件列表 :

• 公开讨论与项目有关的一切(?)
• 提问时-不要捆绑 有自己观点的问题
• 鼓励人们提出多种解决方案
• 让人们权衡利弊
• 简明扼要
• 避免轻浮的语言,这些语言可能会被不太了解你的人消极地看待