对于这个有点离题的答案表示抱歉(即，一个人未直接解决该问题).请尽情编辑！

需要执行管理的项目！

这些可能来自一个单一的(或不是)仁慈的***者，或者是一个可能是开放的，由不同但志趣相投的个人组成的[IMHO，小团体].一个标准的笑话是:"该组应该由奇数个成员组成，而3个成员已经太多了"；实际上，小型的大学委员会可能非常有效.

但是，对于非完全***"决策实体的要求与问题中建议的流程有些相符.为有效利用项目贡献者的良好意愿，执行团队需要

• 被认为是合法的
• 有效沟通
• 使群众"有能力为路线图定义，问题识别，解决方案范围界定和所有其他设计级任务做出贡献. (尽管很明显，最后还是说了最后，最终决定将在委员会中做出.
• 交付优质而充满活力的产品(顺便说一句，通过采用敏捷开发流程，缩短了交付之间的时间)
• 在需要时妥协
• 提倡以协调的方式集中资源而不是分支出去.
• 分享荣耀！

要支持所有这些正式文档和流程非常有用.例如，问题中指示的define the problem->define requirements and specific metrics of success->architect->build过程可以以单个协作编辑的文档(基于Wiki或其他)的形式实施，即每个问题/想法一个.该文档以定义的格式为模板:所需的属性，例如日期，初始过帐信息...以及打开(和关闭)以按照给定计划进行编辑的部分.这样可以使有关问题的集体记录，建议的内容，[权威性]决定的内容以及原因等保持清晰的记录.

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

另一种有用的方法是通过非正式(或事实上)来奖励有效参与，从而为有效地帮助该项目的贡献者提供更大的分量.较活跃的成员可以进入内部圈子"，也可以在项目子集中担任领导角色.

最后，一个项目的领导者(无论是在***"领导者还是在部分***"领导者的背景下)都必须对维持和平"保持警惕.开源项目的贡献者通常是朝气蓬勃，聪明而有见地的人.意见冲突，人格冲突，急躁等是可以预料的.但是，可以通过系统地解决具有明确事实的问题，针对名称调用和非生产性形式进行积极地审核/编辑等方式来缓解这些冲突.

How to successfully implement democratic (non-BDFL controlled) type of management for the open source project? More specifically - for the project using distributed source repositories.

What style of communication is best to adopt in such environment?

How to encourage merging branches into the master?

I am mostly interested in establishing the situation where people can directly merge into the master branch under the "social contract" agreement that they follow the project roadmap (which they themselves help to define) and that code they commit is tested.

I specifically want to encourage workflow

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

The reason is that - I often see emails like here is the problem and here is how I think it should be solved Immediately somebody else jumps in and starts a fight. Not productive at all.

Often disagreement of that kind stems from not being on the same page on the problem definition, requirements or architecture. Or sometimes just because nobody even thought about such things.

How to encourage people to analyze the problem properly, share great ideas and select the best solutions?

How to organize communication so to avoid silly fights, make good decisions without being overly bureaucratic and move along at a good pace ?

Would you have any suggestions? Are there examples of projects managed this way?

How do you think adoption of distributed revision control instead of centralized affects the style of project management?

edit: found some interesting links in related questions

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

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

Sorry for this somewhat off-topic answer (i.e. one not addressing directly the question). Please edit at your heart's delight!

Projects _do_ need executive governance!

Such may come from a single Benevolent (or not) Dictator, or a [IMHO, small] group, possibly open, of diverse but like-minded individuals. A standard joke on this is that: "The group should be made of an odd number of members, and 3 is already too many"; in truth, small collegial committees can be very effective.

This requirement for a "non fully democratic" decision making entity is however somewhat aligned with the processes suggested in the question. To effectively harness the good will of contributors to the project, the executive team needs to

• be perceived as legitimate
• communicate effectively
• empower "the masses" to contribute with roadmap definition, problem identification, solution scoping and all other design-level tasks. (All the while it remaining clear that in the end, and after all has been said, final decision will be done in committee.
• DELIVER a good and vibrant product (BTW by adopting agile development processes, the time between deliveries is lessened)
• compromise when needed
• advocate the interest of pooling resources in a coordinated fashion, rather than branching out.
• Share the glory!

To support all of this formal documentation and processes are very useful. For example, the define the problem->define requirements and specific metrics of success->architect->build procedure indicated in the question can be implemented in the form a single collaboratively edited document (wiki-based or other), i.e. one per issue/idea. This document is templated with a defined format: required attributes such as date, initial posting info... and sections which are opened (and closed) for editing following a given schedule. This allows keeping a clean(er) record of the way the collective though of a given issue, what was suggested etc, what was [authoritatively] decided and why.

With such a process, the community feels engaged and hopefully individuals not too disappointed when the eventual decisions do not go "their" way. They can read and comment on the what and why of the decisions.

Another useful approach is to reward effective participation by informally (or factually) provide more weight to the contributors who effectively help with the project. The more active members can either gain their way into the "inner circle" or be handed-out leadership roles on subsets of the project.

Finally, the leaders of a project (whether in the context of a "democratic" or of a "partially dicatorial" leadership) need to be ever vigilant about "peace keeping". Contributors to Open Source projects are typically energetic, smart and opinionated individuals; conflict of opinion, conflict of personalities, impatience etc. is to be expected. These ***es however can be eased by systematically addressing issues with clear facts, moderating/editing aggressively against name calling and non-productive forms etc.