Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 7 years ago.

Improve this question 开发者_Python百科

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 clashes however can be eased by systematically addressing issues with clear facts, moderating/editing aggressively against name calling and non-productive forms etc.

---

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.

---

access to repository

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.

---

Communication style:

email and mailing lists:

• discuss everything concerning the project in public (?)
• when asking questions - do not bundle questions with your own opinions
• encourage people to propose more than one solution
• ask people to weigh pros and cons
• be brief and to the point
• avoid frivolous language that can be perceived negatively with people that do not know you well