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
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 clashes however can be eased by systematically addressing issues with clear facts, moderating/editing aggressively against name calling and non-productive forms etc.
Let it be affirmed that the primary goal in instituting governance of an open-source project be to ensure the long-term health of the project.
Accordingly, the default bias should be towards openness and inclusiveness. However, policy should be changed as issues present themselves, in order to maintain the long-term health of the project.
For the model of decision making, we favor a "do-ocracy". The people who contribute the most generally command the respect of the community. Alienating them is the best way to derail the project.
The repository should be open the committers, given that commits can easily be reverted and commit-access easily revoked. This is preferable to alienating potential committers.
To ensure transparency for developers new and old, and allow them to decide their involvement in a project based upon the history of the project, their should be transparency and openess in the inner working of the project. For example, the email archive should be public.
Lastly, let us remember that too much red-tape gets in the way of progress. So red-tape and other barriers to contribution should be avoided, and only added as issues present themselves.
This Constitution can and should be amended as issues present themselves.
there are several options ranging from one controlling committer to anyone can commit - but upon social agreement that they respect the project guidelines and the roadmap.
in my opinion distributed repository allows you to be more relaxed with who you allow to commit, because there are multiple backups and the repo becomes virtually unbreakable.
on a separate note - anyone can commit approach - which I would like to test out - sounds more like a "wiki". I can directly compare this with my experience managing a wiki (nmrwiki.org): where despite complete openness - where not even user registration is required to edit the resource, people are often wary about "breaking stuff" and this worry becomes a mental barrier to making a contribution. So a permissive approach to repository management may just work.
发布评论
评论（4）
很抱歉这个有点偏离主题的答案（即没有直接解决问题）。请随心所欲地编辑！
项目确实需要执行治理！
这些人可能来自一个仁慈的（或非仁慈的）独裁者，或者一个[恕我直言，小]团体，可能是开放的，由不同但志同道合的个人组成。一个标准的笑话是：“小组应该由奇数成员组成，而 3 人已经太多了”；事实上，小型合议委员会可以非常有效。
然而，对“非完全民主”决策实体的要求在某种程度上与问题中建议的流程一致。为了有效利用项目贡献者的善意，需要
支持所有这些正式文档和流程非常有用。问题->定义成功的要求和具体指标->架构师->构建问题中指出的过程可以以单个协作编辑文档（基于wiki或其他）的形式实现，即每个文档一个问题/想法。该文档采用定义的格式进行模板化：所需的属性，例如日期、初始发布信息...以及按照给定的时间表打开（和关闭）进行编辑的部分，这允许保持干净的记录。关于特定问题的集体思考方式、建议等、[权威]决定的内容以及原因。
通过这样的过程，社区会感到参与，并希望当最终的决定不符合“他们”的意愿时，个人不会太失望。他们可以阅读并评论决策的内容和原因。
另一种有用的方法是通过非正式（或事实上）为有效帮助项目的贡献者提供更多权重来奖励有效参与。更活跃的成员可以进入“内部圈子”，或者在项目的子集上担任领导角色。
最后，项目的领导者（无论是在“民主”领导还是“部分独裁”领导的背景下）需要对“维持和平”保持警惕。开源项目的贡献者通常是精力充沛、聪明且固执己见的人；意见冲突、性格冲突、不耐烦等都是可以预料到的。然而，这些冲突可以通过系统地解决具有明确事实的问题、积极调节/编辑反对辱骂和非生产性形式等来缓解。
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
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->buildprocedure 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 clashes however can be eased by systematically addressing issues with clear facts, moderating/editing aggressively against name calling and non-productive forms etc.
最初发布于 MetaOptimize< /a>.
< a href="http://blog.metaoptimize.com/2010/02/27/constitution-for-governance-of-open-source-projects-v20100227/" rel="nofollow noreferrer">开放治理宪法源项目 (v20100227)
需要确认的是，建立开源项目治理的首要目标是确保项目的长期健康发展。
因此，默认的偏见应该是开放和包容。
然而，随着问题的出现，政策应该改变，以保持项目的长期健康发展。
对于决策模式，我们赞成“执行统治”。
贡献最大的人普遍受到社区的尊重。
疏远他们是破坏项目的最好方法。
存储库应该向提交者开放，因为提交可以很容易地恢复并且提交访问可以很容易地撤销。这比疏远潜在的提交者更好。
为了确保新老开发人员的透明度，并让他们根据项目的历史决定是否参与项目，项目的内部工作应该是透明和开放的。例如，电子邮件存档应该是公开的。
最后，让我们记住，太多的繁文缛节会阻碍进步。因此，应该避免繁文缛节和其他贡献障碍，只有在问题出现时才添加。
本宪法可以而且应该根据问题本身进行修改。
因此就这样解决了。
Originally posted on MetaOptimize.
Constitution for Governance of Open-Source Projects (v20100227)
Let it be affirmed that the primary goal in instituting governance of an open-source project be to ensure the long-term health of the project.
Accordingly, the default bias should be towards openness and inclusiveness.
However, policy should be changed as issues present themselves, in order to maintain the long-term health of the project.
For the model of decision making, we favor a "do-ocracy".
The people who contribute the most generally command the respect of the community.
Alienating them is the best way to derail the project.
The repository should be open the committers, given that commits can easily be reverted and commit-access easily revoked. This is preferable to alienating potential committers.
To ensure transparency for developers new and old, and allow them to decide their involvement in a project based upon the history of the project, their should be transparency and openess in the inner working of the project. For example, the email archive should be public.
Lastly, let us remember that too much red-tape gets in the way of progress. So red-tape and other barriers to contribution should be avoided, and only added as issues present themselves.
This Constitution can and should be amended as issues present themselves.
Therefore be it resolved.
访问存储库
有多种选择，从
一个控制提交者到任何人都可以提交- 但基于社会一致同意他们尊重项目指南和路线图。在我看来，分布式存储库可以让您更轻松地选择允许提交的人，因为有多个备份，并且存储库几乎牢不可破。
另请注意 -
任何人都可以提交方法 - 我想测试一下 - 听起来更像是“wiki”。我可以直接将其与我管理 wiki (nmrwiki.org) 的经验进行比较：尽管完全开放 - 甚至不需要用户注册来编辑资源，但人们常常对“破坏东西”保持警惕，这种担心成为一种心理障碍做出贡献。因此，宽松的存储库管理方法可能会起作用。access to repository
there are several options ranging from
one controlling committertoanyone can commit- but upon social agreement that they respect the project guidelines and the roadmap.in my opinion distributed repository allows you to be more relaxed with who you allow to commit, because there are multiple backups and the repo becomes virtually unbreakable.
on a separate note -
anyone can commitapproach - which I would like to test out - sounds more like a "wiki". I can directly compare this with my experience managing a wiki (nmrwiki.org): where despite complete openness - where not even user registration is required to edit the resource, people are often wary about "breaking stuff" and this worry becomes a mental barrier to making a contribution. So a permissive approach to repository management may just work.沟通方式：
电子邮件和邮件列表：
提出带有自己观点的问题
Communication style:
email and mailing lists:
questions with your own opinions