Decision Process for the TWiki Community

UNDER CONSTRUCTION

I want to spend some days to draft this so do not attack it too much yet - Kenneth

Purpose

This topic defines the decision process for decision needed to be taken by the open source community round TWiki for anything that does not relate to features. For features the community follows the TWikiReleaseManagementProcess.

The decision process is not made to prevent the community members from working actively maintaining and evolving the pages on the twiki.org site. It is there to assist in getting important decisions and topics where a conflict is present decided using a fair and open process.

The community decision process ensures that

• Important decisions are visible and discussed in the community
• Important decisions are decided upon based on facts and arguments
• Open decision process which allows all community members: developers, marketeers, supporters, testers, active customers to have their vote.
• An executive team veto that ensures against a hostile take over by showing up in great numbers to force a decision through against the spirit of the regular project participants.
• An executive team veto that cannot be abused by a single person

The process steps

• The proposer raises a proposal using the TWiki application on TWikiCommunityDecisionProposals
• The community discuss the proposal on the topic. The proposal must be discussed for a minimum of 14 days before a decision can be made
• If everyone agrees with the proposal. Or agrees after the proposal has been adjusted per suggestions from the community the proposal is declared accepted by consensus
• If there is just ONE that disagrees the proposal is added to the agenda of a TWiki Project Meeting. TWiki project meetings are held once per month. No proposal can be on a project meeting unless it has been raised on Codev for at least 14 days
• Anyone that participates at the project meeting can vote for or against the proposal
• Anyone not able to attend the meeting can give their vote on the proposal topic. It is preferred - if possible - that votes are given at the meeting because this gives a better chance to allow other peoples oppinions to influence the decision. But the community is spread in 24 time zones so all pre-given votes count. You are allowed to change your already given vote at the meeting
• Members of the executive team can veto against a proposal if they find that the proposal goes against the TWikiMission or to protect the project against attempts to push through a proposal that goes against the interest of the regular active contributors by showing up as a hostile large group. Example can be a hostile take over attempt from a commercial interest

The decision process cannot make decisions in these areas.

• The TWiki name and brand, and the twiki.org domain name are the property of the project founder Peter Thoeny. Any decisions concerning the use of these belongs entirely to Peter Thoeny.
• Decisions to exclude an individual member from access to the project assets. Such decision belongs to the executive team and in the case the TWiki brand is at risk to Peter Thoeny.

The decision process should not be used for

• Every little decision. Making decisions this way is time consuming. Use this process only when it is really needed
• To suppress minority oppinions. Democracy is the combination of ruling by majority and protection of minorities. Try and adjust processes and proposals so that both the majority and minority interests are met whenever possible
• Promiting commercial interests that does not benefit the rest of the community
• Generate flame wars. When a proposal meets resistance seek compromize. A good compromize may be a less ideal solution but the benefit to maintaining an open minded and friendly community will often outweigh the disadvantage of a compromize.
• Making last minute decisions. Do not create proposals in the last minute or in a way that takes our customers or a release hostage. Raise proposals early so things can be discussed and decided without rush and stress and in a friendly tone.
• Challenging the people that have volunteerly taken roles on the project. Let the release manager, the marketing coordinator, the twiki.org web master, the server sys admin, the subversion maintainer etc etc do their job and only challenge their decisions in rare cases when it is important for the whole community.

-- Contributors: KennethLavrsen - 25 Feb 2008

Discussion